BMCBladeLogicUserGuide v800 PDF

BMC BladeLogic Server
Automation User Guide
Supporting
BMC BladeLogic Server Automation version 8.0.00
November 2009
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 713 918 8800 or Fax 713 918 8000
2101 CITYWEST BLVD 800 841 2031
HOUSTON TX 77042-2827
USA
Outside United States and Canada
Telephone (01) 713 918 8800 Fax (01) 713 918 8000
Copyright 20022009 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, IBM, and WebSphere are trademarks or registered trademarks of International Business Machines Corporation in the United States,
other countries, or both.
Java, JumpStart, OpenBoot, Solaris, and Sun are trademarks or registered trademarks of Sun Microsystems, Inc., in the U.S. and other
countries.
Linux is the registered trademark of Linus Torvalds.
Oracle is a registered trademark of Oracle Corporation.
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. UNPUBLISHED -- RIGHTS 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
You can obtain technical support by using the BMC Software Customer Support website or by contacting Customer
Support by telephone or e-mail. To expedite your inquiry, see Before contacting BMC.
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 issues similar to yours and possible solutions
order or download product documentation
download products and maintenance
report an issue or ask a question
subscribe to receive proactive e-mail alerts when new product notices are released
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 issue
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 follows:
(USA or Canada) Contact the Order Services Password Team at 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 BladeLogic User Guide

Contents
Chapter 1 Introduction 23
Application Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Overview of this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Documentation conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Procedural descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Windows and UNIX paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Multiple approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
System text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapter 2 Overview of BMC BladeLogic Server Automation 29

System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Client tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Middle tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Server tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Using BMC BladeLogic A brief overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Component templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Depot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
RBAC Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Chapter 3 Getting started 37

Preparing for user logins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Setting up an authentication profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Starting the BMC BladeLogic console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Viewing an untrusted certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Deleting cached session credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Viewing cached session credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Viewing or deleting stored certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Switching roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Changing passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Rules for entering paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Configuration file entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Contents 5
Slashes appearing in values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Trailing slashes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Chapter 4 Using the BMC BladeLogic Server Automation console 51

BMC BladeLogic console elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Quick tour of the BMC BladeLogic Console interface . . . . . . . . . . . . . . . . . . . . . . . 57
BMC BladeLogic perspectives and views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
About global capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Running operations in the background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Working with content editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Viewing and editing text files with BL Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Viewing and editing Network Shell Script files with ShellEd . . . . . . . . . . . . . . . . 70
Setting preferences for text editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Selecting editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Provisioning with BMC BladeLogic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Managing the BMC BladeLogic console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Customizing preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Viewing keyboard shortcuts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Customizing keystroke combinations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Customizing tables and columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Refreshing the data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Managing BMC BladeLogic resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Components folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Component Templates folder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Depot folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Devices folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Jobs folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
RBAC Manager folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Servers folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Creating new objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Organizing folder content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Searching for objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Creating a folder or group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Defining a smart group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Copying, cutting, and pasting groups, folders, and system objects. . . . . . . . . . . . 95
Deleting a folder, group, smart group, or system object . . . . . . . . . . . . . . . . . . . . . 96
Properties, Permissions, and Audit Trail tab group . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Properties view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Permissions view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Audit Trail view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Viewing dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Importing and exporting BMC BladeLogic objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Exporting objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Importing objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Chapter 5 Properties 117

Using the Property Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Understanding custom property classes and instances. . . . . . . . . . . . . . . . . . . . . 120
Adding a custom property class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Adding or modifying properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Creating or modifying an instance of a property class . . . . . . . . . . . . . . . . . . . . . 129
Removing or deprecating a property, custom property class, or instance . . . . . 131
Using PropertySync to import and export properties . . . . . . . . . . . . . . . . . . . . . . 132
Viewing and modifying properties for property classes . . . . . . . . . . . . . . . . . . . . 137
Setting values for system object properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Changing property values for one or more system objects . . . . . . . . . . . . . . . . . . . . . 141
Inserting a parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Chapter 6 Managing access 145

Understanding authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Role-based authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Object-based authorizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Resource-based authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Effective authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Managing authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Set up authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Create authorization profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Create ACL templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Create ACL policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Create automation principals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Create roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Create users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Assign object-based permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Update permissions for multiple objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Enforcing authorizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
No access nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Managing audit trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Built-in roles and users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
RBACAdmin and BLAdmin users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Setting up authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Adding or modifying an nexec command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Deleting an nexec command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Defining audit trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Creating an authorization profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Modifying authorization profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Creating an ACL template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Template Access Control List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Modifying ACL templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Creating an ACL policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Policy Access Control List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Contents 7
Modifying ACL policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Creating and modifying maintenance windows. . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Creating automation principals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Modifying automation principals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Using server properties to map automation principals . . . . . . . . . . . . . . . . . . . . . 172
Creating roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Agent ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Modifying Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Creating users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
General information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Role selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Modifying users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Synchronizing users with Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Using object-based permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Defining permissions for a system object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Updating permissions for one or more system objects . . . . . . . . . . . . . . . . . . . . . 190
Avoiding common mistakes while using permissions. . . . . . . . . . . . . . . . . . . . . . 191
Using agent ACLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Windows user mapping and agent ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Previewing and pushing agent ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Creating ACL Push Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Default Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Modifying ACL Push Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Using the bladduser utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Creating users without using RBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Creating users in bulk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Chapter 7 Using the Servers folder 207

Properties and servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Editable intrinsic properties for servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Updating server properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Creating Update Server Properties Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Modifying Update Server Properties Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Organizing servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Adding a server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Adding a server using the BMC BladeLogic console . . . . . . . . . . . . . . . . . . . . . . . 222
Importing servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Assigning servers to server groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Assigning a server to a server group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Moving or copying a server between server groups . . . . . . . . . . . . . . . . . . . . . . . 227
Removing a server: decommissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Browsing servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Contents of the Live node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Managing server objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Copying and pasting files and directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Deleting files and directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Starting and stopping services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Viewing server objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Using custom configuration objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Executing custom commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Chapter 8 Components and component templates 243

Process for using components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Component requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Component design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Component discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Component usage implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Organizing components and component templates . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Creating a component template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Editing a component template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Discover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Browse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Snapshot/Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Local properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Local configuration objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Creating Component Discovery Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Component Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Contents 9
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Modifying Component Discovery Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Adding components to servers manually. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Compliance exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Modifying components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Validating a component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Setting multiple components as exceptions to compliance rules . . . . . . . . . . . . . . . . 309
General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Associated compliance rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Adding components to a component group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Creating Compliance Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Component templates for filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Auto-remediation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Default notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Modifying Compliance Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Viewing and using compliance results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Compliance statuses of compliance rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Viewing compliance results by rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Viewing compliance results by server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Viewing the results of a compliance rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Editing a compliance rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Defining exceptions for components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Viewing and using auto-remediation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Undoing auto-remediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Manually remediating compliance results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Creating a remediation package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Packaging and deploying a component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Exporting compliance results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Using component templates to ensure compliance for multiple instances of an
application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Chapter 9 Creating packages and other depot objects 349

Organizing depot content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Overview of software packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Overview of BLPackages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Adding software to the Depot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Add Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

Adding a hotfix to the Depot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Add Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Modifying a software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Matching software with depot items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Adding a BLPackage to the Depot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Package Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Package Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Package Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Editing a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Opening a BLPackage to edit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Changing object attributes in a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Adding a local property to a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Moving an object within a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Ordering software within a BLPackage by dependency . . . . . . . . . . . . . . . . . . . . 397
Deleting an object in a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Providing password information in a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . 398
Finding and replacing text in a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Adding a custom action to an asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Importing assets into a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Creating an RPM group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Adding an external command to a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Commenting out assets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Verifying assets in a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Closing the BLPackage editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Adding a Network Shell script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Script Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Modifying a Network Shell script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Adding files to the Depot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Chapter 10 Managing jobs 413

Organizing jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Properties and jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Managing jobs from the Jobs or Servers folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Opening a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Executing a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Executing a job against specific targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Executing a job against failed targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Defining a job execution override for a role and user . . . . . . . . . . . . . . . . . . . . . . 421
Contents 11
Executing a job with BMC Remedy ITSM approval . . . . . . . . . . . . . . . . . . . . . . . . 422
Managing jobs in progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Using Execution Tasks to manage job runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Creating an Execution Task while executing a job against failed targets . . . . . . 429
Creating and defining an Execution Task manually . . . . . . . . . . . . . . . . . . . . . . . 430
Modifying Execution Task definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Executing a job through an Execution Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Viewing job run information through an Execution Task . . . . . . . . . . . . . . . . . . . 436
Viewing history for a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Viewing job activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Viewing the status of a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Checking job status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Viewing job status for change management approval jobs . . . . . . . . . . . . . . . . . . 439
Viewing the job definition of a job run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Viewing job logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Exporting job logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Viewing job schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Avoiding problems with hung jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Defining time-outs for jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Updating server status before running a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Chapter 11 Snapshot Jobs 449

Snapshot and audit basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Symbolic links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Snapshot storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Creating Snapshot Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Components Templates for Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Server Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Modifying Snapshot Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Viewing snapshot and change tracking results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Differentiating between internal and external changes . . . . . . . . . . . . . . . . . . . . . 468
Backing out of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Viewing the changes using the Compare Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Showing deploy activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Bundling snapshot results into a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Adding software to the depot from snapshot results . . . . . . . . . . . . . . . . . . . . . . . 471
Exporting the results of an audit or snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Chapter 12 Audit Jobs 475

Creating Audit Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Component Templates for Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

Masters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Server Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Modifying Audit Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Viewing audit results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Viewing audit results by object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Viewing audit results by server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Viewing differences between text files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Understanding audit results for configuration files. . . . . . . . . . . . . . . . . . . . . . . . 498
Grouping non-compliant servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Using audit results to synchronize servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Sync Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Package Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Packaging audit results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Package Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Package Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Chapter 13 File Deploy Jobs 505

Deploying files and directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Advanced Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Modifying File Deploy Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Chapter 14 Software and BLPackage Deploy Jobs 521

Phases of a Deploy Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Simulate phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Staging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Commit phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Deploy Job states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
Basic and advanced BLPackage Deploy Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Deploying a software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Deploying a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Caveats for deploying BLPackages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Contents 13
Phases and Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Job Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Phase Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Modifying Deploy Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Limitations for Windows security settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Uninstalling software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Using the results of a Deploy Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Performing actions on a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Performing actions on a server or phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Undoing a Deploy Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Rebooting servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Controlling server behavior for Deploy Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Designating servers that cannot be targeted by Deploy Jobs . . . . . . . . . . . . . . . . 564
Configuring the location of the transactions directory. . . . . . . . . . . . . . . . . . . . . . 564
Using NFS to mount a location while running single-user mode . . . . . . . . . . . . 565
Chapter 15 Network Shell Script Jobs 567

Creating Network Shell Script Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Modifying Network Shell Script Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Chapter 16 Batch Jobs 579

Creating Batch Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Batch Job Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Modifying Batch Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Chapter 17 Managing virtual environments 591

Working with Virtual Machines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Support for virtual environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Browsing a Virtual Machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Contents of the Live node in virtual environments . . . . . . . . . . . . . . . . . . . . . . . . 593
Running Snapshot Jobs and Audit Jobs on hosts . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Managing a VMware environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Discovering Virtual Machines in a VMware environment . . . . . . . . . . . . . . . . . . 596

Browsing VMware Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Managing VMware Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Viewing vCenter server properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Adding a new Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Remediating a Virtual Machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Managing a Solaris Zones environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Browsing Solaris Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Managing Solaris Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Managing an IBM Frame environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Browsing IBM Frame Virtual Machines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Managing IBM LPARs on the frame. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
Managing a Microsoft Hyper-V environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Browsing Hyper-V Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Managing Microsoft Virtual Machines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Managing virtualization sprawl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Identifying virtual sprawl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Creating the server lifecycle properties mapping file . . . . . . . . . . . . . . . . . . . . . . 620
Chapter 18 Administrative tools 623

Administering custom commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Creating or modifying a custom command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
Deleting a custom command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Using the Configuration Object Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Adding a custom configuration object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Identifying configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Creating extended objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
Deleting a custom configuration object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Using jobs to manage custom configuration objects . . . . . . . . . . . . . . . . . . . . . . . 641
Creating a Distribute Configuration Objects Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Selected Configuration Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Modifying Distribute Configuration Objects Jobs . . . . . . . . . . . . . . . . . . . . . . . . . 648
Creating an Upgrade Model Objects Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Selected Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
Modifying Upgrade Model Objects Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
Creating a Deregister Configuration Object Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
Selected Configuration Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Contents 15
Schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Modifying Deregister Configuration Object Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . 663
The Infrastructure Management window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Getting information about Application Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
Reporting Application Server information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
Getting information about PXE servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
Getting information about the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Setting up communications with remote servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
Creating SOCKS proxy server objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
Creating rules for routing to remote servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Adding remote servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
Managing SOCKS proxy servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Viewing and editing proxy server properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Deleting proxy server objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Checking the status of a SOCKS proxy server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Assigning SOCKS proxy servers to a routing rule . . . . . . . . . . . . . . . . . . . . . . . . . 674
Configuring servers to use repeaters during deployments . . . . . . . . . . . . . . . . . . . . . 675
Creating repeater server objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Creating rules to determine the repeater used for target servers . . . . . . . . . . . . . 677
Assigning repeaters to target servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Managing repeater servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Viewing and editing repeater server properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Deleting repeater server objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Assigning a repeater server to a repeater routing rule. . . . . . . . . . . . . . . . . . . . . . 681
Enabling/disabling repeater rule evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
Updating a repeater server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
Creating rules to determine Application Servers to use for job execution . . . . . . . . 683
Enabling/disabling job routing rule evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Creating complex routing rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Managing routing rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Viewing and editing routing rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Routing rule evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Changing the order of rule evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Deleting routing rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Troubleshooting tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Chapter 19 Patch management for Microsoft Windows 691

Defining permissions for the patch catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Defining global configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Viewing published patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
Defining an online patch catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Defining an offline patch catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Viewing the catalog on the BMC BladeLogic Console . . . . . . . . . . . . . . . . . . . . . . 711
Grouping catalog contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Maintaining an existing catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Creating a patching job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

Viewing results of a patching job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
Remediating servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Viewing remediation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Deploying patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Deploying patches for Microsoft Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Patch reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
Chapter 20 Patch management for Solaris 725

Best Practice Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Defining global configuration parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
Viewing published patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Defining an online patch catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
Defining an offline patch catalog for Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
Defining an offline catalog for Fujitsu Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
Creating the patch catalog on the BMC BladeLogic Console . . . . . . . . . . . . . . . . 743
Viewing the catalog on the BMC BladeLogic Console. . . . . . . . . . . . . . . . . . . . . . 747
Maintaining an existing catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
Patch Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Chapter 21 Patch management for Red Hat Enterprise Linux 759

Defining an online patch catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Defining an offline patch catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Viewing the catalog on the BMC BladeLogic Console. . . . . . . . . . . . . . . . . . . . . . 782
Maintaining an existing catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
Patch reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793
Chapter 22 Patch management for SUSE Linux Enterprise 795

Defining a patch catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800
Contents 17
Viewing analysis results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815
Remediating servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817
Patch Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821
Chapter 23 Patch management for Oracle Enterprise Linux 823

Defining global configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825
Viewing published patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827
Defining a patch catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828
Remediating servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846
Patch reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
Chapter 24 Provisioning basics 851

Supported operating systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Understanding provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852
Provisioning Windows and Linux servers: PXE environment . . . . . . . . . . . . . . . 853
Provisioning Solaris servers: JumpStart environment . . . . . . . . . . . . . . . . . . . . . . 856
Provisioning AIX servers: NIM environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858
Provisioning HP-UX servers: Ignite environment . . . . . . . . . . . . . . . . . . . . . . . . . 860
Integrated provisioning and server management. . . . . . . . . . . . . . . . . . . . . . . . . . 862
Overview of the provisioning process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862
Part one: preliminary setup (PXE, JumpStart, NIM, Ignite) . . . . . . . . . . . . . . . . . 863
Part two: running the provisioning process (PXE) . . . . . . . . . . . . . . . . . . . . . . . . . 864
Part two: completing the provisioning process (JumpStart, NIM, Ignite). . . . . . 864
Chapter 25 Provisioning servers 867

Creating boot image files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868
Boot image files and placeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
Creating a WinPE 2.x boot image file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869
Creating a WinPE 1.6 image file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
Creating a Gentoo Linux image file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898
Using the Skip Linux Pre-Install image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
Obtaining a DOS image file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902

Configuring provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 902
Configuring the data store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
Creating custom system package types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Changing the location of installation files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Configuring the PXE server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Configuring the TFTP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
Starting and stopping the PXE server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Starting and stopping the TFTP server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918
Configuring boot image files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Including a Batch Job in a system package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
Creating a system package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Defining settings for Windows servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927
Pre-Install Scripts Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
Disk Partition Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929
Post-disk partition Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
Basic configuration Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931
Computer Settings Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933
OS components Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 940
Network Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
Unattend entries Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943
Post-install configuration Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946
Local properties Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948
Defining settings for Linux servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948
Pre-install scripts Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949
Disk partition Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949
Basic configuration Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951
Computer settings Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952
OS components Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953
Network Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954
Kickstart entries Red Hat Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955
AutoYaST entries SUSE Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956
Post-install configuration Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958
Local properties Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959
Defining settings for ESX servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960
Pre Install Script ESX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961
Disk Partition ESX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962
Basic configuration ESX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964
Computer Settings ESX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
Network ESX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966
Kickstart Entries ESX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967
Post-Install Configuration ESX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
Local properties ESX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
Defining settings for Solaris servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971
Disk partition Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972
Basic configuration Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974
Computer settings Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975
Network Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976
Package specifications Solaris. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978
Additional sysidcfg entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
Contents 19
Additional profile entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979
Add Install Client Script Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
Rules File Script Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980
Begin Script Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981
Finish Script/Agent Install Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982
Reboot Script Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983
x86 Parameters Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984
Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
Local Properties Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986
Defining settings for AIX servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
Basic configuration AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987
Target disk AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
Localization settings AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
Network Config AIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991
Agent Install/First boot script AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992
Local properties AIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
NIM scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
Control flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995
Optional Bosinst Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
Pre Machine Definition Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
Pre bos_inst Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996
Post bos_inst Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
Defining settings for HP-UX servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997
Basic configuration HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998
Disk partition HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Computer settings HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 999
Network settings HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1000
Ignite Commands/Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1001
Ignite parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
Software selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
Boot script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003
Post-install config HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003
Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004
Local properties HP-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004
Organizing system packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005
Folders, access control, and system package sharing: an example. . . . . . . . . . . 1005
Importing and exporting system packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
Working with manually imported devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
Manually importing a device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007
Manually importing a list of devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1011
Device Smart Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
Monitoring the provisioning status of servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
Viewing imported devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019
Viewing provisioned servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
Viewing device information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
Viewing and changing device properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1021
Viewing a servers provisioning history. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022
Viewing a system packages provisioning history . . . . . . . . . . . . . . . . . . . . . . . . 1023

Classifying servers as provisioned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
Deleting servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023
Creating a Provision Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025
Choose Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1026
System Package Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
Select Image (PXE only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
System Package Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027
Basic Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028
Network Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1029
Provisioning Summary (multiple servers only) . . . . . . . . . . . . . . . . . . . . . . . . . . 1029
Optional Bosinst Attributes (NIM only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030
Begin Script (JumpStart only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030
Post-install Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1030
Provisioning Job Settings (PXE only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1031
Server ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
Server Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
Managing Provision Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1032
Executing a Provision Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
Viewing the results of a Provision Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
Canceling a Provision Job in progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035
Viewing and editing a Provision Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036
Changing the devices for a Provision Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037
Scheduling a Provision Job for execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
Setting up default notification of job completion . . . . . . . . . . . . . . . . . . . . . . . . . 1040
Viewing the log for a Provision Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041
Exporting the log for a Provision Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1041
Re-provisioning servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1042
Provisioning Windows 2003 or 2008 servers from a local data store . . . . . . . . . . . . 1044
Creating the WinPE 2.x image for booting from local media . . . . . . . . . . . . . . . 1045
Creating the WinPE 2.x image for booting from the PXE server . . . . . . . . . . . . 1048
Creating a system package for use with a local data store . . . . . . . . . . . . . . . . . 1048
Associating the LocalDataStore instance with the system package. . . . . . . . . . 1051
The CONFIG_STORE property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052
Provisioning Solaris servers using a WAN boot installation . . . . . . . . . . . . . . . . . . 1052
Provisioning target servers with ESXi 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055
Properties and provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
Device Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
System package properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
Streamlining the wizard with parameterized properties: an example . . . . . . . 1058
Inserting a parameter in a system package field. . . . . . . . . . . . . . . . . . . . . . . . . . 1059
System package fields that accept property references . . . . . . . . . . . . . . . . . . . . 1059
Using properties to reference scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
Data store instance properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064
Data Store Instances and provisioning strategies . . . . . . . . . . . . . . . . . . . . . . . . . 1064
Contents 21
Appendix A System authorizations 1067
Appendix B Intrinsic properties 1087
Appendix C Security settings for Windows 2008, 2003, and 2000 1099
Appendix D Content format 1105

Packaging content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105
Overview of content format XML files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105
Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
Grammars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1107
Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1108
Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1109
Data instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
Rule library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113
Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1114
Service instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117
Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1118
BMC BladeLogic Glossary 1121
Index 1139

Chapter
1
1 Introduction
BMC BladeLogic Server Automation (referred to in this guide as BMC BladeLogic)
lets IT organizations automate the management of enterprise-class data centers.
Using BMC BladeLogic, 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, share routine server management tasks between
functional teams in an organization, and perform many other data center automation
tasks.
BMC BladeLogic 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 RSCD agent so BMC
BladeLogic can manage the server and then run a BMC BladeLogic job to install
software and perform additional configuration on the machine.
System administrators can also take advantage of many virtualization features in

BMC BladeLogic. Virtualization provides a one-to-many capability for managing
virtual infrastructure, including VMWare ESX and Virtual Center servers and all
virtual configuration information for all virtual machines hosted by ESX servers.
BMC BladeLogic lets you manage servers and applications with a consistent user
experience, regardless of whether they are physical or virtual.
Together, the capabilities of BMC BladeLogic let you manage the complete life cycle
of data center servers. The BMC BladeLogic suite of tools can boost the efficiency of
seasoned system administrators while at the same time providing an interface
suitable for operations managers and junior system administrators.
All BMC BladeLogic capabilities are available on multiple operating systems.
Application Automation
Application Automation
Another application used in conjunction with BMC BladeLogic Server Automation is
BMC BladeLogic Application Automation. This application lets IT organizations
automate the process of application updates across work groups, resulting in
shortened release cycles and system-wide alignment of application configurations.
You can use Application Automation to ensure that application configurations are
consistent across varying environments such as development, QA, staging, and
production. All deployment actions can be authorized based on user roles, ensuring
appropriate levels of user access. If necessary, you can easily roll back problematic
deployments. With Application Automation, the deployment of applications can be
automated, even for complex, multi-tier changes, such as sequenced updates of web,
application, and database servers.
Overview of this guide

This guide contains the following chapters:
Chapter 2, Overview of BMC BladeLogic Server AutomationProvides a

general description of the BMC BladeLogic architecture and a brief introduction to
some of its basic functionality.
Chapter 3, Getting startedDescribes the tasks necessary to start the BMC

BladeLogic console the first time after installation and for all subsequent sessions.
Chapter 4, Using the BMC BladeLogic Server Automation consoleIntroduces

the BMC BladeLogic console and describes procedures that are common
throughout.
Chapter 5, PropertiesDescribes the Property Dictionary and how properties

are applied to servers, jobs, users, and other assets throughout BMC BladeLogic.
Chapter 6, Managing accessExplains how to use authorizations to control

access to all objects within a BMC BladeLogic system.
Chapter 7, Using the Servers folderExplains how to use the Servers folder to
add servers to those managed with BMC BladeLogic. This chapter also provides
many procedures for organizing servers and the server objects they contain. A
server object is a file, package, registry value, or other asset that a server holds.
Chapter 8, Components and component templatesDescribes how to create and

manage components, which provide a mechanism for organizing server objects into
collections that model logical assets, such as applications, middleware
components, and other assemblies. With components you can manage assemblies
rather than the server objects that make up those assemblies.

Overview of this guide
Chapter 9, Creating packages and other depot objectsExplains how to use the
Depot folder to create deployable packages of Windows and UNIX software and
complex packages of server objects and software assets, known as BLPackages. This
chapter also explains how to store files and Network Shell scripts in a central
repository called the Depot.
Chapter 10, Managing jobsExplains how to perform a variety of job-related

tasks in the Jobs folder.
Chapter 11, Snapshot JobsExplains how to create jobs that record server
configurations in snapshots and how to use those snapshots.
Chapter 12, Audit JobsExplains how to compare server configurations using

audits and how to correct the configurations of servers that do not match your
standard configurations.
Chapter 13, File Deploy JobsExplains how to create jobs that deploy files and
directories.
Chapter 14, Software and BLPackage Deploy JobsExplains how to create jobs
that deploy software packages and BLPackages.
Chapter 15, Network Shell Script JobsExplains how to create jobs that execute
Network Shell scripts.
Chapter 16, Batch JobsExplains how to create jobs that aggregate a series of
other jobs (for example, Deploy Jobs, File Deploy Jobs, and Network Shell Jobs).
Chapter 17, Managing virtual environmentsExplains how to perform basic ad-

hoc actions on virtual machines in their environment as well as more complex
management tasks such as deploying applications to a virtual machine and
controlling virtualization sprawl.
Chapter 18, Administrative toolsDescribes how to define commands that can

be executed on remote servers, identify configuration files, create custom
configuration objects and extended objects, and perform other types of
administrative tasks.
Chapter 19, Patch management for Microsoft WindowsExplains how to

monitor and remediate server patch configurations on Windows.
Chapter 20, Patch management for SolarisExplains how to monitor and

remediate server patch configurations on Solaris.
Chapter 21, Patch management for Red Hat Enterprise LinuxExplains how to
monitor and remediate server patch configurations on Red Hat Enterprise Linux.
Documentation conventions
Chapter 22, Patch management for SUSE Linux EnterpriseExplains how to

monitor and remediate server patch configurations on SUSE Linux.
Chapter 23, Patch management for Oracle Enterprise LinuxExplains how to

monitor and remediate server patch configurations on Oracle Enterprise Linux.
Chapter 24, Provisioning basicsProvides a general description of how the

BMC BladeLogic provisioning solution works, including an overview of the tasks
needed to set up and use a provisioning system.
Chapter 25, Provisioning serversExplains how to use BMC BladeLogic to

provision servers.
Documentation conventions
Procedural descriptions
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 sub-option 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 => Sub-option rather than saying select Main Option
and then select Sub-option.
Windows and UNIX paths

When describing paths, this guide uses UNIX-style path separators (forward slashes)
except in situations where Windows-style path separators (back slashes) are
specifically required.
Multiple approaches
When you perform a task in BMC BladeLogic, multiple approaches are usually
possible. You can use menu options, tool bar icons, or pop-up menus to achieve the
same goals. Typically, BMC BladeLogics documentation describes only one
approach, usually involving the use of pop-up menus.

System text
System text
Monospace fonts depict text that a user might enter at the command line or text that a
system generates in response to user input. The following is an example of system
text:
ERROR: You must be "root" for pkgadd to execute properly.
System text

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

automating their management.
Network ShellA cross-platform shell with full scripting capability that gives
seamless access to remote servers from central management workstations.
RSCD agent (short for Remote System Call Daemon)Software that must be
installed and running on each remote server that BMC BladeLogic accesses.
Application ServerSecure, scalable software for controlling how BMC

BladeLogic components communicate with remote servers and databases. Also
used during initial provisioning of servers.
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.
BMC BladeLogic Command Line Interface (BLCLI)A set of utilities that allow
you to perform most BMC BladeLogic tasks from a command line.

System architecture
System architecture
A BMC BladeLogic 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 BladeLogic system.
BMC BladeLogic
reports
Network
Client
BLCLI client Tier
console Shell
(web browser)
PXE / TFTP Application Network Shell

reports server
Server Server(s) Proxy Server
(optional) Middle
Tier
BMC BladeLogic reporting data
core database warehouse
Agent
File
Server
Server
Tier
Agent Agent Agent Agent Agent

Remote Remote
Server Server Server Server Server Server Server

Client tier
Client tier
The BMC BladeLogic client tier includes the BMC BladeLogic console, a command
line interface (BLCLI) that provides API-level access to the functionality available
through the console, and Network Shell for ad hoc administration of one or more
servers. It also includes a web interface to the BMC BladeLogic Decision Support for
Server Automation server.
The BMC BladeLogic console is a graphical user interface that gives system
administrators a host of sophisticated tools for managing and automating data center
procedures. It also lets system 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 BladeLogic client-tier applications
let you manage Solaris, Linux (Red Hat and SUSE), AIX, HP-UX, and Microsoft
Windows 2000/2003/2008 servers.
Middle tier
The primary component of the middle tier is the Application Server, which controls
how the BMC BladeLogic console communicates with remote servers. Not only does
the Application Server manage communication between consoles and remote servers,
it also controls interaction with the database and file servers. The Application Server
is completely scalable, allowing administrators to adjust its performance to
accommodate added users and increased database activity. If necessary, a BMC
BladeLogic system can incorporate multiple Application Servers that cooperate by
balancing job processing workloads.
The middle tier also includes several components used for provisioning servers, with
the principal components being the PXE Server and the Application Server. The PXE
Server delivers instructions to servers being provisioned so they can download a
bootstrap program. The Application Server provides servers being provisioned with
the instructions necessary to provision the machine.
If a site is running BMC Service Automation Reporting and Analytics, the middle tier
includes an Apache Tomcat server. BMC Service Automation Reporting and
Analytics uses the Application Server to authenticate users, and it reads data from the
core BMC BladeLogic database as well as a reporting data warehouse. The reporting
data warehouse is populated using information from the core BMC BladeLogic
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
Server tier
The BMC BladeLogic 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 BladeLogic component.
Access control
In BMC BladeLogic, the objects you interact with are called system objects. Servers,
jobs, and system packages are examples of system objects. Throughout the system,
BMC BladeLogic uses role-level and object-level authorizations that grant
permissions to perform actions on system objects.
In BMC BladeLogic, 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
read certain server objects, such as files, while a senior administrator role might be
given full authorization to create and modify those server objects. 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 every
system object in BMC BladeLogic. To take an action on any system object, you must
have role level authorization as well as 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 allow you to make fine-
grained decisions about access to objects throughout your system.
The BMC BladeLogic Application Server enforces access to system objects throughout
the BMC BladeLogic console. After role-level authorizations and server permissions
have been defined, you can push that information to an agent on a remote server.
There 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.

Security
Security
BMC BladeLogic provides multiple levels of security, ranging from unrestricted
communication between management consoles and remote servers to security
models that incorporate the strongest available security mechanisms, such as
public/private key exchange using X.509 certificates and Kerberos-based
authentication. For more information on BMC BladeLogic security, see the BMC
BladeLogic Server Automation Administration Guide.
Using BMC BladeLogic A brief overview

The BMC BladeLogic console provides the following main functional areas, known as
folders. These folders are:
Servers
Component templates
Components
Depot
Jobs
RBAC Manager
Together these folders give you the tools to define access to objects in the BMC
BladeLogic system and then manage and automate day-to-day activities throughout
the data center.
All folders except RBAC Manager let you organize system objects into folder, 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 Patch
Analysis Jobs.
Servers
The Servers folder lets you browse all 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 every
job. From the Servers folder you can initiate many actions based on servers or server
objects.

Components
Components
The Components folder provides a central location for managing components. Using
the Components folder, you can organize components, run various jobs on
components, and change the properties and permissions of a component.
Component templates
The Component Templates folder lets you 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 rather than the server objects that make up those
applications or policies. For example, a component can specify the 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.
Depot
Using the Depot folderalso known as the Depotyou can store objects you may
need, such as files, Network Shell scripts, hotfixes, and software packages. You can
also store BLPackages, which are aggregations 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.
Jobs
The Jobs folder lets you create and store all the jobs you use to perform tasks in BMC
BladeLogic. In the Jobs folder you can create the following types of jobs:
ACL PushConverts the permissions defined for a server into entries in an access
control list and copies the ACL to the agent on that server.
Atrium ImportTransfers business service data from a BMC Atrium

Configuration Management Database to the BMC BladeLogic database.

RBAC Manager
AuditDetermines whether server configurations match a standard configuration

and provides a mechanism for automatically correcting any discrepancies.
BatchRuns a concatenated series of other jobs on remote servers.
ComplianceCompares component parts to compliance rules defined in a

component template and provides a mechanism for remediating any
discrepancies.
Component DiscoveryAssociates components with servers that match signature

conditions you define for each component template.
DeployDeploys BLPackages and software installables to remote servers without

requiring any user interaction.
Deregister Configuration ObjectsRemoves implementation files for custom

server objects from servers.
Distribute Configuration ObjectsDistributes implementation files for custom

server objects to servers where you want to use these objects.
File DeployDeploys files and directories to remote servers.
Network Shell ScriptRuns a Network Shell script on one or more remote servers.
Patching A patching job performs patch analysis on a group of target servers

based on a patch catalog.
SnapshotRecords the configuration of a group of server objects at a point in time.
Update Server PropertiesObtains the most recent information about a server and
uses it to update server properties.
Upgrade Model ObjectsUpgrades 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.
RBAC Manager
The RBAC Manager folder lets you define sets of permissions, known as roles, and
then assign users to those roles. In this way you can authorize actions for whole
classes of users, such as junior administrators or system architects. Using the RBAC
Manager folder, you create roles and users. You can also define authorization
profiles, which are collections of individual authorizations, specify the actions that

RBAC Manager
should be recorded in audit trails, create ACL templates, which are sets of role-based
permissions that you can apply to system objects, and define ACL policies, which let
you manage a group of authorizations in a single location that automatically apply to
multiple system objects.

Chapter
3
3 Getting started
When you use the BMC BladeLogic console to log in, the login process first connects
to the BMC BladeLogic Authentication Service, which is a service dedicated to
validating user identities. The Authentication Service is implemented as a service
within the BMC BladeLogic Application Server. Processing login requests for all
authentication protocols, the Authentication Service examines user credentials, such
as IDs and passwords, to determine whether a user is valid.
If the Authentication Service successfully authenticates you, it generates a session

credential and delivers the credential back to the BMC BladeLogic console. A session
credential validates you as a legitimate user for a finite period of time. When you log
in, 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
BladeLogic.
BMC BladeLogic uses TLS and X.509 certificates to secure communication between all
of its components. BMC BladeLogic Application Servers generate their own self-
signed X.509 certificates. The first time you use the BMC BladeLogic 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 have trusted is added to a
keystore, which holds all the certificates that the BMC BladeLogic console has chosen
to trust.
When you communicate with the same Application Server in the future, the
Application Server again presents its certificate. This time, however, BMC BladeLogic
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 any user tries to log into BMC BladeLogic, there are certain preliminary steps
that should be performed (see Preparing for user logins on page 38).

Preparing for user logins
Preparing for user logins

Before a user can log in, you must first create one or more authentication profiles, which
are collections of information needed to conduct logins. An authentication profile
specifies the authentication mechanism that should be used during a login, 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.) Typically a BMC BladeLogic administrator creates an
authentication profile for each combination of Application Server and authentication
mechanism, such as QAServer1SRP or DevServerADK. For more details on
authentication profiles, see Setting up an authentication profile on page 38.
Before you attempt to log in, you should confirm that your user name is included in
BMC BladeLogics 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 BladeLogic. For more information on RBAC, see Access control
on page 32.
After you have satisfied these prerequisites, you can log into the BMC BladeLogic
console (see Starting the BMC BladeLogic console on page 40). The login dialog lets
you view or delete certificates and session credentials used during the login process
(see Viewing or deleting stored certificates on page 45). Once you log into the BMC
BladeLogic console, it is easy to switch roles if your user identity has been assigned to
multiple roles (see Switching roles on page 46). You can also easily switch SRP
passwords (see Changing passwords on page 47).
Setting up an authentication profile

Use this procedure to set up an authentication profile, which is a collection of
information that the system uses to conduct a login session with the BMC BladeLogic
Authentication Service. The Authentication Service is a service implemented within
the BMC BladeLogic Application Server. The Authentication Service is responsible
for authenticating users and issuing session credentials. When you log into the BMC
BladeLogic 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 BladeLogic provides SRP authentication. See
the BMC BladeLogic Server Automation Administration Guide for information on
configuring all types of authentication.

Setting up an authentication profile
1 To open the login window for the BMC BladeLogic console, do one of the
following:
On Windows, do one of the following:
From the Start menu, select Programs => BMC Software => BladeLogic Server
Automation Suite => Server Automation Console releaseNumber.
From the directory where BMC BladeLogic is installed (for example,

C:\Program Files\BMC Software\BladeLogic\version\CM), enter:
.\rcp\launcher.exe
If you have more than one version of the client installed, you can find them in
directories called BladeLogicN, such as BladeLogic2.
On a UNIX-style system, from the directory where BMC BladeLogic is installed

(for example, /opt/bmc/BladeLogic/version), enter:
./rcp/launcher.sh
2 On the login 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 opens.
It provides the same fields as the Edit Authentication Profile dialog.
5 On the Authentication Profile dialog, enter values for the following:
Profile NameThe name you are assigning to this authentication profile. For
example, you could assign a name such as QAServer1SRP or DevServerADK.
Application ServerThe name or IP address of the Application Server to which

the client should connect.
Authentication PortThe port where the client should connect to the

Authentication Service. The same port is used for all BMC BladeLogic
authentication mechanisms.

Starting the BMC BladeLogic console
Authentication MethodChoose the authentication mechanism for this

authentication profile 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 on distinguished name templates, see the BMC

Select RSA SecurID Authentication.
Select Public Key InfrastructureAuthentication.
6 Click OK.

Use this procedure to log into the BMC BladeLogic console. Only users who have
been granted access to BMC BladeLogic can log in. For more information on how
users are granted access, see Access control on page 32.
To log in, you must specify an authentication profile, which is a collection of

information that a BMC BladeLogic client uses to conduct a login session. For more
on creating authentication profiles, see Setting up an authentication profile on
page 38. Using an authentication profile, you obtain a session credential from the
Authentication Service. BMC BladeLogic client applications use a session credential
to establish a secure connection with the BMC BladeLogic Application Server. This
procedure explains how to obtain a valid session credential. If you already have a
valid session credential, this procedure explains how to use it to start the BMC
BladeLogic console and establish a connection with the Application Server.
As part of this procedure you can choose whether to cache your session credential. By
default, session credentials are not cached. If a valid session credential is cached,
when you use a BMC BladeLogic client application again, you do not have to
authenticate. Session credentials remain valid for a configurable amount of time. See
the BMC BladeLogic Server Automation Administration Guide for more details on
configuring this aspect of the Authentication Service. By default session credentials
expire after 10 hours.

When you attempt to log in, you may encounter a security message warning that the
Application Server has presented BMC BladeLogic with an untrusted certificate.
Application Servers always use self-signed certificates, so typically this happens the
first time you try to connect to a particular Application Server. If you encounter this
type of warning, you should ideally examine the certificate before choosing to trust it.
Once you trust it, the certificate is added to your keystore of trusted certificates and
you should not encounter this warning again when connecting to the same
Application Server.
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 being asked to trust to items in the trusted list.
1 To open the BMC BladeLogic login dialog, do one of the following:

.\rcp\launcher.exe

./rcp/launcher.sh
A login dialog displays. The appearance of the dialog 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 the authentication profile you should
use.
If you have a valid cached session credential, skip this step.

If you are using ADK or PKI authentication, skip this step.
If you 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.
If you are using Domain Authentication, enter your user name and domain. The
domain name must always be capitalized. You do not have to enter a domain
name if you are defined as a member of the default realm. For information on
how to set up the default realm for Domain Authentication, see the BMC
4 To change the setting for caching session credentials or the display language, do
the following:
A Click Options. The login window expands to show additional options in a

tabbed format. By default the General tab is open.
B Check Save credential for this session if you want to save a session credential
between sessions.
By default this option is not checked. Your setting for this option remains in
effect for future logins until you change this setting. This option is dimmed if a
session credential is already cached.
C For Language, the User Preference item in the list represents your personal
choice of language (either your previous choice or your acceptance of the
installation default). Select a new display language for the console or keep your
current user preference. Your selection remains in effect as your default
language for future logins until you make a new choice. See the BMC BladeLogic
Server Automation Installation Guide for more information.
5 Click Connect.
If the Application Server presents the BMC BladeLogic console with an X.509
certificate that is not trusted, a security alert displays. Most Application Servers
use self-signed certificates, so typically you encounter this dialog the first time you
access a particular Application Server.
6 If a security alert is not displayed, skip this step. If a security alert describes an
untrusted certificate, do one of the following:
Click No to return to the login dialog. You can cancel the login session or use a
different authentication profile to log in.
Click Yes to accept the unknown certificate and proceed with the login.

Viewing an untrusted certificate
Click View Certificate to examine details about the certificate. For more
information on this procedure, see Viewing an untrusted certificate on
page 43. After examining the certificate, click Yes or No, as described above.
7 If you have multiple roles associated with your user name, the Assume Role dialog
displays. From this dialog, 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 46.)
8 Click OK. The BMC BladeLogic console displays.
NOTE
When the console starts, by default it loads certain types of information by running an
operation in the background. The Show background operations icon in the lower right
corner of the console indicates a background process is running. For more
information on background processes, see Running operations in the background
on page 67.
Viewing an untrusted certificate

In certain situations, when you attempt to log into BMC BladeLogic, a security dialog
displays, warning that you have been presented with an untrusted certificate. In most
situations 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.
When you encounter this security warning, BMC BladeLogic recommends that you
examine the certificate. If the details of the certificate indicate it should be trusted,
accept the certificate. Once 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.
1 Log into BMC BladeLogic, as described in Starting the BMC BladeLogic console
on page 40. When you click Connect, a Security Alert dialog displays if the
Application Server is presenting a certificate that the client application does not
trust.
2 Click View Certificate.
The Certificate dialog opens, showing the General tab. This tab shows who issued
the certificate and to whom the certificate was issued.

Deleting cached session credentials
3 To obtain more information click the Details tab to see detailed information about
the certificate.
4 Click Close to return to the Security Alert dialog.
5 Depending on your assessment of the certificate, do one of the following:
Click Yes to trust the certificate and continue logging in.
Click No to refuse the certificate and return to the login dialog. You can then
select a different authentication profile and attempt to log in again.
Deleting cached session credentials

The login window for BMC BladeLogic lets you delete valid cached session
credentials. When a BMC BladeLogic 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 onto BMC BladeLogic as a different user, you must first delete any cached
session credentials.
1 Open the BMC BladeLogic login window by doing one of the following:

.\rcp\launcher.exe

./rcp/launcher.sh
2 Click Delete Cached Credentials.

Viewing cached session credentials
Viewing cached session credentials

The login window for BMC BladeLogic lets you view valid cached session
credentials. When a BMC BladeLogic Application Server authenticates you, it
generates a credential for your session, which you can optionally cache. This
credential remains cached until it expires. This procedure lets you view or delete
valid session credentials.

.\rcp\launcher.exe

./rcp/launcher.sh
2 Click Options. The login window expands to show additional options in a tabbed
format.
3 Click the Credential tab. The login window lists any cached sessions displays.
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 credentials expiration date.
5 Click Close to close the Cached Session Credential window.
Viewing or deleting stored certificates

The login window for BMC BladeLogic lets you view or delete a stored certificate.
When you use the BMC BladeLogic console to establish a connection with an
Application Server, you are presented with a certificate. You can choose to trust the
certificate. If you do, the certificate is used for securing the connection with the BMC
BladeLogic client, and the certificate is added to the keystore for client applications.
This procedure shows the list of certificates in that keystore. You can view each
certificate, and you can choose to delete one or more of those certificates.

Switching roles

.\rcp\launcher.exe

./rcp/launcher.sh
2 Click Options. The login window expands to show additional options in a tabbed
format.
3 Click the Certificates tab. The login window lists any certificates in the client
keystore.
4 In the certificates list, select a certificate and do one of the following:
Click Delete. A confirmation dialog displays.
Click View. The Certificate View window opens. This tab shows who issued the
certificate and 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.
Switching roles
Use this procedure to pick a role when you are logging into the BMC BladeLogic
console and have been assigned to multiple roles or when you are already running
the console and you want to change roles. Through RBAC, users can be granted
multiple roles, but a user can only assume one role at a time.

Changing passwords
Log into BMC BladeLogic. If you are assigned to multiple roles the Assume Role
dialog displays.
While running BMC BladeLogic, select Configuration => Switch Role. The
Assume Role dialog displays.
2 From Select Role, choose the role you want to use.
3 Click OK. The servers and other objects displayed in BMC BladeLogic may change
if the new role grants you access to different resources.
Changing passwords
Use this procedure to change your SRP password while running the BMC BladeLogic
console. You can also use the RBAC Manager folder to change passwords. SRP is
BMC BladeLogics default authentication mechanism.
If you attempt to log in with an expired SRP password, the Change Password dialog
displays. Use it to provide a new password, as described below.
1 Select Configuration => Change SRP Password. The Change Password dialog
displays.
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 BladeLogic requires you to enter paths using somewhat different conventions
than are typical for Windows or UNIX.

UNIX
UNIX
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
Windows
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 entering a file path, if you do not specify a disk drive for a Windows machine,
BMC BladeLogic defaults the path to the C drive. For example, BMC BladeLogic
considers the following paths to be the same:
//win2ktest1/winnt
//win2ktest1/c/winnt
Configuration file entries

When entering paths to configuration files on both Windows and UNIX, a double
slash (//) separates the path to the configuration file from the path to any hierarchy
within the file. For example, you might identify a configuration file entry with the
following:

Slashes appearing in values
/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. When you want to enter a
value that includes a slash, you must escape the slash by preceding it with a
backslash. For example, if you need to create the value driver/32, you would enter
driver\/32.
NOTE
The Windows registry is an exception because its path separator is a backslash. If you are
entering a value in a Windows registry path that includes a backslash, you must escape the
backslash by preceding it with a slash. For example, if you need to create a registry value
named C:\winnt, you would enter C:/\winnt.
Trailing slashes
BMC BladeLogic does not support trailing slashes when specifying a folder or
directory.
If you are entering a path to a registry value with a name of empty string (that is, ""),
you can use a trailing slash, as shown below:
HKEY_LOCAL_MACHINE\SOFTWARE\BMC BladeLogic\RSCD Agent\

Trailing slashes

Chapter
4
Using the BMC BladeLogic Server
4
Automation console
BMC BladeLogic contains global menus, simple tool bars, perspectives, views,
objects, and content editors, referred to collectively as the console. The console is
organized and implemented to help you perform the tasks required to provision and
manage your data center in the most efficient way possible. This chapter describes
console elements as well as global capabilities such as import and export and
customizing the interface. If you are new to BMC BladeLogic, you may want to refer
to Managing the BMC BladeLogic console on page 73 for procedures explaining
how to customize the appearance of BMC BladeLogic.
BMC BladeLogic console elements

The console contains standard graphical user interface (GUI) elements. The various
elements can be modified using the Preferences menu (Window => Preferences).

The following figure shows the default view of the product when you log in the first
time. This is called the Classic perspective.
Default Classic perspective
52 BMC BladeLogic Server Automation User Guide

The following shows an exploded figure of the console and its elements. In this figure
a server from the Servers folder in the Folders view on the left is open in the content
editor on the right. The object title, which in the example is a server, appears in a tab
at the top left of the content editor and the tabs at the bottom let you review different
aspects of the server Live Browse, Activity, Snapshot Results, and Audit Results
quickly and easily. The server properties are automatically populated to the
Properties view in the tab group.
Console title bar
Global menu bar
Classic default perspective

Global tool bar Perspective title bar
Folders view Content editor

Content editor tab title
Shortcut toolbar
View tab group

Properties, Permissions, Audit Trail Tasks in Progress view
View tab title View tool bar
Product name

The following table lists the various elements and provides a brief description of
each.
Element Description
BMC BladeLogic console title Identifies the system name, the user, the users role, and the
bar 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 have been
selected and organized for quick and easy 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 79.
global tool bar Contains icons for common actions such as Open, Search,
and Close.

Element Description
Perspective A perspective represents a configuration of views, view tab
groups, and editors. By default, the BMC BladeLogic 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 appears in a tab on the right side
of the console.
Perspectives are configured for certain tasks. For example,

the Classic perspective is configured to make it easy to
perform typical BMC BladeLogic configuration and
provisioning tasks. The Explorer perspective, a pre-
configured 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 on the right as well as in
the drop down list of perspectives making it easy to navigate
between perspectives. You can custom tailor existing
perspectives to suit your work needs.
Perspectives have menus and tool bars for navigating

multiple perspectives, opening, resizing, moving, or closing
perspectives, and changing the look. The system saves any
custom-tailoring you do to perspectives 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 tool bar, and close

the perspective.
For more information, see BMC BladeLogic perspectives

and views on page 60.

Element Description
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 tool
bar 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, 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 single unit or move each view independently of
the others in the tab group.

Quick tour of the BMC BladeLogic Console interface
Element Description
content editor Is 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 can be accessed when you choose

Window => Navigation => Show System Menu or
when you right-click 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 Working with content editors on

page 68.
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 with Quick Access on page 65.

The BMC BladeLogic Console is a single application window that contains global
menus, a simple tool bar, 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 while another
contains a list of all the jobs currently running. The primary element of every
perspective, however, is the content editor.
Editors
Just as there are different types of files, text, html, shell scripts, java - there are
different types of content editors. When you select (or create) an object, the system
does its best to open it using the most appropriate editor.
If it is a simple text document, the document opens in the built-in text editor. If it is a
Java source file, it opens in the JDT's Java editor, which has special features such as
the ability to check syntax as code is typed. If it is a Microsoft Word document on a
Windows computer and Word is installed, the document opens using Word inside
the system, by means of object linking and embedding (OLE).

You may have multiple content editors and objects open simultaneously. Only one
will be in focus. To change the focus from one content editor or object to another,
simply click the tab of the content editor or object with wich you want to work.
Perspectives and views

Instead of having to select and arrange individual views, BMC BladeLogic provides
several pre configured views arranged in a predetermined way; they are called
perspectives, and they can be customized to suit your needs.
When you log onto 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 editorwhether that is
working with a Shell script project or a set of word processing documents does not
matter in this perspective, apart from which editor is used to open specific objects in
the editor area.
As you work within the console, you can select different perspectives by selecting
Window => Open Perspective => perspectiveName.
The view in the upper left is called the Folders view; it shows a hierarchy of the
workspace and all 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 BMC BladeLogic
Console.
Menus and tool bars

In addition to perspective, views, and content editors, several other features of the
console are worth mentioning: the main menu, the main tool bar, and the shortcut
tool bar. Like the views and editors in a perspective, the global menu and tool bar
may change depending on the tasks and features available in the current perspective.
The main menu appears at the top of the window, 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.
Below the main menu is a simple tool bar which contains buttons that provide
convenient shortcuts for commonly performed actions. The tool bar icons do not have
labels but if you position the mouse pointer over them a short text description, or tool
tip, is displayed.
There are several ways to open perspectives. You can choose Window => Open
Perspective => perspectiveName from the main menu. You can also click the Open
Perspective icon that is adjacent to the perspective title tab. The tabs and icon provide
a quick way to open a new perspective and switch between perspectives.

Gutters on the left side and bottom of the screen serve as shortcut tool bars for
minimized views and their restore buttons. When you minimize a view, the views
icon and a Restore button are displayed together in the short cut tool bar nearest the
minimized view. For example, when you minimize the Tasks in Progress view, its
icon and a Restore button appear in the gutter across the bottom of the console. When
you minimize the Folders view, the Folders icon and Restore button appear in the
gutter on the left side of the console.
You can optionally add another type of shortcut to the shortcut tool bars: a Fast View.
Fast Views provide a way to turn a view in a perspective into an iconsimilar to the
way you minimize a view.
For example, you may find that you use the Tasks in Progress view only occasionally.
To turn the Tasks in Progress view into a Fast View, right-click the Tasks in Progress
view's title bar and select Fast View from the context menu. The Tasks in Progress
view is closed, and its icon appears in the shortcut tool bar. Clicking the icon
alternately opens and closes the view.
A Fast View does not have a Restore button. To restore the view to its previous place
in the perspective, right-click the Fast View icon and select Fast View.
In addition to the console global menu and tool bar, views can also have menus and
tool bars. Every 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, making it a Fast View, 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 tool bar. The tool bar always contains buttons to minimize or
maximize the view. They may also contain the triangle representing the system
menu, or buttons to add, edit or delete entries in the view.
Changing perspectives
As you work in the console, you may find that the different views are not the right
size for the work you're doingperhaps your source code is too wide for the content
editor. The solution is to hover the mouse over a view border until it turns into a two-
headed arrow and drag it until the window is the right size.
There may be occasions when you need to use all the screen real estate for a specific
view. Double-click the views title bar or click the maximize icon; this maximizes the
view within the perspective and sends the other views to the shortcut tool bars.
Double-click the title bar again to reduce the view to its normal size and restore the
other views to their normal locations and sizes.

BMC BladeLogic perspectives and views
You can also rearrange views by dragging them using their title bars. Dragging one
view on top of another causes them to appear as a single tab group of views. Selecting
a view in a tab group is like selecting a document in the content editor. Click its tab at
the top or bottom of the tab group to bring it into focus.
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 mouse pointer becomes a
black arrow whenever it is over a grid location where docking is allowed. For
example, if you want to make the content editor area taller in the Classic perspective,
drag the Tasks in Progress view on top of the Properties view, Permissions view, and
Audit Trail view tab group, making it another view in the tab group, and opening the
entire pane up for the content editor.
In addition to rearranging views, you can remove a view from a perspective by

selecting Close from the view's title bar menu or click 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 as you move from perspective to
perspective or close and open the console are saved automatically. For example, if at
the end of the day, you have added Tasks in Progress view to the Properties view,
Permissions view, and Audit Trail view tab group and expanded the content editor to
fill the space, that is the Classic perspective configuration you will see when you
begin your next session. To restore the perspective to its default appearance, select
Window => Reset Perspective.
If you find that your customized perspective is particularly useful, you can add it to
the list of preconfigured perspectives. From the main global menu, select Window =>
Save Perspective As. When prompted, provide a name for your new perspective.

A perspective is a visual configuration of elements for organizing your work space.
Typically, it contains one or more preconfigured 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 select an object in a view and open it in a content
editor. You can work with one of BMC BladeLogics preconfigured perspectives or
you can use a pre-configured perspective to build a perspective that suits the needs of
your workflow.

The views within the preconfigured perspectives have been selected to support
whatever tasks you are performing in the content editor. All the views in the Classic
perspective support the most frequently performed tasks associated with the system.
For example, if you select a server in the Folders view, you will automatically see the
selected server in the Properties view, Permissions view, and Audit Trail view tab
group. The Tasks in Progress view keeps you updated about any jobs that are run
against the objects selected in the Folders view, including the selected server.
Preconfigured perspectives and views

BMC BladeLogic ships with preconfigured perspectives. Each perspective has a
slightly different focus. Table 1 shows the preselected perspectives and the views
they contain.
Table 1 Preconfigured perspectives

Perspective Views
All Folders, Child Explorer, Properties, Permissions, Audit Trail,
Property Dictionary, Error Log, Custom Commands, Tasks in
Progress
Classic - the default Folders, Properties, Permissions, Audit Trail, Tasks in
perspective Progress
Classic2 Folders, Tasks in Progress
Explorer Child Explorer, Properties, Permissions, Audit Trail
Help Desk Folders, Properties, Permissions, Audit Trail, Custom
Commands
You can see all the open perspectives as tabs at the top right of the perspective
configuration. You can have all perspectives available at once and activate them
using the tabs.
Classic perspective
The default or Classic perspective is the general purpose perspective that opens the
first time you run BMC BladeLogic. It contains two views, a view tab group, and a
content editor. The views include:
Folders view - provides you with access to the 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
Managing BMC BladeLogic resources on page 84.
Properties, Permissions, Audit Trail views - this 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.

Tasks in Progress view - manages and monitors the status of jobs. For more
information, see Managing jobs in progress on page 427.
In the Classic perspective, the Folders view on the left provides access to functional
areas or resources known as folders (see Managing BMC BladeLogic resources on
page 84). When you select an item from the Folders view, it opens in the content
editor, the pane on the right. Tabs on the content editor provide information about
particular assets, such as the contents of a file or BLPackage. The tabs make it easy to
move between a variety of objects in the content editor or between multiple editors.
Working with perspectives and views

You can easily arrange and rearrange the preconfigured perspectives to suit your
working style by working with the views and the underlying perspective grid. You
can snap or dock the views in to different spots in the perspective grid, change the
shape from vertical to horizontal, or create groups of views with multiple tabs called
tab groups. The following table describes basic perspective and view behavior.
Table 2 Perspective and View Behavior

Action Procedures
To navigate perspectives and Choose Window => Navigation => navigationOption.
views using a menu
Perspectives
To open a perspective Do one of the following:
Choose Window => Open Perspective =>

perspectiveName.
Choose Open Perspective in the perspective title tab

and choose a perspective from the list.
Choose Other to see all available perspectives and select

one.
To reset perspective defaults 1. Choose Window => Reset Perspective.
2. When prompted to reset the defaults for the active

perspective, click OK.

Table 2 Perspective and View Behavior (continued)

Action Procedures
To customize a perspective 1. With the perspective you want to customize open, choose
Window => Customize Perspective.
2. The Customize Perspective - perspectiveName dialog

opens.
On the Shortcuts tab, select one or more submenus to

customize in the current perspective: New, Open
Perspective, Show View. The items you check here
will appear as cascading items under the selected
menu.
For example, if you use the file navigation view on a

regular basis, you add it to a perspective by choosing
Submenus => Show View. Check File Explorer.
On the Commands tab, select one or more items you

want to add to the Menu bar or the Tool bar in the
current perspective. Depending upon the Command
group with which they are associated, they will
appear in the Menu or Tool bar.
3. Click OK to apply changes.

To save a customized 1. Choose Windows => Save Perspective As.
perspective
2. Enter a name for the new perspective and click OK.
Views
To open a new view Choose Window => Show View => viewName.
To move and dock a view Click in the view title tab to activate the view. As you drag
the view, a frame shows you where you can dock the view
and what shape you can make it as you move it within the
perspective grid. Drop the view when you decide where you
want to dock the view.
If you dock the view on top of another view, it becomes a Tab

Group.
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 a single mobile unit with an arrow that changes
direction as you move the frame around the perspective
grid.
3. Click when you decide where you want to dock the

tabbed group view in the perspective.

Table 2 Perspective and View Behavior (continued)

Action Procedures
To detach a view from the 1. Right-click in the view tab.
perspective grid
2. Choose Detached. An additional tool bar appears over
the view title tab.
3. Click anywhere in the Detached tool bar to drag and

drop the view anywhere within the BMC BladeLogic
console.
To reattach a view to the Do one of the following:
perspective grid
Click in the tab title bar to change the view back to an
attached view.
Right-click in the view title tab and clear Detached.

To minimize and maximize a 1. Do one of the following:
view or tab group
Use the minimize and maximize buttons on a
view or Tab Group.
Right-click the view title tab or tool bar and choose

Minimize or Maximize.
Double-click the view title tab to expand the view. The

other views in the perspective become icons in the
shortcut tool bar.
Double-click again to return the view to its original

size and location. The other views in the perspective
resume their space and size in the perspective.
Enter Ctrl + M to toggle between minimize and

maximize.
To resize a view 1. Do one of the following:
Move the cursor over the view border until it becomes

a double-arrow.
Right-click in the view title tab and choose Size =>

viewSide. The border you select is highlighted.
2. Resize to accommodate your work style.

About global capabilities

BMC BladeLogic has a global menu bar and a limited global tool bar. You can initiate
most operations in BMC BladeLogic using the options on these bars. You can also
right-click an object and choose from the context sensitive menu options available to
you.
BMC BladeLogic also provides the following global capabilities:
Navigating the console with Quick Access

Limiting objects using filters
Clearing filters
Paging through multiple objects
Managing jobs in progress
Running operations in the background
Working with content editors
Managing BMC BladeLogic resources
Importing and exporting BMC BladeLogic objects
Searching for objects
Navigating the console with Quick Access

BMC BladeLogic is a sophisticated, feature-rich product with many elements and
resources. The ones you use all the time will become familiar quickly, with use. The
features that you use with less regularity might never become routine.
Instead of spending a great deal of time searching through menus and resources you
can use the Quick Access popup to quickly scan for commands for which you might
recall some portion.
1 Press Ctrl+3. The Quick Access popup displays.
2 Type the portion of the command or resource that you can remember in the text
box at the top of the popup. As you enter more letters, the selection list changes as
more items are located that match your entry.
For example, you want to change the build order. Enter build in the text box. The
system shows you the available choices, organized by resource. In the case of build,
it 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 popup.
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

Working with a large number of objects can be difficult to manage. One way to limit
the scope of your work is to filter the 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.
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 Click More to add an additional line that lets you use a text string in the Description
field as a filter.
NOTE
The More option is enabled only when the Child Explorer view is available in the
perspective. When the Child 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. Since
filters only affect the display of objects, clearing the filter returns those objects to the
display.
1 When you are ready to view all members of the group, do one of the following:
A If the Filters dialog is still open, choose Clear.
B 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

When working with groups, smart groups, folders, and search groups in BMC
BladeLogic, the number of objects can make viewing and manipulating the objects
cumbersome. To make working with groups more manageable, they are presented in
the Folders view tree in groups of 20 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 what page number you are on, how
many items there are per page, how many items there are total, and how many pages
there are total.
To page through objects, do one of the following:
Double click the up (Previous) and down (Next) arrows to scroll through the objects
Right click an arrow and choose one of the following: Next Page, Previous Page, First
Page, Last Page, Jump to Page.

When you perform an operation that take a long time to complete, the BMC
BladeLogic console gives you 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 gives you this option.

A dialog telling you the operation is in progress provides the option for running the
operation in the background. If you do not run the operation in the background, the
dialog remains displayed, effectively locking your console. If you choose to run the
operation in the background, the system places the operation in a queue with any
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 BladeLogic
console, a dialog informs you that operations are currently running. These operations
will be canceled if you close BMC BladeLogic. The dialog gives you 30 seconds to
make a decision. Otherwise, the system will shut down and any background
operations are canceled.
When you start an operation that gives you the opportunity to run it in the
background, a progress dialog gives you the following options:
Click Run in Background. The progress dialog 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 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 have
operations run in the foreground, use Preferences. For more information, see
Customizing preferences on page 73.
Click Details to display additional information about the operation in progress.

The dialog expands and shows any background operations that are currently in
progress. You can click Cancel operation to cancel an operation in this list.
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.

BMC BladeLogic integrates multiple editors to provide you with access to files based
on the file type. The system supports the following content editors.
BL Editor - 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 with BL Editor on page 69.
System - The operating system editor is read only.

Viewing and editing text files with BL Editor
Default - Use the Preferences menu to specify a default editor (for more
information about setting preferences, see Customizing preferences on page 73).
ShellEd - ShellEd is a 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 with ShellEd on page 70.
Other - This opens a window which displays all editors 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 dialogs or windows in the BMC BladeLogic 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 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 they are the same. For example Copy (CTRL- C) and Paste (CTRL-V) tend to be
universal.
Viewing and editing text files with 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. The
following procedure uses the Servers folder as the example.
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.
The file displays 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.

Viewing and editing Network Shell Script files with ShellEd
5 To save the file, right-click the tab representing the file and select Save. To save the
file using a different name or location, select Save As from the File menu and use
the dialog to specify a name and location for the file.
6 To close the tab representing the file, click Close in the file title tab.
Viewing and editing Network Shell Script files with ShellEd

ShellEd is the default editor for Network Shell Scripts. It has all the features the
standard features that are available with BL Editor as well as Shell Script help and
syntax color formatting. It offers flexible NSH script content editing. Use ShellEd for
viewing and editing files and Network Shell scripts stored in the Depot.
Use this procedure to view and edit ShellEd files.
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 displays 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, select Save As from the File
menu. Use the dialog to specify a name and location for the file.
6 To close the tab representing the file, click Close in the file title tab.

Setting preferences for text editors
Setting preferences for text editors

The system comes with many default settings that you can modify to suit your work
style or corporate mandates, 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.
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 on the 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 that 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 on the 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 on the left. Clear existing settings
to override the defaults.
7 Click Apply to implement the new settings or Restore Defaults to return to the
original values.
8 Click OK to exit the Preferences dialog.
Selecting editors
The system provides you with many options when it comes to editing BMC
BladeLogic objects. In addition to the BL Editor, the system editor, and the default
editor, there are additional internal and external editors you can use.

Provisioning with BMC BladeLogic
1 Select the object you want to open in the content editor.
2 Right-click and choose Open with => Other.
The Editor Selection dialog displays the list of all editors, BMC BladeLogic and
non-BMC BladeLogic that are available within the system.
3 To use a BMC BladeLogic internal editor, select one from the list and click OK.
4 To use a non-BMC BladeLogic editor, select External Program.
5 Select one of the external editors in the list or select Browse to see the 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.
Provisioning with BMC BladeLogic

BMC BladeLogic lets you provision operating systems onto servers.
NOTE
For information about using the BMC BladeLogic console to provision servers, see Chapter 25,
Provisioning servers.
Using the console, you can:
Create and manage system packages, which are collections of all the instructions
necessary to provision a server with an operating system.
Create and execute Provision Jobs.
View devices that devices that have already been provisioned, devices that have
been discovered but not yet provisioned, and devices that have been manually
imported but not yet provisioned.
Monitor the progress of devices being provisioned.

Managing the BMC BladeLogic console
The provisioning capabilities are divided into the following folders:
Depot folder
Devices folder
Jobs folder
For information about managing provisioning jobs in progress, see Managing jobs in
progress on page 427.
Managing the BMC BladeLogic console

The following options let you manage the appearance of BMC BladeLogic:
Customizing preferences
Viewing keyboard shortcuts
Customizing keystroke combinations
Customizing tables and columns
Refreshing the data
The BMC BladeLogic Preferences window provides you with a centralized location
for managing the look and behavior of your console. Preferences are not intended to
reference any resource currently defined in the workspace, for example a job or
server. It is intended to tailor editors, views or other objects that perform operations
on a resource. The changes you make in the Preferences window persist until you
make additional changes or restore the original defaults.
Use this procedure to set and save preferences.
1 Choose Window => Preferences.
2 Do one of the following to see preference categories in the hierarchy on the left.
Enter text in the filter text box to narrow your choices in the preferences tree. For
example, if you want 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 on the right to navigate the different preference
windows settings.
The arrows cycle you backwards (left) and forward (right) through the
preference windows to which you have navigated.
The down arrows list the preference windows (back and forward) to which you
have navigated.
The down arrow on the right lets you resize the preferences settings tree on the
left or execute key scrolling.
4 To set preferences, refer to Table 3 on page 75 for BMC BladeLogic-specific

preferences and Table 4 on page 76 for general preferences.
5 Select one or all of the following actions:
Choose Restore Defaults to remove preferences you have made or changed.
Choose Apply to activate the new preferences.
6 Select each node that is currently expanded or was expanded previously during
the current session. Then select File => Refresh or press F5.
The current node and its children are refreshed so they reflect any new
preferences.
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 Click OK to exit the Preferences window. Your preferences are automatically saved
with the console.

Table 3 Preference Settings - BMC Category

Preference Setting Options/ Default
Display Options Show the compliant software in the Audit results - show 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 nodes if users should be able to see a system object even
though the user does not have appropriate permissions to interact with that
object.
RBAC Manager shows no access nodes. Clearing this option means that no
access nodes are not displayed. For more information on no access nodes, see
No access nodes on page 152.
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 BladeLogic console. For more
information on configuring the Application Server, see the BMC BladeLogic
Server Automation Administration Guide.
Show running jobs in Tasks in Progress window for jobs
For which the current role has access permission - shows all running jobs
for which the current role has access permission.
Executed by current role - shows all running jobs executed by the current
role.
Executed by current user - shows all running jobs executed by the current
user.
From Display Font, select the name and size of the display font in the drop-
down lists. To set this value you must restart the BMC BladeLogic console.
File Deploy Options Parallel ProcessesThe number of parallel deployments you want to occur.
Block Level Update The minimum size (in kb) for a file that should invoke
large file handling during a deployment. Files smaller than this value are
copied in full.
Update Block SizeThe block size (in kb) that should be used for
comparison and update purposes.
Minimum disk free The minimum amount of disk space (in kb) for a
destination directory.
Default destination directory The default destination directory for push
jobs.
Default staging directoryThe default directory on repeater hosts that
holds content while it is being copied to destination machines.
Default backup suffixA suffix that is appended to all files that otherwise
would be overwritten during a copy. Adding a backup suffix effectively
creates a backup copy of those files.
Default backup directoryThe directory where a backup of a target file or
directory can be stored.

Table 3 Preference Settings - BMC Category

Preference Setting Options/ Default
Live Browse Results The maximum number of items that can be displayed when you select a node
Option while browsing the Servers folder. This limit can also be set for the Application
Server. (See the BMC BladeLogic Server Automation Administration Guide for more
information on using the blasadmin utility to set a maximum.) If you enter a
value lower than the maximum defined for the Application Server, the limit you
enter here as a preference takes precedence. You cannot set this value higher
than the value that is defined for their Application Server. Setting this number to
0 indicates no results are displayed.
If you select a node while browsing the Servers folder 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 looks like this:
Paging Options Page Size: a value between 1 and 1000. For more information, see Paging
through multiple objects on page 67.
Table 4 Preference Settings - General Category

Preference Setting Options/Default
global 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 Current presentation: Default or Classic
Override presentation settings:
Editor tab positions - Top
View tab positions - Top
Perspectives switcher positions - Top Left
Show text on the perspective title bar
Current theme: Default, Reduced Palette, Classic
Show traditional style tabs - enabled
Enable animations - enabled
Enable colored labels - enabled
Colors and Fonts Use filters to narrow selection lists. Use wildcards as place
holders in filters.
Set preferences for the console dialogs and editors
Set preferences for use when text is being compared
Set preferences for foreground, background, active and
inactive
Label Decorations Clear the default settings that display additional information
about items using label decorations.

Table 4 Preference Settings - General Category (continued)

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 have
been 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 a single 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
Content Types Content types, including:
Properties (Preferences)
Refactoring History Files
Refactory History Index
Runtime log files
XML (Ant Buildfiles)
The File associations box displays the files associated with a

specific content type. You can add new file associations, edit or
remove existing associations.


Editors Show multiple editor tabs in the content editor
Allow in-place system editors
Restore editor to its original state on 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
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.
Text Editors 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 moved 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
Accessibility Use custom caret
Enable thick caret
Use characters to show changes in vertical ruler
Annotations Shows preference settings available by annotation type
Hyperlinking Shows preferences settings for the type of hyperlinking navigation
enabled and the default modifier key
Linked Mode Shows preferences settings for ranges by range type
Quick Diff Enable Quick Diff to show changes within the text editor, instead
of just the compare editor.
Show differences in an overview ruler to tell, at a glance, how

many changes you have made to a file since your last commit.
Spelling Not available


Keys Add, edit, remove key bindings for the system. For more
information, see Customizing keystroke combinations on
page 79.

BMC BladeLogic uses standard keystroke combinations for common commands as
well as less common commands. Using key board shortcuts can make your work
easier and faster. For example, Ctrl+C is the same thing as choosing Edit => Copy but
faster and more efficient.
The system provides a quick review of all the keystroke combinations in a simple,
filterable window. To view all keystroke combinations, use the following procedure:
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. See
Customizing keystroke combinations on page 79.

The system uses standard keystroke combinations for common commands. For
example, Ctrl-c is the same thing as choosing Edit => Copy. However there may be
combinations that you prefer to work with or you may wish to assign keystroke
combinations to commands that do not have already have them. You can customize
keystroke combinations using the Preferences window.
NOTE
When you are interacting with dialogs or windows in the BMC BladeLogic 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 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 they are the same. For example Copy (CTRL- C) and Paste (CTRL-V) tend to be
universal.

Use this procedure to customize keystroke bindings.
1 Choose Window => Preferences. Expand General and click Keys.
2 Select the default keyboard scheme or EMACS, the Apple MacIntosh editor
keyboard command scheme.
3 Enter one or more characters to filter the list of commands. 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:
Choose Filters if you want to clear some of the default filter actions or restore
filters.
Choose Export if you want to save the keystroke commands as a .csv file to a
location other than the system folder.
Choose Restore Defaults to remove any key bindings you have made or changed.
Choose Apply to activate the new or changed keystroke combinations you have
made.
8 Click OK to exit the Preferences window. Your preferences are automatically saved
with the console.


Whenever the system presents data in tables, you can customize the columns in the
tables. You can add and remove columns from the 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.
There are several types of tables.
Fixed-column tables - display a fixed number of columns that are predetermined.

You may choose which columns to display but you cannot add to the original
configuration. For more information, see Customizing fixed-column tables.
Child Explorer tables - display a default number of columns but the number of
columns you can add to the table is limited only by the number of properties that
are available for the object. For more information, see Customizing Child
Explorer tables on page 81.
Custom configuration object tables - display a default number of columns but the
number of columns you can add to the table is limited only by the number of
properties that are available for the object. For more information, see Customizing
custom configuration object tables on page 82.
Customizing fixed-column tables

Use the following procedure to customize a fixed-column table.
1 Right-click anywhere 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 Select a row and use the up and down arrows on the right to reposition the
columns in the table.
4 Click the arrow beside Format to expand the Column Customization window. See
Formatting columns on page 83.
5 Click OK to apply the changes and view the customized table.
Customizing Child Explorer tables

Child Explorer tables display information about a parent object selected in a content
editor or in the Folders view in table format. You can tailor Child Explorer tables,
including adding attributes or properties as columns.

Use the following procedure to customize columns in a Child Explorer 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 on the 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).
7 Click beside Format to expand the Column Customization window. See

Customizing custom configuration object tables

Custom configuration objects display tables with huge numbers of columns but
relatively small number of rows. To make the tables more manageable, you can select
which columns to display.
Use the following procedure 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 on the right.
3 To remove a row from the table, select the row in the Columns list and click
Unselect to remove it.

5 Click beside Format to expand the Column Customization window. See

Customizing columns from a pop-up menu

Use the following procedure to customize a fixed-column table from a pop-up menu.
1 Right-click on 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 Click the name of the column you want to display or remove from the display.
Changing the sort order of a column

To change the sort order of a column, click the column header. If it is a sortable
column, an up arrowhead appears in the header to show you the sort direction. Click
again to reverse the sort direction.
For information on sorting columns in a paging table, see Customizing fixed-column

tables.
Formatting columns
Use the following procedure 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. Choose
Reset to return to the original value.
4 Use the Field Format menu to modify the value when it is a date or a number.
Preview shows you what the value will look like in the new format.
5 Adjust the width of the column or accept the default value (1). All the columns are
auto-sizing, meaning that they will expand or contract to fit the space available to
them. It also means that the column width changes dynamically.
If you change the width of the column to 2 that means that this column equals the
same space as two columns; 3 equals the width of three columns, and so on.

Refreshing the data
6 Choose the alignment of the column header and its content: left, center, right.
7 Click OK to apply changes and view the formatted table.
Refreshing the data

Refreshing the product displays the most current information available in the
database. The product automatically refreshes the database so that you are working
with the most current information. For example, when you create, remove, or modify
an object, the changes you make to that object job, template, and so on are
automatically cascaded across the Folders view, where ever the object appears.
Dependent objects are refreshed in tree and table views. For example, if you add
something to a template, the components associated with that template will reflect
the addition you made to it.
While the product automatically refreshes information, it is a good practice to refresh

manually on a regular basis.
Do any of the following to refresh:
Choose File => Refresh.

Select Refresh from a pop-up menu (available by right-clicking in most contexts).
Press F5.
Click Refresh on windows where it might be appropriate to refresh.
If you want to refresh a hierarchical object, select the parent object and then select
Refresh.
Managing BMC BladeLogic resources

The BMC BladeLogic Folders view is a general purpose view which gives you access
to all your BMC BladeLogic resources. It contains the following folders:
Components folder
Component Templates folder
Depot folder
Devices folder
Jobs folder
RBAC Manager folder
Search
Servers folder

Components folder
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 Chapter 8,
Components and component templates.
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 on components,
and change the properties and permissions of a component template. For a complete
description of the Component Template folder, see Chapter 8, Components and
component templates.
Depot folder
The Depot folder holds objects that are needed to execute jobs. 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 Chapter 9, Creating packages and other
depot objects. For information on system packages, see Creating a system package
on page 925.

Devices folder
Devices folder
The Devices folder lets you view discovered servers (servers that have booted up but
have not yet been provisioned), pre-discovered servers (servers that have not yet
booted up but have already been 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 servers on page 1019 and
Creating a Provision Job on page 1024.
Jobs folder
The Jobs folder lets you create, modify, and execute jobs as well as view job results.
With the Jobs folder, you can manage any of the following types of jobs:
ACL Push JobsConvert role information into access control lists and then copy
those lists to agents. For more information, see Creating ACL Push Jobs on
page 195.
Atrium Import JobsTransfer business service data from a BMC Atrium

Configuration Management database to the BMC BladeLogic database. For more
information on these jobs see BMC BladeLogic Integration for Atrium: Implementation
Guide.
Audit Jobs Determine whether server configurations comply with a standard

configuration. For more information, see Creating Audit Jobs on page 475.
Batch JobsRun a concatenated series of jobs on remote servers. For more

information, see Creating Batch Jobs on page 579.
Compliance JobsDetermine whether components satisfy compliance rules

established for a component template. For more information, see Creating
Compliance Jobs on page 312.
Component Discovery JobsAssociate components with servers. For more

information, see Creating Component Discovery Jobs on page 294.
Deregister Configuration Objects JobsRemoves implementation files for custom

server objects from servers. See Creating a Deregister Configuration Object Job
on page 656.
Distribute Configuration Objects JobsDistributes implementation files for

custom server objects to servers where you want to use these objects. See Creating
a Distribute Configuration Objects Job on page 642.

RBAC Manager folder
File Deploy JobsCopy files and directories from a managed server to multiple
locations. For more information, see Deploying files and directories on page 506.
Network Shell Script Jobs Deploy and execute Network Shell scripts on remote
servers. For more information, see Creating Network Shell Script Jobs on
page 567.
Patch Analysis JobsAnalyze the configuration of patches on servers by

comparing them to vendor recommendations or user-defined lists of patches.
Provision Jobs Apply a system package to one or more servers and perform
unattended installation of the operating system. See Creating a Provision Job on
page 1024.
Snapshot JobsRecord the configuration of a group of server objects at a point in

time. For more information, see Creating Snapshot Jobs on page 452.
Software and BLPackage Deploy JobsDeploy BLPackages and software

installables to remote servers without user interaction. For more information, see
Overview of software packages on page 350.
Update Server Properties JobsObtain the most recent property settings from
agents and update them in BMC BladeLogic. For more information, see Creating
Update Server Properties Jobs on page 212.
Upgrade Model Objects JobsUpgrade policy-based objectsthat is, component

reference the most recent version of a server object. See Creating an Upgrade
Model Objects Job on page 649.
For procedures explaining how to set up and manage the Jobs folder, see Chapter 10,
Managing jobs.
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 those roles. Once 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 Chapter 6, Managing access.

Search
Search
Search lets you scan and retrieve information about objects in your BMC BladeLogic
environment. You specify search criteria to construct queries to search all objects in
the BMC BladeLogic database. Search results appear in a Search view and can be
saved to a Smart Group (see Defining a smart group on page 92). For more
information about Search, see Searching for objects on page 90.
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 Chapter 7, Using the Servers folder.
Creating new objects

The Folders view presents you with an overview of the objects available to the
system. You must create the objects to populate the folders in the object tree.
The New menu enables you to create new resources for objects in the resource tree.
There are several ways to access the New menu.
Choose File => New => Other to open the New dialog from the Global menu. Enter
a filter to narrow the choice of wizards or scroll through the list in the Wizard
explorer tree. For example, File => New => Other to open the New dialog. Enter
Servers in the filter box to narrow the display. 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 the ACL Template object. Choose New =>ACL Template to open the Create
New ACL Template wizard.

Organizing folder content
Organizing folder content

The BMC BladeLogic console lets you 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. In that way smart groups help
you easily organize objects according to specific criteria. 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, all Windows servers can be grouped together
automatically. The contents of a smart group can change over time 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 BladeLogic 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
Use the following procedures to define folders, groups, and smart groups:

Creating a folder or group
Defining a smart group

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 95. You can also delete folders and groups and the
objects they contain (see Deleting a folder, group, smart group, or system object on
page 96).
NOTE
If you select multiple system objects, menu options that allow you to perform actions on those
object are always enabledeven when you do not have permission to perform an action on all
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 do attempt to delete the
selected objects, warnings inform you that you do not have permission to delete some objects.

Use these procedures to search for BMC BladeLogic resources and objects. A simple
search returns objects in a Search view. A BMC BladeLogic resource search returns
objects as nodes under Search in the Folders view. BMC BladeLogic search returns are
available until you save them to a Smart Group or until you perform another search.
Use the following procedure to search for BMC BladeLogic objects.
1 Click Search from the tool bar.
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 Do the following to specify the search criteria:
A In the next drop-down box to the right, select the name of a property. For
example, select DATE_CREATED.
B In the next drop-down box to the right, select a comparison-operator, such as

begins with, is one of, or is before.
C In the next field to the right, provide a value or values for the property. How
you provide a value depends on the property and the comparison operator.
For example, to search for all windows computers, select OS in the first drop-
down, then select equals, then select windows.
D To create another condition, click the plus sign to the right of the condition you
have just defined. An additional line for another condition displays.
To delete a row representing a condition, click the minus sign to the right of that
condition.
7 Click Search. Expand Search to see the results.
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 92).
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 95. You can also delete folders and groups and the
objects they contain (see Deleting a folder, group, smart group, or system object on
page 96).
NOTE
If you select multiple system objects, menu options that allow you to perform actions on those
object are always enabledeven when you do not have permission to perform an action on all
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.

Use this procedure to 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 140.
Select any of the following folders, any sub-folder or sub-group 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 displays.
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 displays.
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 on defining an ACL, see Defining
permissions for a system object on page 186.
4 Define permissions for the folder or group and click Finish.

Use this procedure to define a smart group.

NOTE
Be aware of the following:
You cannot manually add objects, folder, 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.
Smart groups can potentially include an extremely large number of objects.

Displaying those objects can impact your systems performance. BMC BladeLogic
allows you to limit the number of objects displayed in a smart group. For more
information on this procedure, see Limiting the objects displayed in smart groups
on page 95.
Select any of the following folders, sub-folders, or sub-groups 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 smart group wizard displays.
2 For Name, enter a name for the smart group. For Description, you can optionally
3 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).

4 Do the following to define a condition:
A When defining smart job or smart depot groups, use the first drop-down box to
the 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.
B In the next drop-down box to the right, select the name of a property. For
example, select DATE_CREATED.
C In the next drop-down box to the right, select a comparison-operator, such as

begins with, is one of, or is before.
D In the next field to the right, provide a value or values for the property. How
you provide a value depends on the property and the comparison operator.
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, then select between, and finally select two dates in the fields
farthest to the right.
5 To create another condition, click the plus sign to the right of the condition you
have just defined. An additional line for another condition displays.
To delete a row representing a condition, click the minus sign to the right of that
condition.
The Permissions panel is an access control list granting roles access to this smart
group. Access to all objects, including the sharing of objects between roles, is
controlled through ACLs.
7 Define an ACL for the smart group. For more information on defining an ACL, see
Defining permissions for a system object on page 186.
8 Click Finish.
The new smart group is created. Objects matching the conditions you have
specified automatically populate the group.

Copying, cutting, and pasting groups, folders, and system objects
Limiting the objects displayed in smart groups

Server and component smart groups can potentially include an extremely large
number of objects. Obtaining information from the database to display those objects
can be slow and can consume considerable amounts of system memory. BMC
BladeLogic lets you limit the number of objects displayed in a server or component
smart group. To accomplish this, you must use the Application Server
Administration console (that is, the blasadmin utility) to set a value for the
MaxSmartGroupItems option. For more information on this procedure, see the BMC
If you choose to limit the objects displayed in server or component smart groups and
the contents of a smart group are truncated, a dialog displays when you create or
select the smart group. It warns you that the contents of the smart group are not all
displayed. The name of the smart group indicates its contents are truncated.
If you define a job that references a server or component smart group and the
contents of that smart group are truncated, the job will fail.
You can also use search (Search on page 88) to limit objects.
Copying, cutting, and pasting groups, folders, and system

objects
Use this procedure to copy and paste or cut and paste groups (including smart
groups) or to cut and paste folders while working with the Child Explorer view. You
can also use this procedure to copy and paste or cut and paste most types of system
objects. You cannot copy and paste folders or groups but you can copy and paste
smart groups.
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 BladeLogic provides a
mechanism for changing this default behavior, as described in Assigning default
permissions when cutting and pasting on page 96.
TIP
Rather than cut and paste groups and folders, you can drag and drop them.
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.

Deleting a folder, group, smart group, or system object
3 Right-click a folder or group and select Paste from the pop-up menu.
The folder, group, or system object appears in its new location. You cannot paste
into a smart group.
NOTE
Copy and paste actions are also available from the global Edit menu as well as the standard
keystroke combinations (Ctrl-v, Ctrl-c).
Assigning default permissions when cutting and pasting

By default, when you copy and paste an object, the newly created object has 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, the newly created
object has 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 the object from scratch.
For information on how to use blasadmin to set the UseDefaultAclOnObjectCopy

option, which controls how permissions are assigned during copy and paste
operations, see the BMC BladeLogic Server Automation Administration Guide.

Use this procedure to 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 the BMC
BladeLogic Server Automation Administration Guide. 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 are deleting, you have the option of deleting
those other objects along with the object you have chosen 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 rapidly find system objects with broken dependencies.
For details, see Finding system objects with broken dependencies on page 98.
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 shows the objects you have selected for deletion.
3 Click OK.
If no folders, groups, or system objects have dependencies on other objects, the

Delete dialog shows the results of your actions. A green check indicates an object
was successfully deleted. Proceed to step 6.
If any of the folders, groups, or system objects being deleted have dependencies on
other objects, the Found Dependencies dialog lists the other items affected by the
deletion of the first object in the Delete dialog. For example, if you have chosen to
delete a BLPackage, the Found Dependencies dialog might show that a Deploy Job
and a Batch Job have dependencies on that BLPackage.
4 Review the contents of the Found Dependencies dialog and click one of the
following:
OKDeletes the folder, group, or object listed in the dialog along with all of its
dependent objects.
IgnoreDoes not delete the folder, group, or object listed in the dialog.
BreakDeletes the object listed at the top of the dialog and breaks any
dependencies with component templates, Deploy Jobs, or Batch Jobs.

Properties, Permissions, and Audit Trail tab group
If the Delete dialog in the previous step showed multiple objects being deleted, the
Found Dependencies dialog now displays any dependencies for the next item
listed in the Delete dialog.
5 Continue to repeat step step 4 until the Delete dialog shows the results of your
actions.
6 Click Close to close the Delete dialog.
Finding system objects with broken dependencies

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. Using this property, you can
create a smart group that displays system objects with broken dependencies. For
example, you could create a component template smart group with a condition
saying that BROKEN_OBJECT must equal True. This smart group will display all
component templates with broken dependencies.
Properties, Permissions, and Audit Trail tab

group
Almost every object in BMC BladeLogic includes 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 view
The Properties view provides a list of properties associated with the current system
object.
In the Properties view, there are two categories of properties: basic and extended. 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 who 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. The extended set of
properties also includes user-defined properties.
For a complete discussion of properties in the BMC BladeLogic system, see Chapter 5,
Properties. For a detailed description of how to use the Properties view to set
values for system object properties, see Setting values for system object properties
on page 140.

Permissions view
Permissions view
The Permissions view lists permissions that have been granted to the system object
that is currently selected. 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 a an extensive discussion of permissions, see Chapter 6, Managing access. For a

detailed description of how to use the Permissions view to define permissions for
system objects, see Defining permissions for a system object on page 186.
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 what types of actions are logged in an audit trail (see Defining audit
trails on page 158).
Viewing dependencies
Use this procedure to 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 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 created a new revision of one Deploy Job, you can quickly check to see
if the Batch Job has been updated to include the latest revision of the Deploy Job.

Viewing dependencies
The Dependency display also lets you right-click an item and immediately go to that
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 itself.
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.

Importing and exporting BMC BladeLogic objects
Importing and exporting BMC BladeLogic

objects
BMC BladeLogic lets you import and export the following types of BMC BladeLogic
objects:
BLPackages
Configuration files
Component templates
Depot software
Extended objects
Files
Jobs (all job types, with the exception of Provision, Distribute Configuration
Objects, Deregister Configuration Object, and Model Object Upgrade Jobs)
Network Shell Scripts
Property Dictionary and custom property classes (see Using PropertySync to
import and export properties on page 132)
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 BladeLogic objects, you can do any of
the following:
Move objects between separate BMC BladeLogic 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 BladeLogic 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 pre-packaged content provided by BMC BladeLogic.
Package problematic objects so they can be forwarded to BMC BladeLogic 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.

Exporting objects
For more information, see Exporting objects on page 102 and Importing objects
on page 104.
Exporting objects
Use this procedure to export system objects from BMC BladeLogic 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.
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)
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 For Save to, enter the path or use the hierarchical tree to select the directory where
you want to save exported objects.

Exporting objects
4 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
Audit Jobs
Exclude Compliance Jobs Batch Jobs
Exclude Component Templates Audit Jobs
Batch Jobs
Compliance Jobs
Component Discovery Jobs
Deploy Jobs
Snapshot Jobs
Audit Jobs
Exclude Deploy Jobs Batch Jobs
Exclude Depot Files Audit Jobs
Batch Jobs
BLPackages
Compliance Jobs
Component Templates
Deploy Jobs
Snapshot Jobs
Audit 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
Audit Jobs
Often you can dramatically reduce the size of the object being exported by
excluding 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 auto-mapping mechanism
can do that automatically.

Importing objects
5 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 will match
functionality prior to release 7.4.3.
6 If the object being exported is a configuration file or extended object that references
a custom grammar and you want to export that grammar with the object, check
Include referenced grammar files.
This option only displays when the object being exported is a configuration file or
extended object or 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.
7 Click Export.
A dialog displays, indicating that the export has begun. In some situations, this
operation can take time. The dialog gives you options for running the operation in
the background. For information on this dialog and running background
operations, see Running operations in the background on page 67.
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 being exported. If
you are exporting a configuration file or extended object, the operating system is
appended to the object name, such as objectName_Windows.
Importing objects
Use this procedure to import system objects from a file system into BMC BladeLogic.
The behavior of the Import wizard, which steps you through this procedure, depends
on the type of object you are importing.
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.

Importing objects
If you import an object that includes any associated objects stored in the file server of
the exporting system, those associated objects will be 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 BladeLogic from which
the objects were exported.
If you are importing an object, PropertySync is enabled (see Using PropertySync to

import and export properties on page 132), and the imported object references
properties, property classes, or property set instances that do not exist on the importing
system, the import will fail.
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 Use the Import wizard, as described in the following sections:
Select Import Source Directory

Import contents
Select destination grammars
Select destination group
Select remediation groups
Map Missing Servers and Server Groups
Map Missing Properties
Property Values Mapping
Map Existing System Package Types
Map Missing BLPackages
Map Missing Component Templates
Map Missing Depot Objects
Map Missing Component Discovery Jobs
Map Missing Compliance Jobs

Importing objects
Map Missing Deploy Jobs

Map Missing Network Shell Scripts
In some situations, after you specify a source directory (the first section listed
above), a dialog 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.
3 Click Finish after completing the last step of the wizard.
Select Import Source Directory

The Select Import Source Directory panel lets you identify the file that contains the
BMC BladeLogic object you want to import.
1 For Import from, enter the path to a directory or use the hierarchical tree to select
the top-level directory representing the BMC BladeLogic 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 actual file
representing the BMC BladeLogic object.
2 Check Automatically map or create export groups 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 will create
groups to make the group structure on the import system match the exporting
system.
If you do not check this option, the import process will assign imported objects to a
default group. You may have to manually map some objects to their correct
groups, as described in Select destination group on page 107.
Import contents
The Import Contents panel shows all of the objects that will be 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.
Select destination grammars

The Select Destination Grammars panel lets you 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 are
importing a configuration file, extended object, or component template that includes
a local configuration object. If the Import wizard finds a matching grammar file on

Importing objects
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.
1 In the Grammar Selection list, select a grammar and click Change Selected Grammar
.
The Grammar Selection dialog opens.
2 Using the Grammar Selection dialog, select a grammar file on the importing
system that should be used in place of the selected grammar file and click OK.
3 Repeat the previous two steps for each grammar file so that the correct grammar is
defined for every grammar file in the list.
Select destination group

The Select Destination Group panel lets you identify the groups that should contain
all parts of the object you are importing. For example, if you are importing a Deploy
Job that deploys a BLPackage, you must identify a job folder where you want to store
the imported Deploy Job, and you must identify a depot folder to store the imported
BLPackage.
1 In the Group Selection list, select an object and click Change Selected Group .
The Select Group dialog opens.
2 Using the Select Group dialog, navigate to the folder that should hold the selected
object and click OK.
3 Repeat the previous two steps for each object so that the correct folder is defined
for every 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.
Select remediation groups

If a Compliance Job that you are importing 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.

Importing objects
The Select Remediation Groups panel lets you identify the groups that should contain
all BLPackages, Deploy Jobs, and Batch Jobs that are created automatically when you
run the imported Compliance Job.
1 In the Group Selection list, select an object and click Change Selected Group .
The Select Group dialog opens.
2 Using the Select Group dialog, navigate to the folder that should hold the selected
object and click OK.
3 Repeat the previous two steps for each object so that the correct folder is defined
for every 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.
Map Missing Servers and Server Groups

The Map Missing Servers and Server Groups panel lets you identify a server that
should take the place of a server referenced by the object you are importing. The
Import wizard only displays this panel when the object you are importing references
a server not available to your role.
When importing most types of jobs, servers and job targets are not considered
relevant so they are not mapped when you export and import jobs. The one 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 displays.
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.
1 In the Server Selection list, select a server or server group and click Change Server
Mapping .
The Select Server dialog opens.
2 Using the Select Server dialog, navigate to the server or server group that should
take the place of the selected item and click OK.
3 Repeat the previous two steps for each server and server group in the list.

Importing objects
Map Missing Properties

The Map Missing Properties panel lets you identify the properties that should take
the place of properties referenced by the object you are importing. When an imported
object references properties, the import process automatically maps those 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. Note,
however, that PropertySync cannot be enabled. (For more information on
PropertySync, see Using PropertySync to import and export properties on
page 132.) If PropertySync is enabled and properties are missing on the importing
system, the import will fail.
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 any 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. In a situation like this 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. See the table below for a list of possible reasons. If a property is successfully
mapped, the Reason column is blank.
Reason Detailed 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 has a
different type.

Importing objects
Reason Detailed Explanation

Matching enumeration with same element A property has been exported, and the
not found 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 has been 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 have the option of turning 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 the BMC
1 Under Property Selection, review the properties listed and the properties to which
they have been mapped. The Replacement Property column shows the property to
which a 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,
proceed to the next step.
2 In the Property Selection list, select a property and click Change Property Mapping
.
The Select Property dialog opens.
From Property, select a property that should replace the property you selected in
the previous step.
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 opens. Use the dialog to define the property and add it to the Property
Dictionary. (For more details, see Adding or modifying properties on
page 125). 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.
4 On the Select Property dialog, click OK.

Importing objects
5 Repeat the previous three steps for each property in the list that is not properly
mapped.
Property Values Mapping

The Property Values Mapping panel lets you 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 displays when all 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 where 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 was true:
The same property did not exist.
The same property existed but no value was explicitly defined. (Note that if the
property on the exporting system had a default value, that value is not exported
because default values are never exported.)
PropertySync is not enabled. (For more information on PropertySync, see Using

PropertySync to import and export properties on page 132.) If PropertySync is
enabled and properties values are missing, the import will fail.
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 that property to continue using the Import wizard.
1 In the Missing Property Name list, select a property and click Change Property
Mapping .
The local field for the selected property becomes active, and it displays utilities for
editing the value of the selected property.
2 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 142.

Importing objects
3 Repeat the two previous steps for each property listed in the Missing Property Name
list.
Map Existing System Package Types

The Map Existing System Packages Type panel lets you identify the type of system
packages you are importing. 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 displays this panel when you are importing system
packages.
1 In the System Package Type Selection list, select a system package type and click
Change System Package Type Mapping .
The Edit System Package Type Name dialog opens.
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.
3 Repeat the previous steps for each system package type in the System Package
Type Selection list.
Map Missing BLPackages

The Map Missing BLPackages panel lets you identify a BLPackage that should take
the place of a BLPackage referenced by the object you are importing. 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.
1 In the BLPackage Selection list, select a BLPackage and click Change BLPackage
Mapping .
The Select Depot Object dialog opens.
2 Using the Select Depot Object dialog, navigate to the BLPackage that should take
the place of the missing BLPackage you have selected and click OK.

Importing objects
3 Repeat the previous two steps for each BLPackage in the list.
Map Missing Component Templates

The Map Missing Component Templates panel lets you identify a component
template that should take the place of a component template referenced by the object
you are importing. 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.
1 In the Component Template Selection list, select a component template and click
Change Component Template Mapping .
The Component Templates dialog opens.
2 Using the Component Templates dialog, navigate to the component template that
should take the place of the missing component template you have selected and
click OK.
3 Repeat the previous two steps for each component template in the list.
Map Missing Depot Objects

The Map Missing Depot Objects panel lets you identify depot files and software that
should take the place of depot files and software referenced by the object you are
importing. The Import wizard only displays this panel when the object you are
importing 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.
1 In the Depot Object Selection list, select a file or software and click Change Depot
Object Mapping .
2 Using the Select Depot Object dialog, navigate to the file or software that should
take the place of the missing soft-linked depot object you have selected and click
OK.

Importing objects
If you are mapping a missing file, the dialog only lets you map to a depot file on
importing system; if you are mapping missing software, the dialog only lets you
map to depot software.
3 Repeat the previous two steps for each depot object in the list.
Map Missing Component Discovery Jobs

The Map Missing Component Discovery Jobs panel lets you identify Component
Discovery Jobs that should take the place of Component Discovery Jobs referenced by
the Batch Job you are importing. The Import wizard only displays this panel when
the object you are importing 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.
1 In the Component Discovery Jobs Selection list, select a Component Discovery Job
and click Change Component Discovery Job Mapping .
The Select Component Discovery Job dialog opens.
2 Using the dialog, navigate to the Component Discovery Job that should take the
place of the missing job you have selected and click OK.
3 Repeat the previous two steps for each Compliance Job in the list.
Map Missing Compliance Jobs

The Map Missing Compliance Jobs panel lets you identify Compliance Jobs that
should take the place of Compliance Jobs referenced by the Batch Job you are
importing 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.
1 In the Compliance Jobs Selection list, select a Compliance Job and click Change
Compliance Job Mapping .
The Select Compliance Job dialog opens.

Importing objects
2 Using the dialog, navigate to the Compliance Job that should take the place of the
missing job you have selected and click OK.
3 Repeat the previous two steps for each Compliance Job in the list.
Map Missing Deploy Jobs

The Map Missing Deploy Jobs panel lets you identify Deploy Jobs that should take
the place of Deploy Jobs referenced by the Batch Job you are importing. The Import
wizard only displays this panel when the object you are importing 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.
1 In the Deploy Jobs Selection list, select a Deploy Job and click Change Deploy Job
Mapping .
The Select a Deploy Job dialog opens.
2 Using the dialog, navigate to the Deploy Job that should take the place of the
missing job you have selected and click OK.
3 Repeat the previous two steps for each Deploy Job in the list.
Map Missing Network Shell Scripts

The Map Missing NSH Scripts panel lets you identify Network Shell scripts that
should take the place of scripts referenced by a Network Shell Script Job you are
importing 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.
1 In the NSH Scripts Selection list, select a script and click Change NSH Script Mapping
.

Importing objects
2 Using the dialog, navigate to the script that should take the place of the missing
script you have selected and click OK.
3 Repeat the previous two steps for each script in the list.

Chapter
5
5 Properties
Most system objects in BMC BladeLogic have properties associated with them. These
properties define a wide range of characteristics. Typically you manage properties
using a master list called the Property Dictionary (see Using the Property
Dictionary on page 118).
The Property Dictionary organizes properties into classes and sub-classes. Each sub-
class inherits all properties defined for its parent class. Each parent class inherits the
properties defined for the root system object in the Property Dictionary.
Most built-in classes or sub-classes in the Property Dictionary correspond to a type of

system object in BMC BladeLogic. 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 BladeLogic automatically inherits all the
properties assigned to its corresponding class or sub-class in the Property Dictionary.
For example, if you add a property to the Server class, every server automatically
inherits that property.
All system objects in BMC BladeLogic 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.
Throughout BMC BladeLogic 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-style 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 BladeLogic 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.

Using the Property Dictionary
In addition to BLPackages, you can use parameters and properties in 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.
Another common use for properties is to assign values to objects so those values can
be used elsewhere in BMC BladeLogic. For example, a property can indicate an
objects development status (for example, DEV, QA, or PROD). Or, a property can
indicate that a server is off line.
Properties are also used to define smart groups, which are groups of objects that are
automatically populated based on criteria in the form of property settings (see
Defining a smart group on page 92). All folders except RBAC Manager let you
create smart groups. In BMC BladeLogic 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.
See the following for additional information about using properties:

Inserting a parameter
Setting values for system object properties
Changing property values for one or more system objects

The Property Dictionary is a master list of all properties that can be assigned to
system objects.
The Property Dictionary presents two types of property classes: built-in and custom.
Both types are hierarchical collections of classes and sub-classes. Each class and sub-
class can contain its own properties. In addition, every sub-class inherits all the
properties of its parent class.

Built-in property classes are associated with particular 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 sub-
class are automatically associated with all Network Shell Script Jobs. Note that many
of the properties in the Network Shell Script Jobs sub-classand all sub-classesare
inherited from the Jobs class.
BMC BladeLogic lets you create hierarchical custom property classes and sub-classes.
To each custom 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
sets built from custom classes and sub-classes. Then, you can create multiple
instances of these property sets. For each instance, you can set individual properties
to particular values.
BMC BladeLogic lets you export properties, property classes, and property set
instances from one Application Server and import them into another Application
Server. This capability lets you synchronize properties between Application Servers.
Once properties are synchronized, it becomes easier to export and import other types
of system objects between systems because all property dependencies should be
satisfied on the importing system. BMC BladeLogic calls this kind of synchronizing
activity a PropertySync import or PropertySync export.
To explicitly associate a custom property class with a system object, you must create a
property class property, which is a particular type of property that references another
property class or sub-class (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 Understanding
custom property classes and instances on page 120.
In general, all roles can read the Property Dictionary; there are no special permissions
required to view it. However, to view instances of custom property classes, your role
must have, at minimum, a PropertyInstance.Read authorization. For information on
granting authorizations to roles, see Creating roles on page 173.
The Property Dictionary lets you perform the following procedures:
Adding a custom property class

Adding or modifying properties
Removing or deprecating a property, custom property class, or instance
Using PropertySync to import and export properties
Creating or modifying an instance of a property class
Viewing and modifying properties for property classes

Understanding custom property classes and instances

Custom property classes let you create complex sets of properties that you can
associate with an object such as a BLPackage. Because sub-classes 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.
Eastern
Division
Application A Application B
custom
property
classes and
sub-classes
Version Version Version Version
211 212 301 302
DEV QA DEV QA DEV QA DEV QA
1 1 1 1 1 1 1 1
2 2 2 2 2 2 2 2 instances
3 3 3 3 3 3 3 3

The following graphic focuses on 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 sub-classes. The following graphic shows how one property defined
at each level propagates downward through the structure.
Properties Inherited From Default Value Local Value

Eastern
Division ROOT_DIR <not inherited> /c
ROOT_DIR Eastern Division /c

Application A
APP_DIR <not inherited> apps/a
Version ROOT_DIR Eastern Division /c

211 APP_DIR Application A apps/a
VER_DIR <not inherited> 211

DEV APP_DIR Application A apps/a
VER_DIR Version 211 211
LEVEL_DIR <not inherited> <no default>

APP_DIR Application A apps/a
1
LEVEL_DIR <not inherited> <no default> dev1

2 APP_DIR Application A apps/a apps/sandbox/a

3 APP_DIR Application A apps/a apps/experimental/a

Collectively 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 sub-class. In this example, the
DEPLOY_LOC property refers to the DEV custom property sub-class, which includes
the properties ROOT_DIR, APP_DIR, VER_DIR, and LEVEL_DIR. Three instances of
the DEV custom property class have been defined.
The path to the BLPackages 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.
While this example examines one set of properties on one branch of a custom
property class hierarchy, you can use the same approach on every branch of the entire
hierarchy. You can also use other properties to establish other types of information
that is inherited downward throughout the hierarchy.

Use this procedure to add custom property classes to the Property Dictionary.
When you create a custom property class, the permissions you define for that system
object are not inherited by any sub-classes. This lets you create a custom property
class and define some properties for it. Then, you can create a sub-class that inherits
the properties defined for the parent class. For the sub-class, you can grant the
Modify permission to another role (for example, the JuniorAdmin role). With a
custom property class structure like this, the sub-class inherits the properties defined

for the parent-class. The JuniorAdmin role cannot delete the properties that the sub-
class 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 sub-class.
To perform this procedure, your role must have, at minimum, a

PropertyClass.CreateCustom authorization. For information on granting
authorizations to roles, see Creating roles on page 173.
To modify an existing custom property class, you must modify its properties, much
like you would for any other system object. For more information on this procedure,
see Setting values for system object properties on page 140.
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 sub-class. 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.
3 For Name, enter the name of a custom property class. For Description, you can
optionally provide descriptive text.
4 If you want this custom property class to be included when a parent class or the
entire Property Dictionary is exported, check Synchronize.
Typically, you export the Property Dictionary or a custom property class from one
system and import it into another so the properties on both systems can be
synchronized. Clearing the Synchronize option lets you exclude property classes
that should not be exported and thus should not be included in a PropertySync
import.
The Synchronize option is only displayed when you have enabled PropertySync
using the Application Server Administration console (that is, the blasadmin
utility). For more information on that procedure, see the BMC BladeLogic Server
Automation Administration Guide.
5 Click Next. The Properties panel of the Create New Property Class wizard opens.
Use the Properties panel to add properties to the custom property class.
The Properties panel lets you 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 125.
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 BladeLogic uses ACLs to control access to all objects.
For more information on defining an ACL, see Defining permissions for a system
object on page 186.
7 Click Finish to save the new custom property class.
8 Click Close to close the Property Dictionary.

Use this procedure to add or modify properties. You can add properties to both
custom and built-in classes. You can also use this procedure to 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.
In addition, the new property is inherited by all subordinate built-in sub-classes.
When you create a property in the Property Dictionary, the property is available
globally throughout BMC BladeLogic. All roles have access to that property. You can
use a parameter to reference the new property in any situation where BMC
BladeLogic 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. For more information on using local properties,
see Editing a component template on page 260, Editing a BLPackage on page 383,
and Chapter 25, Provisioning servers.
The following table describes the types of data that properties can accept, including
any 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.
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.

Data Type Limitations

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 Regular expression formats provided by the
permission bitmasks and regular expressions Java Development Kit (JDK) 1.4. Regular
expressions are limited to 2,000 characters.
References to a custom or built-in property User-defined custom property classes or
class built-in property classes.
Property class properties reference another property class. If you want to apply a
custom property class to an object, you must create a property class property that
refers to that custom property class. Then you can 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 on creating instances, see
Creating or modifying an instance of a property class on page 129.
NOTE
When you create an instance of a custom property class, many dependencies are established
for the properties included in the custom property class. Because of these dependencies, 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 that 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.
1 Do any of the following:
Choose Configuration => Property Dictionary View. Using the Property Class
Navigation pane, select a property class or sub-class for which you want to add
or modify a property. In the property list on the right, select the Properties tab.

Using the Property Dictionary, add a new custom property class (see Adding a
custom property class on page 123). In the property list on the 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. Then, 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 opens. Depending on your context, the name of this dialog may
vary.
3 For Name, enter the name of the property. For Description, you can optionally
4 For Type, do one of the following:
Select Simple and then, from the drop-down list to the 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:
A. Click Browse to the right of Possible values. The Edit Enumeration dialog
opens.
B. Click Add New Value . The Enumeration Editor dialog opens.
C. 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. Then, for Value, enter a possible 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.
D. Click OK.
E. To add another value, repeat step B through step D.
Select Complex and then, from the drop-down list to the right, select the type of
data that can be provided for this property.

Select Property class and then click Browse to the right. The Property Class
Selection dialog opens. Use this dialog to select a custom or built-in property
class or sub-class. Then click OK.
For an extended discussion of using property classes and property class

property types, see Understanding custom property classes and instances on
page 120.
5 To specify a default value for the property check Use this default value. Then, for
Default value, enter a default.
The method you use for entering a default value depends on the property type you
selected 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, you can click Browse to the right of Default value,
which displays the Edit Long Text dialog. There you can 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 sub-class, 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 BladeLogic. 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.


Use this procedure to create or modify an instance of a property class. An instance is a
set of properties and property values associated with a property class. 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 sub-classes:
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.) If you want
property values defined 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 Understanding custom property classes
and instances on page 120.
1 Choose Configuration => Property Dictionary View.
2 Navigate to the property class or sub-class for which you want to create an
instance.
3 Click the Instances tab.
4 Do one of the following
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 displays. The only difference between this
window and the New Instance wizard is that you display panels by selecting
tabs instead of stepping through the 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 that 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 If you want this instance to be included when its property class or the entire
Property Dictionary is exported, check Synchronize.
synchronized. Clearing the Synchronize option lets you exclude property class
instances that should not be exported and thus should not be included in a
PropertySync import.
When you check the Synchronize option for an existing property class instance and
the Synchronize option was previously cleared, the change is automatically
propagated to the property class that is the basis of the instance and to all ancestors
of that property class.
The Synchronize option is only displayed when you have enabled the export/
import of property classes using the Application Server Administration console
(that is, the blasadmin utility). For more information on that procedure, see the
BMC BladeLogic Server Automation Administration Guide.
7 To set values for a particular property in the custom property class, double-click
that property. The Set Property Value dialog opens. Enter a value for the property
and click OK. For more information on setting property values, see Setting values
for system object properties on page 140.
8 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 BladeLogic, including the sharing of objects between
roles, is controlled through ACLs. For more information on defining an ACL, see
9 Click Finish.

Removing or deprecating a property, custom property class, or instance
Removing or deprecating a property, custom property class,

or instance
Use this procedure to 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 elsewhere in BMC BladeLogic, as described below:
A property cannot be removed
when the property is referenced, such as in a parameter or component template

signature.
when the property is 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

when the custom property class has a sub-class
when an instance of the custom property class exists
NOTE
If a property class property references a custom property class and that property class
property has been 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 older version of that object will continue 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 is no longer displayed in the Property Dictionary. Once it is
deprecated, you cannot create another property, custom property class, or instance
with the same name. If you attempt this, BMC BladeLogic will ask if you want to un-
deprecate the item. If you do, the property, custom property class, or instance is
returned to the Properties Dictionary.
2 Using the Property Class Navigation pane, do one of the following:
Select the property class or sub-class from which you want to delete a property.
Click the Properties tab and select the properties you want to remove.

Select a custom property class or sub-class to remove.
Select a property class or sub-class for which you want to delete an instance.
Click the Instance tab and select the instances you want to remove.
3 Click Remove .
The selected items are removed unless an item is being used elsewhere in BMC
BladeLogic. If an item is in use, a message asks if you want to mark the item as
deprecated.
4 If necessary, click Yes to deprecate an item.

BMC BladeLogic allows you to export and import an entire Property Dictionary or a
specific custom property class. BMC BladeLogic calls this a PropertySync because
importing a Property Dictionary synchronizes the properties on the importing
Application Server with the properties defined on the exporting Application Server.
Typically, you perform a PropertySync so you can more easily export and import
other types of system objects such as jobs or component templates. If properties are
synchronized between systems, all the property dependencies are satisfied when you
move objects between Application Servers.
When performing a PropertySync, you can specify that certain property classes or
instances of property classes should not be synchronized. If you make this
specification, the property class or instance is not exported and thus cannot be
imported into the system being synchronized. For information on how to specify that
a property class or instance should not be synchronized, see Adding a custom
property class on page 123 or Creating or modifying an instance of a property
class on page 129. The left pane of the Property Dictionary includes a column called
Synchronize, which tells you at a glance whether a property class should not be
synchronized.
PropertySync synchronizes property data not just by adding property information to

the importing system but also by removing it. For example, any properties that exist
on the importing system but do not exist on the exporting system are deleted from the
importing system if the property classes to which they belong are supposed to be
synchronized.
When exporting and importing properties, the following procedures are possible:
Exporting the Property Dictionary or a custom property class on page 133

Importing the Property Dictionary or a custom property class on page 133

Exporting the Property Dictionary or a custom property

class
Use this procedure to perform a PropertySync export of the entire Property
Dictionary or a specific custom property class.

PropertyClass.ExportDictionary authorization. For information on granting
NOTE
To enable export of the Property Dictionary or custom property classes, you must use the
Application Server Administration console (that is, the blasadmin utility) to set the
PropertySync option to true. For more information on this procedure, see the BMC BladeLogic
To export the entire Property Dictionary, select SystemObject (the root node of
the Property Dictionary).
To export a particular custom property class, expand the Custom Property

Classes folder and select a custom property class.
3 Click Export .
The Export window opens.
4 For Save to, enter the path or use the hierarchical tree to select the directory where
you want to save the exported Property Dictionary or custom property class.
5 Click Export.
If you are exporting the Property Dictionary, it is exported under the name
PropertyDictionary. If you are exporting a custom property class, it is exported
under its name.
Importing the Property Dictionary or a custom property

class
Use this procedure to perform a PropertySync import of a Property Dictionary or a
specific custom property class.

When you perform a PropertySync import of a custom property class, you do not
have to specify the location to which the property class should be imported. BMC
BladeLogic determines that location automatically from the data being imported.
Many situations can cause a PropertySync import to fail. For a detailed discussion of
these situations, see PropertySync error scenarios on page 134.

PropertyClass.ImportDictionary authorization. For information on granting
NOTE
To enable import of a Property Dictionary or custom property class, you must use the
Application Server Administration console (that is, the blasadmin utility) to set the
PropertySync option to true. For more information on this procedure, see the BMC BladeLogic
2 Click Import .
The Import wizard opens, displaying the Select Import Source Directory panel.
This panel lets you identify the file that contains the BMC BladeLogic object you
want to import.
3 For Import from, enter the path to a directory or use the hierarchical tree to select
the top-level directory representing the Property Dictionary or custom property
class you want to import.
4 Click Next to display the Import Contents panel, which shows that a Property
Dictionary object is being imported.
5 Click Finish to complete the import process.
PropertySync error scenarios

When importing the Property Dictionary, many conditions can cause the import to
fail. When a PropertySync import fails, all data that has been imported is rolled back,
so no changes are made to the Property Dictionary on the importing system. The
import utility displays an error message identifying the property, property class, or
property set instance causing the error.
The following table describes the most common scenarios that can cause a
PropertySync import to fail. For each scenario, the table provides recommendations
for resolving the problem.

Problem Scenario Solution

You have removed a property, property Do one of the following:
class, or property set instance on the
exporting system. On the importing system On the importing system, remove all
an object or a property class or property set references to the missing property,
instance that is not being synchronized property class, or property set instance.
references the missing property. Then re-run the PropertySync import.
On the exporting system, re-create the

property, property class, or property set
instance that is causing the error and re-
run the export. Then, on the importing
system, re-run the PropertySync import.
An import is adding a property class or Do one of the following:
property set instance. However, a property
class or property set instance with the same On the importing system, rename the
name already exists on the importing system property class or property set instance
and that property class or property set that is causing the conflict. Then re-run
instance is not being synchronized. the import.
On the exporting system, rename the

property class or property set instance
that is causing the conflict. Re-run the
export. Then, on the importing system,
re-run the PropertySync import.
A property exists on the importing system Do one of the following:
and the property has the same name as a
property that is imported via PropertySync. On the importing system, rename the
The property on the importing system is property that is causing the conflict.
defined in a sub-class of a property class. The Then, re-run the PropertySync import.
property class is being synchronized but the
sub-class where the property is defined is not On the exporting system, rename the
being synchronized. property that is causing the conflict. Re-
run the export. Then, on the importing
For example, suppose the exporting system system, re-run the PropertySync import.
has a property class called A that contains a
property called A1. On the importing system
there is an older copy of property class A,
and it has a sub-class called B. The sub-class
is not being synchronized. Sub-class B
contains a property called A1.


On the exporting system, a property exists in Do one of the following:
a property class that is being synchronized.
The property is required but no default value On the importing system, add the
is defined. On the importing system, one or property to the property class. Define the
more property set instances of the same property so it is not required. In the non-
property class exist. These instances are not synchronized property set instances, set
being synchronized, and these instances do values for the property. Then, re-run the
not define a value for the property. PropertySync import.
On the exporting system, provide a

default value for the required property.
Re-run the export. Then, on the
importing system, re-run the
A custom property class is exported, and it is Do one of the following:
a subset of one or more custom property
classes on the exporting system. On the On the importing system, add the
importing system, one or more of the custom missing custom property set classes.
property classes that are parents of the Then, re-run the PropertySync import.
exported property class do not exist.
On the exporting system, export a larger
For example, suppose the exporting system subset of the Property Dictionary
has a hierarchy in which custom property (possibly the entire dictionary) to ensure
class A is the parent of B, and B is the parent that all necessary parent classes are
of C. The root of the export is B. On the exported. Then, on the importing system,
importing system, custom property class A re-run the PropertySync import.
does not exist.
A subset of the total property dictionary is Do one of the following:
exported, but that exported subset refers to
one or more properties from a parent class On the importing system, manually add
that is not exported, and those properties do the missing properties. Then, re-run the
not exist in the parent class on the importing PropertySync import.
system.
On the exporting system, export a larger
For example, suppose the exporting system subset of the Property Dictionary,
has a hierarchy in which property class A is including the property classes where the
the parent of B, and B is the parent of C. missing properties are defined. Then, on
Property class A includes a property A1. The the importing system, re-run the
user exports the Property Dictionary starting PropertySync import.
at property class B, including a property set
instance of B that contains a value for On the exporting system, remove all
property A1. In this situation, property class references to properties that are missing
A on the importing system must include a on the importing system from the subset
property A1. of property data that must be exported.
Re-run the export. Then, on the
importing system, re-run the


On the exporting system, a property exists in Do one of the following:
a property class that is being synchronized.
This property already exists on both the On the importing system, remove the
importing and exporting systems, and values for the property from the non-
previously it was editable. Now the property synchronized property set instances.
is being changed so it is not editable. On the Then, re-run the PropertySync import.
importing system, one or more property set
instances of the same property class exist. On the exporting system, make the
These instances are not being synchronized, property editable. Re-run the export.
and these instances define a value for the Then, on the importing system, re-run the
property. PropertySync import.
On the exporting system, a property that Do one of the following:
requires enumerated values exists in a
property class that is being synchronized. On the importing system, remove any
This property already exists on both the uses of the deleted enumerated values.
importing and exporting systems. On the Then, re-run the PropertySync import.
exporting system, one or more of the
enumerated values for this property are On the exporting system, re-create the
deleted, but those values are still in use by enumerated values that were previously
that property on the importing system. deleted for the property. Re-run the
export. Then, on the importing system,
re-run the PropertySync import.

For all property classes in the Property Dictionary, you can display a properties
dialog. This dialog provides tabs that display general identifying information,
permissions, and audit trail entries.
The General tab of the properties dialog for a property class provides information
identifying the object. Most of the information on the General tab cannot be modified
except for one option that lets you choose whether a custom property class should be
synchronized when you export the Property Dictionary.
The Audit Trail tab provides a record of roles and users that have sought
authorization for this object. For more information on audit trails, see Audit Trail
view on page 99.
1 Right-click a property class in the Property Dictionary and select Properties from
the pop-up menu. A tabbed dialog displays.
2 Using the tabs on this dialog, you can perform the following actions:
Choosing to synchronize custom property classes on page 138

Defining permissions for a system object on page 186

3 Click OK.
Choosing to synchronize custom property classes

synchronized. By clearing the Synchronize option, you can exclude custom property
classes that should not be exported and thus should not be included in a
When you change the Synchronize option for an existing custom property class, the
following can occur:
When you clear the Synchronize option and it was previously checked, the change
is automatically propagated to all property set instances for this custom property
class, all custom property classes that are descendents of this property class, and
all property set instances of those descendents.
When you check the Synchronize option and it was previously cleared, the change
is automatically propagated to all custom property classes that are ancestors of this
property class.
The Synchronize option is only displayed when you have enabled PropertySync
using the Application Server Administration console (that is, the blasadmin
utility). For more information on that procedure, see the BMC BladeLogic Server
1 Right-click any custom property class and select Properties from the pop-up menu.
A tabbed dialog displays. The General tab is already selected.
2 If the Synchronize option is displayed, select it if you want this custom property
class to be included when its parent class or the entire Property Dictionary is
exported.
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.
1 In the Property Dictionary, right-click a property class and select Properties from
the pop-up menu.
2 On the resulting dialog, click the Permissions tab.

To add a set of authorizations for a role, do the following:
A. Click Add Entry . The Add New Entry window opens.
B. From Role, select a role to which you want to grant permissions.
C. 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.
Use Shift-click or Control-click to select multiple authorizations. Click the

right arrow to move your selections to the Selected Authorizations list.
D. Click OK.
To use an ACL template to add a predefined set of permissions to one or more

roles, do the following:
A. Click Use ACL Template . The Select ACL Template dialog opens.
B. Select one or more ACL templates on the dialog.
C. If you want the contents of the selected ACL templates to replace all entries in
the access control list, check Replace ACL with selected templates.
If you do not check this option, the contents of the selected ACL templates are
appended to any existing entries in the access control list. Replacing the
current set of permissions with the contents of an ACL template is
particularly useful when promoting a system object between roles.
D. Click OK.

To apply ACL policies (sets of permissions that are centrally managed), do the
following:
A. Click Use ACL Policy . The Select ACL Policy dialog opens.
B. Select one or more ACL policies on the dialog.
C. If you want the contents of the selected ACL policies to replace all entries in
the access control list, check Replace ACL with selected policies.
If you do not check this option, the contents of the selected ACL policies are
appended to any existing entries in the access control list. Replacing the
current set of permissions with the contents of an ACL template is
D. Click OK.
To delete an entry, select the entry and then click Delete Entry .

When you select a system object, the Properties view lists the properties for that
object. Similarly, when you use a wizard to create most types of system objects, you
encounter an identical list of properties. The following procedure can be used in
either context for setting the value of a system property. This procedure is referenced
by many other procedures that describe how to create or modify system 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.
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 .

Changing property values for one or more system objects
The value of the property is reset to the value it inherits from a built-in property
class.
Depending on the type of property you are editing, you can take different
actions to set a new value, such as entering an alphanumeric string, choosing
from an enumerated list, or selecting a date. To insert a parameter into the value,
enter the value, bracketed with double question mark delimiters (for example,
??MyPARAMETER??) or click the Select Property . For more information, see
Changing property values for one or more

system objects
Use this procedure to change a property value 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.
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 table view. Then select
the items you want to modify.
Note that 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:
class.

??MyPARAMETER??) or click Select Property . For more information, see
5 Click OK.
The new value is applied to all selected system objects.
Inserting a parameter is a common activity throughout BMC BladeLogic. Many other
procedures reference this procedure.
To insert a parameter, enter the name of the property delimited with two question
marks, such as ??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 like ??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, since a target for a Deploy Job is a
server.)
In any situation where you can enter a parameter, BMC BladeLogic 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.
1 Access a situation in BMC BladeLogic 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 displays. 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.


Chapter
6
6 Managing access
BMC BladeLogic 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 BladeLogic system of access control gives you
extremely 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
particular types of actions occur.
See any of the following for introductory information about managing access in BMC
BladeLogic:
Understanding authorizations
Managing authorizations
Enforcing authorizations
Managing audit trails
Built-in roles and users
Understanding authorizations
In BMC BladeLogic, 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.

Role-based authorizations
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 BladeLogic, including objects that
function as resources, such as servers and components.
Performing any action in BMC BladeLogic typically requires three levels of

authorization:
Object-based authorizations
Resource-based authorizations
The combination of role-based and object-based authorizations determines a users

effective authorizationsthat is, the actions a role can actually perform on a system
object.
Authorizations are granted to roles so they can perform certain types of actions. To
accomplish this 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
fully 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
permissionsmust also be satisfied.
Object-based authorizations
When you create any system object in BMC BladeLogic, 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 BladeLogic, 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.
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. 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 permissions for the
particular Deploy Job you want to run. Finally, you must also be granted Server.Read
and Server.Modify on the server that is the target of the Deploy Job.
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.
Managing authorizations
To manage authorizations, you must use the functionality of the RBAC Manager
folder as well as the ability to set permissions for any system object throughout BMC
BladeLogic. When setting up and using authorizations, BMC BladeLogic
recommends the work flow described in the following sections.

Set up authorizations
Set up authorizations
Authorizations are permissions to perform certain types of actions in BMC
BladeLogic. There are two types of authorizations: system and command. A system
authorization grants permission to perform a certain class of action, such as creating a
particular type of job or creating components. A command authorization grants
permissions to perform certain Network Shell and nexec commands. For more
information, see Setting up authorizations on page 156.
Create authorization profiles

An authorization profile is a group of system and command authorizations. Once you
create authorization profiles, you can 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 159.
Create ACL templates

An ACL template is a collection of authorizations granted to one or more roles but not
associated with a specific object. Once you create ACL templates, you can use them to
repeatedly assign complex sets of authorizations to system objects throughout BMC
BladeLogic. 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 (see Create ACL
policies on page 149).
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 particularly 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 161.

Create ACL policies
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. That capability is particularly useful for large 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 165.
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.
Automation principals and server management
When using BMC BladeLogic 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 there are two possible approaches:
Windows user mapping. In this approach, the operating system on a managed

Windows server can recognize the identity encapsulated in an automation
principal. When BMC BladeLogic performs an action on a managed server, the
system can map a role to an automation principal, in effect mapping the role to
the identity in the automation principal.
User privilege mapping. In this approach, users are granted permissions on

managed servers through the BMC BladeLogic configuration files.
On UNIX servers, the RSCD agent is able to use a setuid command to fully
impersonate a user on the managed server.

Create roles
You must use the BMC BladeLogic configuration files (exports, users, and users.local)
on each managed server to set up UNIX user impersonation or Windows user
privilege mapping. For information on that process, see the BMC BladeLogic Server
If you want to set up Windows user mapping, you must define an automation
principal in RBAC. Then you must associate the automation principal with a role. For
information on creating automation principals, see Creating automation principals
on page 169. For information on mapping automation principals to roles, see Agent
ACL on page 175.
NOTE
Only Windows servers running BMC BladeLogic 8.0 or later can recognize automation
principals.
Deploy Jobs and File Deploy Jobs that include repeaters use Windows user mapping only
when communicating with the repeater or a target server. When the repeater
communicates with targets, communication is based on user privilege mapping.
Create roles
A role defines a set of authorizations 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. For more information, see Creating roles on page 173.
Create users
Creating a user in the RBAC Manager folder sets up a user account so an individual
can access the BMC BladeLogic 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 179.
BMC BladeLogic also provides a set of BLCLI commands that can synchronize your
RBAC user database with Active Directory. For more information, see
Synchronizing users with Active Directory on page 184.

Assign object-based permissions
Assign object-based permissions

For every system object in BMC BladeLogic, 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 Using object-based permissions on
page 186.
Update permissions for multiple objects

After you have established 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 190.
Enforcing authorizations
When you are using the BMC BladeLogic console, the BMC BladeLogic 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 can be used. 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 BladeLogic 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 195). This job uses the authorizations
specified for all roles granted access to a server and generates entries 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 on how BMC BladeLogic converts role information into entries in a users
configuration file, see Using agent ACLs on page 192.
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.

No access nodes
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 on Windows user mapping, see
Creating automation principals on page 169.
No access nodes
A no access node represents a system object that you can see in a BMC BladeLogic
console but you cannot interact with because you do not have the appropriate
authorizations. BMC BladeLogic uses italics to distinguish no access nodes from
system objects for which you have permissions. Using preferences you can specify
whether a BMC BladeLogic console displays no access nodes (see Customizing
preferences on page 73).
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.
Managing audit trails

Audit trails record who attempts to perform specific actions in BMC BladeLogic. All
actions in BMC BladeLogic must be authorized. An audit trail entry can be generated
every time a user is successfully authorized for an action, every time a user is denied
authorization, or in both cases. To view an audit trail for any system object, see
Audit Trail view on page 99.
You can specify what authorizations are logged in an audit trail. To accomplish this,
you define properties for the system authorizations listed in the Authorizations node.
For more information on this process, see Defining audit trails on page 158.


A standard BMC BladeLogic 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 BladeLogic. 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 BladeLogic. This allows
the RBACAdmins role to always have access to any system object in BMC
BladeLogic. 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 BladeLogic. This allows the BLAdmins role to view all
activity within BMC BladeLogic. In addition, out-of-box authorizations grant the
BLAdmins role full authority to perform any actions on any system object in BMC
BladeLogic 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 BladeLogic
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 Granted * authorization for
on all objects in BMC all system objects relating to
BladeLogic (for example, RBAC (for example, Role.*
BLPackage.Read). and ACLTemplate.*).
Granted ModifyACL Granted Server.PushACL to

authorization on all objects in push ACLs to servers.
BMC BladeLogic (for example,
BLPackage.ModifyACL). The above authorizations
can be modified as
The above authorizations are necessary.
built-in and cannot be
modified.

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

BLAdmins Granted Read authorization Granted * authorization on
on all system objects within all classes of system objects
BMC BladeLogic. within BMC BladeLogic
except the following:
The Read authorization is
built-in and cannot be Role.Read (grants read-
modified. only access to roles)
AuthProfile.Read (grants
read-only access to
authorization profiles)
PatchAnalysisConfig.Mo
dify (used for modifying
the download locations
for Windows patch
analysis configurations)
The above authorizations

can be modified as
necessary.
GlobalReportAdmins Granted all reports-related
authorizations in RBAC,
including
Reports.Administration, which
allows the role to manage BMC
BladeLogic Decision Support for
Server Automation.
GlobalReportViewers Granted all reports-related
authorizations in RBAC except
Reports.Administration.
BMC BladeLogic has designed built-in and out-of-box authorizations to make it easy
to manage access permissions with no further modifications. However, if you want 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 other sets of
authorizations, and you can use object-based permissions to further restrict access
throughout the BMC BladeLogic system.
In addition to the built-in roles, BMC BladeLogic 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 on the Everyone role see Defining

RBACAdmin and BLAdmin users
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 that object without having to revise an ACL template
for each different role. For more information on Current Role, see Creating an
ACL template on page 161.
RBACAdmin and BLAdmin users

A standard BMC BladeLogic 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 a single 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 on the default Network Shell role, see Role selection on page 182.
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 BladeLogic, you use the Post-
install Configuration Wizard to set up a password for the RBACAdmin user, as
described in the BMC BladeLogic Installation Guide. However, you can also use
bladduser utility to set up the RBACAdmin and BLAdmin users, as described in
Using the bladduser utility on page 204.
Setting up authorizations
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

BladeLogic. 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
Appendix A, System authorizations.. In the RBAC Manager folder, the only action
you can take to set up a system authorization is to specify how that authorization is
used to generate an audit trail.

Adding or modifying an nexec command
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 BladeLogic installation includes many default nexec
commands. You can also can add and delete custom nexec commands. A custom
nexec command can consist of anything that can be executed using the Network Shell
nexec command, including scripts stored on remote servers.
Using the Authorization node, you can perform the following procedures:

Deleting an nexec command
Defining audit trails

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.
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 displays.
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 Click Finish to close the wizard and save your changes.


Use this procedure to 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 BladeLogic installation.
To perform this procedure, you must have, at minimum, the Authorization.Delete

system authorization.
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 prompts you to confirm the
deletion.
4 Click Yes.
Defining audit trails

An audit trail is a record of who has sought authorization for specific actions in BMC
BladeLogic. 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 BladeLogic.
For information on viewing the audit trail for a system object, see Audit Trail view
on page 99.
To define audit trail preferences, your role must be granted the Authorization.Modify
authorization.
2 Under Authorizations, expand System Authorizations.
All possible system authorizations in BMC BladeLogic are displayed under the
System Authorizations node.
3 Select an authorization, right-click, and select Open from the pop-up menu. A
properties dialog opens.
4 Check Success to log information every time this authorization is requested and the
authorization is granted. Check Failure to log information every time this
authorization is denied.

Creating an authorization profile
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
to choose a server.
6 Click OK.
Creating an authorization profile

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 173).

Granting permissions to individual system objects (see Defining permissions for a
system object on page 186).
Specifying authorizations in an ACL template (see Creating an ACL template on
page 161).
Assigning authorizations to an ACL profile (see Creating an ACL policy on
page 165).
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 160 for information on
modifying an existing authorization profile.
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 displays.

Authorizations
3 Provide information for different aspects of the authorization profile, as described

in the following sections:
Authorizations
Permissions
4 Click Finish at any time to close the wizard and save your changes.
Authorizations
The Authorizations panel lets you identify an authorization profile and select the
system and command authorizations it should include.
1 For Name, enter the name you want to assign to the authorization profile. For
Description, you can optionally provide descriptive text.
2 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.
3 Click the right arrow to move your selections to the Selected Authorizations list.
Permissions
The Permissions panel is an access control list granting roles access to this
authorization profile object. Access to all objects in BMC BladeLogic, including the
sharing of objects between roles, is controlled through ACLs. For more information
on defining an ACL, see Defining permissions for a system object on page 186.
Modifying authorization profiles

1 Open the RBAC Manager folder, expand the Authorization Profiles node, and
navigate to an existing authorization profile.

Creating an ACL template
Right-click the authorization profile and select Open from the pop-up menu. A
tab opens showing the authorizations chosen for this profile. Modify the
contents of this list. (For more information on this, see Authorizations on
page 160.)
Select the Properties, Permissions, or Audit Trail tab group to see or modify any of
properties, permissions, or audit trail information that apply to this
authorization profile. For more information, see Properties, Permissions, and
Audit Trail tab group on page 98.
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 173).
Granting permissions for an individual system object (see Defining permissions

for a system object on page 186).
Updating permissions for a group of system objects (see Updating permissions

for one or more system objects on page 190).
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 173). Once assigned to a role in this
way, each Current Role authorization is automatically translated into permissions for
that action for the current role. For example, suppose you create an ACL template
that grants AuditJob.* to Current Role. Then you specify the ACL template as the
object permissions template for a role. When that role creates an Audit Job, the role is
automatically granted AuditJob.* permission for the job.

General
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 every 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 164 for information on modifying
an existing 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 displays.
3 Provide information for different aspects of the ACL template, as described in the
following sections:
General
Template Access Control List
Permissions
4 Click Finish at any time to close the wizard and save your changes. Click OK to
close the ACL Template Properties window and save changes.
General
The General panel lets you provide a name and description for the ACL template.
1 For Name, enter the name you want to assign to the command profile. For

The Template Access Control List panel provides a list of roles that are granted a
particular system authorization, command authorization, or authorization profile.
You can also assign authorizations using ACL policies.

Action Procedure
To add a set of authorizations for a role 1. 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.
Use Shift-click or Control-click to select multiple authorizations.

Click the right arrow to move your selections to the Selected
Authorizations list.
4. Click OK.
5. To add authorizations for another role, repeat steps 1 through 4.

Permissions
Action Procedure
To use an ACL template to add a 1. Click Use ACL Template . The Select ACL Template dialog
predefined set of permissions to one or opens.
more roles
2. Select one or more ACL templates on the dialog.
3. If you want the contents of the selected ACL templates to

replace all entries in the access control list, check Replace ACL
with selected templates.
If you do not check this option, the contents of the selected ACL
templates are appended to any existing entries in the access
control list. Replacing the current set of permissions with the
contents of an ACL template is particularly useful when
promoting a system object between roles.
4. Click OK.
To apply ACL policies (sets of 1. Click Use ACL Policy . The Select ACL Policy dialog opens.
permissions that are centrally
managed) 2. Select one or more ACL policies on the dialog.
3. If you want the contents of the selected ACL policies to replace

all entries in the access control list, check Replace ACL with
selected policies.
If you do not check this option, the contents of the selected ACL
policies are appended to any existing entries in the access
control list. Replacing the current set of permissions with the
contents of an ACL template is particularly useful when
promoting a system object between roles.
4. Click OK.
To delete an entry Select the entry and click Delete Entry .
Permissions
The Permissions panel is an access control list granting roles access to this ACL
template object. Access to all objects in BMC BladeLogic, including the sharing of
objects between roles, is controlled through ACLs. For more information on defining
an ACL, see Defining permissions for a system object on page 186.
Modifying ACL templates

Use this procedure to modify an existing ACL template.

Creating an ACL policy
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
tabs appear in the content editor:
General
These tabs correspond to panels in the New ACL Template wizard. Use these
tabs to modify the ACL template.
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 98.
Creating an ACL policy

An ACL policy lets you manage a group of authorizations in a single location that
will automatically apply to multiple system objects. Any change you make to an ACL
policy immediately becomes effective for any object where that ACL policy has been
applied. If you delete an ACL policy, the system immediately removes the
permissions granted to any object using that ACL policy.
See Modifying ACL policies on page 167 for information on modifying an existing
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 displays.
3 Provide information for different aspects of the ACL policy, as described in the
following sections:
General
Policy Access Control List
Permissions

General
General
The General panel lets you provide a name and description for the ACL policy.
1 For Name, enter the name you want to assign to the ACL policy. For Description,

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.
Action Procedure
To add a set of 1. Click Add Entry . The Add New Entry window opens.
authorizations for a role
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
previous step.
To assign individual command authorizations, click the Commands tab at

the bottom of the Available Authorizations list. Then, select the command
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.
Use Shift-click or Control-click to select multiple authorizations. Click the

right arrow to move your selections to the Selected Authorizations list.
4. Click OK.
5. To add authorizations for another role, repeat steps 1 through 4.

Permissions
Action Procedure
To use an ACL template to 1. Click Use ACL Template . The Select ACL Template dialog opens.
add a predefined set of
permissions to one or more 2. Select one or more ACL templates on the dialog.
role
3. If you want the contents of the selected ACL templates to replace all
entries in the access control list, check Replace ACL with selected
templates.
If you do not check this option, the contents of the selected ACL templates
are appended to any existing entries in the access control list. Replacing
the current set of permissions with the contents of an ACL template is
4. Click OK.
To define or update a See Creating and modifying maintenance windows on page 168.
maintenance window for a
server
To delete an entry Select the entry and click Delete Entry .
Permissions
The Permissions panel is an access control list granting roles access to this ACL policy
object. Access to all objects in BMC BladeLogic, including the sharing of objects
between roles, is controlled through ACLs. For more information on defining an
ACL, see Defining permissions for a system object on page 186.
You cannot use ACL policies to assign permissions to use ACL policies.
Modifying ACL policies

Use this procedure to modify an existing 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 tabs appear in the content editor:
General

Creating and modifying maintenance windows
These tabs correspond to panels in the New ACL Policy wizard. Use these tabs
to modify the ACL policy.
properties, permissions, or audit trail information that apply to this ACL policy.
For more information, see Properties, Permissions, and Audit Trail tab group
on page 98.
Creating and modifying maintenance windows

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 every Friday where a set of servers
would be available for software deploy jobs.
Use this procedure to create or modify a maintenance windows 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.
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.
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.

Creating automation principals
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 Click OK to close the window.
5 Click OK to finish creating the policy.
ACL Policies will be able to contain any 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.
Creating automation principals

Use this procedure to create an automation principal, which defines a user credential
that can be used for accessing external systems. You can use automation principals
for Windows user mapping, a process that maps an RBAC role to a local or domain
user on a managed server. You can also use automation principals for accessing
Active Directory servers.
If you are creating an automation principal for Windows user mapping, you should
complete this procedure. Then you can map roles to the automation principal, which
is described in Agent ACL on page 175. Rather than mapping automation
principals to roles, you can accomplish the same mapping on a server-by-server basis
using server properties. For information on that procedure, see Using server
properties to map automation principals on page 172.
NOTE
Only Windows servers running BMC BladeLogic 8.0 or later can recognize automation
principals.

General
1 If you are creating an automation principal for Windows user mapping, additional
configuration of your Application Server environment may be necessary. For a
detailed description of that configuration, see Setting up Network Shell Proxy
Services for Windows user mapping in the BMC BladeLogic Server Automation
Administration Guide. If you are creating an automation principal for other
purposes, skip this step.
2 In the RBAC Manager folder, select Automation Principals.
3 Create a new automation principal by right-clicking and selecting

New => Automation Principal from the pop-up menu. The Automation Principal
Creation wizard displays.
4 Provide information for different aspects of the automation principal, as described

in the following sections:
General
Properties
Permissions
General
The General panel lets you provide user credential information for the automation
principal you are defining.
1 For Name, enter the name you want to assign to the automation principal. For
2 For 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. To
access this setting, use the Control Panel and go to Administrative Tools\Local Security
Policy\Local Policies\User Rights Assignment.
3 For Domain, enter the name of the domain that the user being impersonated would
use for logging into Windows.
The domain is optional. If the login account is local to the managed server, do not
enter a domain.

Properties
4 For Passphrase, enter the passphrase needed to authenticate the automation

principal. Then enter the passphrase again for Confirm.
Properties
The Properties panel shows a list of properties automatically assigned to an
automation principal, as determined by the AutomationPrincipal property class in
the Property Dictionary (see Using the Property Dictionary on page 118). You can
modify the value of any properties in this list that are defined as editable. For more
information on assigning property values, see Setting values for system object
Permissions
The Permissions panel is an access control list granting roles access to this automation
principal. Access to all system objects in BMC BladeLogic, including the sharing of
system objects between roles, is controlled through ACLs. For more information on
defining an ACL, see Defining permissions for a system object on page 186.
Modifying automation principals

Use this procedure to modify an existing 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 on these options, see General on page 170.)
properties, permissions, or audit trail information that apply to this automation
principal. For more information, see Properties, Permissions, and Audit Trail

Using server properties to map automation principals
Using server properties to map automation principals

Typically, after you define an automation principal, 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.
However, you can 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.
1 Create an automation principal.
For details on this procedure, see Creating automation principals on page 169. If
your system is set up to use BMC BladeLogics default set of 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 BladeLogics default set of permissions, you
must be logged on as BLAdmin to perform this step. For more information on
creating properties, see Adding or modifying properties on page 125. For more
general information on the Property Dictionary, see Chapter 5, Properties.
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 opens. (To select multiple servers, you must display them using the Table
View option.) Set the value of the property to the name of the automation principal
you created in the first step.
For more information on setting property values, see Changing property values
for one or more system objects on page 141.
4 Associate a role with an automation principal by mapping the role to the server
property you defined in step 2. Use the Agent ACL tab of the role definition to
perform this mapping.
For more information on mapping roles to properties, see Agent ACL on

page 175. If your system is set up to use BMC BladeLogics default set of
permissions, you must be logged on as RBACAdmin to perform this step.

Creating roles
Creating roles
A role defines a set of authorizations and other information that reflects the
capabilities of an organizational entity. For example, you can create a role for QA
testers, web administrators, or application developers. Each of these roles has a
different set of permissions. When users are assigned to a role, they are granted the
permissions defined for that role. Users can be assigned to multiple roles, but a user
can only assume one role at a time.
Roles let you tailor permissions to the tasks a group usually performs. Even though a
user may function in one context where he or she needs a full set of permissions, in
other contexts that same user may not need such sweeping privileges. In such a
situation, the user can easily switch roles, so he or she always operates with the
appropriate level of authorization.
When defining authorizations for a role, you specify authorizations that apply
throughout BMC BladeLogic 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 on the interactions between
authorizations, see Understanding authorizations on page 145.)
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 on ACL templates, see Creating an
ACL template on page 161.
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 on pushing ACLs, see Using agent ACLs on page 192.
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 179 for information on modifying an existing 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 displays.
3 Provide information for different aspects of the role, as described in the following
sections:

General
General
Agent ACL
Users
Properties
Permissions
Summary
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
Appendix A, System authorizations..
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 on creating authorization profiles, see Creating an authorization
profile on page 159.
1 For Name, enter the name you want to assign to the role. For Description, you can
2 For 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 on defining an
ACL template, see Creating an ACL template on page 161.

Agent ACL
3 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.
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 BladeLogic
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 on the users file, see the
BMC BladeLogic Server Automation Administration Guide.
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. Once 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 on
pushing ACLs, see Using agent ACLs on page 192.

Agent ACL
Optionally, do any of the following:
Field or Option Description

User must exist Check to instruct a server to allow a connection from a user only when an account
on agent with 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 the BMC BladeLogic Server
Map to user Check to force a user connecting to a server to have the same permissions as a user
name with 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.

Agent ACL
Field or Option Description

Platform Define permissions that vary by platform. Click the UNIX tab and enter the following
Related values as they apply to UNIX-style 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-style 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-style 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 on page 172.
See the BMC BladeLogic Server Automation Administration Guide for more details on user
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-style 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-style 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 on automation principals, see Create
automation principals on page 149. The Automation Principal option is only
available on the WINDOWS tab.

Users
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.
1 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.
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.
Properties
The Properties panel shows a list of properties automatically assigned to a role, as
determined by the Role property class in the Property Dictionary (see Using the
Property Dictionary on page 118). You can modify the value of any properties in this
list that are defined as editable. For more information on assigning property values,
Permissions
The Permissions panel is an access control list granting roles access to this system
object (in this case, a role). Access to all system objects in BMC BladeLogic, including
the sharing of system objects between roles, is controlled through ACLs. For more
information on defining an ACL, see Defining permissions for a system object on
page 186.

Modifying Roles
Modifying Roles
Use this procedure to modify an existing 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 tabs appear in the content editor:
General
Agent ACL
Users
Summary
These tabs correspond to panels in the New Role wizard. Use them to modify
the role definition.
properties, permissions, or audit trail information that apply to this role. For
more information, see Properties, Permissions, and Audit Trail tab group on
page 98.
Creating users
Creating a user in RBAC sets up a user account so individuals can access BMC
BladeLogic. 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 BladeLogic forces the user to select a
role when logging in. 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 on pushing ACLs, see
Using agent ACLs on page 192.

General information
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 183 for information on modifying an existing user.
BMC BladeLogic also lets you create users by running a set of BLCLI commands that
synchronizes the contents of your RBAC user database with Active Directory. For
more information, see Synchronizing users with Active Directory on page 184.
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 displays.
3 Provide information for different aspects of the user, as described in the following
sections:
General information
Role selection
Properties
Permissions
General information
The General Information panel lets you identify and disable users, 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 (BMC
BladeLogics default approach to authentication).
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, BMC BladeLogic uses standard URL encoding for the
following special characters.
Character Encoding
% %25
, %2c
: %3a
# %23
space %20
tab %09

General information
1 For Name, enter the name you want to assign to the user. For Description, you can
2 To disable a user, check User is disabled.
A disabled user cannot access the BMC BladeLogic 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.
3 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 Active Directory
on page 184. If a user is created using the New User wizard, this option is
automatically cleared.
4 Check any of the following that are applicable for this user:
Allow Secure Remote Password AuthenticationEnables the user to authenticate

using SRP. If you check this option you must proceed to step 5 to provide
security information needed for each user.
Allow Active Directory/Kerberos AuthenticationEnables the user to authenticate

using AD/Kerberos or Domain Authentication.
Allow LDAP AuthenticationEnables the user to authenticate using LDAP.
Allow SecurID AuthenticationEnables the user to authenticate using RSA

SecurID.
Allow PKI AuthenticationEnables the user to authenticate using public key

infrastructure.
For a complete description of how to set up authentication using AD/Kerberos,

LDAP, SecurID, or PKI, see the BMC BladeLogic Server Automation Administration
Guide.
5 If a user authenticates with SRP, define security settings for the users login by
doing the following:
A Under SRP Authentication Options, for Password, enter the users password.
Then, confirm the password by entering it again in Retype Password.
B 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.

Role selection
This option is enabled if the Password never expires option is cleared and the
interval of time when the password expires is greater than 0. To specify that
interval, use the Application Server Administration console (that is, the
blasadmin utility) to set a value for the MaxPasswordAge option. For more
information on this procedure, see the BMC BladeLogic Server Automation
Administration Guide.
C 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.
D To unlock a user whose login is locked out, clear User is locked out.
Users are locked out when their login attempts repeatedly fail and the number
of failed attempts exceeds a certain threshold. To specify that threshold, use the
Application Server Administration console (that is, the blasadmin utility) to set
a value for the AccountLockoutThreshold option. For more information on this
procedure, see the BMC BladeLogic Server Automation Administration Guide.
None of the SRP authentication options are applicable if users are using another
authentication mechanism to access BMC BladeLogic.
Role selection
The Role Selection panel lets you assign one or more roles to a user. It 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.
1 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.
2 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 Using agent ACLs on page 192.

Properties
Properties
The Properties panel shows a list of properties automatically assigned to a user, as
determined by the User property class in the Property Dictionary (see Using the
Property Dictionary on page 118). You can modify the value of any properties in this
list that are defined as editable. For more information on assigning property values,
Permissions
object (in this case, a user). Access to all system objects in BMC BladeLogic, including
the sharing of system objects between roles, is controlled through ACLs. For more
page 186.
Modifying users
Use this procedure to modify an existing user.
1 Open the RBAC Manager folder, expand the Users node, and navigate to an existing
user.
To modify an existing user, right-click the user and select Open from the pop-up
menu. The following tabs appear in the content editor:
General information
Role selection
These tabs correspond to panels in the New User wizard. Use them to modify
the user definition.
properties, permissions, or audit trail information that apply to this user. For
page 98.

Synchronizing users with Active Directory

Most large organizations rely on external systems such as Active Directory for
managing user accounts. BMC BladeLogic provides a set of BLCLI commands that
can synchronize users maintained in Active Directory with users maintained in the
RBAC database.
To run these BLCLI commands, some preparation is needed. This section provides an
overview of the process needed to synchronize RBAC users with Active Directory.
See the BLCLI Help for details about all BLCLI commands that this procedure
references.
This procedure is typically performed by the RBACAdmins user. If you want to

perform this procedure using a role with a minimal set of authorizations, see
Minimum authorizations for synchronizing users on page 185.
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 General information on
page 180.
1 In a file form, obtain the certificate of the Active Directory server or the CA
certificate that can be used to verify the authenticity of the Active Directory
servers certificate.
The certificate is necessary when you create an LDAP connection in step 3.
You can use the blcred utility to obtain the certificate from the Active Directory
server by running the following command:
blcred -x certStore.pem cert -add -host ActiveDirectoryServer:389 -protocol ldap
2 Create an automation principal that represents the credentials required to access

the Active Directory server.
For more information on creating an automation principal, see Creating

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

Rather than use the BMC BladeLogic console, you can create an automation
principal using the BLCLI command Impersonation:createAutomationPrincipal.
3 Create an LDAP connection and assign it the appropriate permissions by running

the following BLCLI commands:
Ldap:createConnectionCreates a connection.
Ldap:addPermissionAssigns the appropriate permissions to roles so they can

view this connection.
To view the permissions of an existing connection, you can use

Ldap:showPermissions.
4 Synchronize the RBAC user database with Active Directory by running the
following command:
RBACRole:syncUsers
Minimum authorizations for synchronizing users

Synchronizing RBAC with Active Directory is typically performed by the
RBACAdmins role. If you want to perform this procedure with a minimum set of
authorizations, you must set up a role with the permissions described below. For the
objects you are acting on, you must define authorizations as described below.
Role-level authorizations
Role.read
Role.modify
Role.Manageusers
User.*
AutomationPrincipal.read
LdapConnection.read
Object-level authorizations
Type of object Authorization required Comments

LDAP connection object LdapConnection.read Required for Active Directory
synchronization.
Currently, you can only manage
LDAP connection objects using the
BLCLI.
Automation Principal AutomationPrincipal.read Required for Active Directory
synchronization.

Using object-based permissions
Type of object Authorization required Comments

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.
Using object-based permissions

BMC BladeLogic gives you great 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 as the need arises (see Defining permissions for a system
object on page 186). You can also modify permissions for multiple system objects
(described in Updating permissions for one or more system objects on page 190).
Using object-based permissions, you can delegate authority for managing different
objects within BMC BladeLogic. 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 no different than

assigning permissions to any other system object. 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.
Defining permissions for system objects is not always straightforward. See Avoiding
common mistakes while using permissions on page 191 for information on common
problems 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 on object permissions templates, see Creating roles on
page 173.

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 BladeLogic. 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 BladeLogic.
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. In a situation like this, the Developer
role might have a permission such as DeployJob.*. When the Developer role
completes work on the Deploy Job and promotes it to QA, the Developer role no
longer needs the same level of permissions. From then on, it only needs
DeployJob.Read. During testing of the job, the QA role only needs DeployJob.Read
and DeployJob.Execute permissions. These varying permission levels can all be
captured in an ACL template or policy, making it easy to reset permissions for an
object when it is promoted between roles.
When you select a system object, the Permissions view lists the current permissions
for that object. You encounter a similar list when using a wizard to create most types
of system objects. The following procedure can be used in either context. This
procedure is referenced by many other procedures that describe how to create or
modify system objects.
1 Display a list of permissions for a system object by doing any of the following:
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 objectType.CreateACL
the Permissions panel of the wizard. Example: DeployJob.CreateACL

Action Minimum permission required

Select a system object, right-click, and select objectType.ModifyACL
Update 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:
Action Procedure
To add a set of 1. Click Add to open a dialog for defining permissions.
authorizations for a role
2. From Role, select a role to which you want to grant
permissions.
3. Under Available Permissions, 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.
Click the right arrow to move your selections to the

Selected Authorizations list.
4. Click OK.

Action Procedure
To use an ACL template to 1. If you are using the Permissions view to perform this
add a predefined set of procedure, make sure the Access Control List tab is
permissions to one or selected. It should be selected by default. If you are using
more roles a wizard to perform this procedure, skip this step.
2. Click ACL template to open a dialog for specifying

ACL templates.
3. Select one or more ACL templates on the dialog.
4. If you want the contents of the selected ACL templates to

replace all entries in the access control list, check Replace
ACL with Selected Templates.
If you do not check this option, the contents of the

selected ACL templates are appended to any existing
entries in the access control list. Replacing the current set
of permissions with the contents of an ACL template is
particularly useful when promoting a system object
between roles.
5. Click OK.
To apply ACL policies 1. If you are using the Permissions view to perform this
(sets of permissions that procedure, click the ACL Policy tab. If you are using a
are centrally managed) wizard to perform this procedure, skip this step.
2. Click ACL Policy to open a dialog for selecting ACL

policies.
3. Select one or more ACL policies on the dialog.
4. If you want the contents of the selected ACL policies to

replace all entries in the access control list, check Replace
ACL with selected policies.
If you do not check this option, the contents of the

selected ACL policies are appended to any existing
entries in the access control list. Replacing the current set
of permissions with the contents of an ACL template is
particularly useful when promoting a system object
between roles.
5. Click OK.
To delete an entry in the 1. Click Delete
Access Control List
To delete an ACL policy 1. Do one of the following:
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
Updating permissions for one or more system objects

Use this procedure to 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. With this procedure you can replace the current access control
list for the selected system objects, or you can append new entries to an existing
access control list for those 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 BladeLogic. 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.
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 sub-classes.
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 186.
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.

Avoiding common mistakes while using permissions
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.
Avoiding common mistakes while using permissions

BMC BladeLogics system of object-based permissions gives you great flexibility
when defining access. However, there are subtle dependencies between some
permissions. The following are common problems 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 BladeLogic. 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).

Using agent ACLs
Browsing a server is controlled by the Server.Browse authorization. Browsing a

component is controlled by the Component.Browse authorization.
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 on the multiple levels of authorization needed to perform
actions in BMC BladeLogic, see Understanding authorizations on page 145.
Using agent ACLs

When you define permissions for a server, you are controlling access to the server
within the BMC BladeLogic system. The BMC BladeLogic 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.
There are many ways to control access using agent configuration files. (For an
extended discussion of this subject, see the BMC BladeLogic Server Automation
Administration Guide. If you are using Windows user mapping, see Windows user
mapping and agent ACLs on page 194.) Typically, you control agent access by
letting BMC BladeLogic automatically translate the permissions you have defined for
a server in the BMC BladeLogic 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 195).
Once you have pushed ACLs, the users file settings control all incoming connections
to that agent.
When BMC BladeLogic generates entries for a users file, it creates an entry for each
user associated with each role that has access to the server. BMC BladeLogic 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.

Using agent ACLs
# DBAdmins ACLs
entries for
DBAdmins:george rw,map=root
DBAdmins role
DBAdmins:betty rw,map=root
# NSH-only ACLs
george rw,map=root
entries for default
Network Shell role betty rw,map=root
nouser
In addition to generating role:user entries, BMC BladeLogic 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 Role selection on page 182). Using this
information, BMC BladeLogic 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 BladeLogic 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 BladeLogic 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 BladeLogic
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
BladeLogic 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.

Windows user mapping and agent ACLs
TIP
BMC BladeLogic 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 that will be
created in the users file (see Previewing and pushing agent ACLs on page 194).
When you define permissions for a server, you can also preview agent ACLs (see
Adding a server on page 221).
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

Use this procedure to view the ACLs that BMC BladeLogic 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 195). For more information on
agent ACL files, see Using agent ACLs on page 192.
After you have previewed 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.
1 In the Servers folder, select a server.
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.

Creating ACL Push Jobs
To push ACLs to the selected server without running an ACL Push Job, click
Push. A dialog asks you to confirm. Click OK. A progress bar shows the progress
of the ACL push. Then a dialog 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 on
using this wizard, see Creating ACL Push Jobs on page 195.
To close the window, click Cancel.
Creating ACL Push Jobs

Use this procedure to 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 on the contents of an agent ACL, see Using agent ACLs
on page 192.
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 194.
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.

General
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 203 for information on 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 157). Then, add an authorization for the dummy command to the definition of a role. Do
not add any other command authorizations to the role. Finally, run an ACL Push Job, which
pushes the authorization for the dummy command to the agents you specify in the job. On
those agents, the role is only authorized to perform the dummy command and no other
Network Shell and nexec commands.
Open the Server folder and select a server. Right-click and select Administration
Task => Agent ACLs from the pop-up menu. A dialog 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 on this process, see Previewing and pushing agent ACLs on
page 194.
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:
General
Targets
Schedules
Properties
Permissions
General
The General panel lets you provide information that identifies an ACL Push Job.

Targets
1 For Name, enter an identifying name for the ACL Push Job. For Description, you
can optionally provide descriptive text.
2 For Save in, identify the Job folder where you want to store this ACL Push Job by
clicking Browse . The Select Folder dialog opens. Use it to select a folder and
click OK.
3 Under Number of Targets to Process in Parallel, do one of the following:
Select Unlimited to run the job on as many targets as possible simultaneously.
Application Server settings control how many targets the job can potentially
access simultaneously. See the BMC BladeLogic Administration Guide for more
information on configuring Application Servers.
Select Limited and then specify a number in the field to the right. That number
sets the maximum number of targets where the job can run simultaneously.
For example, if you set the limit to 10, the job only runs on 10 targets
simultaneously. When the job completes on one target, it starts on another. If
you set the limit to 1, the job processes each target serially. Limiting the number
of targets is particularly useful when a job temporarily disrupts the functionality
of a target and you want to limit that disruption to a small fraction of your
managed servers.
4 Click Set Execution Override if this job should always execute as if your current role
and user were scheduling the job. After you click, the job definition shows the
role:user combination under which the job will execute. To clear an existing
override, click Clear Execution Override.
For more information on using these options, see Defining a job execution
override for a role and user on page 421.
Targets
The Targets panel lets you choose the servers or server groups to which you want to
push ACLs.
1 From Available Servers, specify the operating system of the servers you want to
select. To display servers running any operating system, select All.
2 Select servers from a tree or sortable list by doing one of the following:

Default Notifications
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 table view. Sort servers in ascending or descending order by
clicking on any column header. Click one or more servers.
If you select a server group, the job runs against the servers assigned to that group
at the time of execution. The servers assigned to smart groups can change
dynamically based on their server properties. You can modify static server groups
manually by adding or removing servers.
3 Click the right arrow to move your selections to the right panel.
The Default Notifications panel lets you define default email messages and SNMP
traps that are generated when a job completes. These 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.
occurrence.
BMC BladeLogic provides a MIB that describes the Configuration Manager SNMP
trap structure. You can use it to create scripts that integrate BMC BladeLogic traps
into your own trap collection system. The MIB can be found at
<BladeLogic_install_dir>/Share/BladeLogic.mib.

Schedules
1 To send email notifications, under Job Run Notifications, do the following:
A Check Send email to and enter the email address of the accounts that should be
notified when the job completes with a status that you specify in the next step.
sysadmin@blade.com;sysmgr@blade.com.
B For When status is, check the statuses that determine whether an email should be
generated. You can select a status indicating the job succeeded, failed, aborted,
or any combination of those statuses.
2 To send SNMP trap notifications, under Job Run Notifications, do the following:
A Check Send SNMP trap to and enter the name or IP address of the server that
should be notified when the job completes with a status that you specify.
Alternatively, you can click the browse button and use the Select Server dialog
to choose a server.
B For When Status Is, check the statuses that determine whether an SNMP trap
should be generated. You can select a status indicating the job succeeded, failed,
aborted, or any combination of those statuses.
3 Check List failed servers in email notification to configure email notifications so that
they list all servers where the job has failed.
Schedules
The Schedules panel lets you accomplish all of the following:
Schedule a job to execute immediately, or at a specific time in the future.
Schedule a job to run on a recurring basis, using an arbitrary time interval.
Define multiple schedules, each instructing the job to run only once or run on a
recurring basis.
Define notifications that are issued when the job runs. Notifications can be issued
through email and SNMP traps.
For each scheduled job, the Schedules panel lists the jobs frequency and the time for
which it is initially scheduled. The time includes the jobs time zone relative to
Greenwich Mean Time.

Schedules
1 To instruct the job to execute immediately when you finish defining the job, check
Execute job now.
This option is not available if you are modifying an existing job.
2 Using the Schedules list, add a new schedule by clicking New Schedule or
modify an existing schedule by selecting it and clicking Edit Schedule .
To delete an existing schedule, select it in the list and click Remove Schedule .
3 Use the tabs on the scheduling window to provide the following categories of
information:
Schedule
Scheduled Job Notifications
4 When you finish modifying all tabs on the Add New Schedule window, click OK.
Schedule
The Schedule tab lets you schedule a job so it can run once or recur on an hourly,
daily, weekly, monthly, or on an arbitrary time interval.
You must choose the time zone that applies for the scheduled job run. If the job runs
on a recurring basis, the job will always execute at the time you have specified. BMC
BladeLogic 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 BladeLogic system should have their clocks synchronized.
1 Click the Schedule tab.
Select Once and do the following:
A. For On Date, enter the month, day, and year when the job should occur. Use a
yyyy/mm/dd format.
B. For At, enter the time when the job should occur. Use a 24-hour clock format
(00:00 to 23:59).

Schedules
Select Daily. For At, enter the time when the job should occur. Use a 24-hour
clock format (00:00 to 23:59).
Select Weekly and do the following:
A. If you want a job to occur on a weekly or greater schedule, enter a weekly

interval in the Every field. For example, enter 3 if the job should occur every
three weeks. For At, enter the time when the job should occur using a 24-hour
B. For On the following days, check the days of the week when the job should
occur. You can select multiple days.
Select Monthly. Then, enter the day of the month when the job should occur. For
At, enter the time when the job should occur using a 24-hour clock format (00:00
to 23:59).
Select Interval. and do the following:
A. For Start At, enter the date and time when the job should first occur. Use a 24-
hour clock format (00:00 to 23:59) for specifying the time.
B. For Repeat Every, enter the interval for subsequent occurrences.
3 From Time Zone, select the time zone in which the job should run.

The Scheduled Job Notifications tab lets you generate email and SNMP traps when a
scheduled job completes. Any notifications defined here override default job
notifications.
BMC BladeLogic provides a MIB that describes its SNMP trap structure. You can use
it to create scripts that integrate BMC BladeLogic traps into your own trap collection
system. The MIB can be found at installDirectory/Share/BladeLogic.mib.
1 Click the Scheduled Job Notifications tab. To send email notifications, under Job
Run Notifications, do the following:

Properties
Alternatively, you can click Browse and use the Select Server dialog to choose
a server.
Approval Information
If the BMC BladeLogic administrator has specified that this job type requires BMC
Remedy ITSM approval prior to execution, you must select the approval type and
enter the approval parameters when you configure the schedule.
Check the Execute on Approval option, and select an Approval type. Optionally, you
can select to use an existing change ticket for 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
For information on available approval types and change ticket options, see Setting
the approval type on page 423.
Properties
The Properties panel shows a list of properties automatically assigned to an ACL
Push Job. You can modify the value of any properties in this list that are defined as
editable. For more information on assigning property values, see Setting values for
system object properties on page 140.
The default list of properties assigned to an ACL Push Job is determined by the Job
built-in property class in the Property Dictionary. If necessary, you can use the
Property Dictionary to create new properties. For more information, see Using the
Property Dictionary on page 118.

Permissions
One common use for job properties is to assign time-out properties.
Permissions
The Permissions panel is an access control list granting roles access to this ACL Push
Job. Access to all objects, including the sharing of objects between roles, is controlled
through ACLs. For more information on defining an ACL, see Defining permissions
for a system object on page 186.
NOTE
If you grant ACLPushJob.Execute to a role so that the role can execute this job, you must also
grant that role ACLPushJob.Read. You cannot execute a job without being able to read the job.
Modifying ACL Push Jobs

Use this procedure to modify an existing 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 the following tabs:
General
Targets
Schedules
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. For
page 98.

Using the bladduser utility
Using the bladduser utility

BMC BladeLogics bladduser utility has two primary purposes:
Creating users without using RBAC

Creating users in bulk
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 BladeLogic system by default provides two predefined roles and users,
including the RBACAdmin and BLAdmin users. Neither of those users can log in,
however, until you have defined a password for them, which is possible with the
bladduser utility.
1 To create a user, do one of the following from the directory where an Application
Server is installed:
On Windows, enter the following:
bin\bladduser.exe
On a UNIX-style system, enter the following:
./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 on the command line. For
example, you can add a user named betty by entering the following command:
bladduser betty password


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. 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, do one of the following from the directory where an
Application Server is installed:
On Windows, enter the following:
bin\bladduser.exe -f filename
On a UNIX-style system, enter the following:
./bin/bladduser -f filename
where filename is the name of the file containing the list of users you want to import.


Chapter
7
7 Using the Servers folder
The Servers folder shows the servers to which your role has access. Before you can
perform other tasks in BMC BladeLogic, 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 populating the Servers folder, you must organize servers into a
structure that matches your needs. BMC BladeLogic allows you to perform many
actions on server groups, so a well-designed server structure can enhance
productivity. For more information on structuring server groups, see Organizing
servers on page 220.
After you create a server group structure, you can populate those groups by adding
servers to them individually and moving servers between groups. For more
information, see Adding a server on page 221 and Assigning servers to server
groups on page 226.
Many of the capabilities of BMC BladeLogic are based on properties that change from
server to server. See Properties and servers on page 208 for an explanation of how
properties are used in conjunction with servers.
There are times when you may 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 need to decommission the server, as described in
Removing a server: decommissioning on page 228.
After you have populated a server hierarchy, 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 Browsing servers on page 229.
Primarily, you manage server objects by performing jobs on them (see Chapter 10,
Managing jobs), but BMC BladeLogic also provides some capabilities for managing
individual server objects, such as the ability to start and stop Windows services. For
more information, see Managing server objects on page 232.
The Servers folder also lets you launch a script or executable program on a server. For
more information, see Executing custom commands on page 240.

Properties and servers
Properties and servers

When performing many actions in BMC BladeLogic, you can use server properties to
specify information that is likely to change from server to server. Every 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 Using the Property Dictionary on page 118). 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 140).
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 92). 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 208.
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
BladeLogic to retrieve and display new property values from the server, you need to
update the servers properties, as described in Updating server properties on
page 210.
Editable intrinsic properties for servers

The following properties are always associated with managed servers. You can edit
their values, as described in Setting values for system object properties on page 140.

Editable intrinsic properties for servers
NOTE
For properties associated with virtual environments, see the section on Setting up a virtual
environment in the BMC BladeLogic Server Automation Installation Guide.
Property Meaning
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 565.
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 564.
IS_ONLINE Indicates that the server is available for use
within the system.
IS_SOLARIS_LIVE_UPGRADE Indicates a 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 Deploying patches for Microsoft Office on
page 723.
MS_OFFICE_INSTALL_USERNAME Provides the user name that should be used to
access the installation media for Microsoft Office.
For more information, see Deploying patches
for Microsoft Office on page 723.
MS_OFFICE_INSTALL_PWD Provides the password for a user name that is
needed when installing Microsoft Office. For
more information, see Deploying patches for
Microsoft Office on page 723.
NAME Provides the name of a server and allows you to
rename servers. For more information on
renaming, see Renaming a server using its
PUSH_ACL_NO_USERS_FLAG Restricts server access to only those users listed
in the servers users file. See Using agent ACLs
on page 192.
REPEATER_MAX_CACHE_SIZE Specifies the maximum size for the cache on
repeaters where BLPackages and software is
stored until it is deployed. SeeConfiguring
servers to use repeaters during deployments on
page 675.

Updating server properties
Property Meaning
REPEATER_NAME The host name of a BMC BladeLogic repeater
used to stage a deployment to this server. This
option is only provided for compatibility with
previous releases. For information on using
repeaters, see Configuring servers to use
repeaters during deployments on page 675.
REPEATER_STAGING_DIR The repeaters staging directory. This option is
only provided for compatibility with previous
releases. For information on using repeaters, see
Configuring servers to use repeaters during
deployments on page 675.
REPEATER_STAGING_DIR The repeaters staging directory. This option is
only provided for compatibility with previous
releases. For information on using repeaters, see
deployments.
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 564.

When you first add a server, BMC BladeLogic 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. If you want the
system to retrieve and display new property values from the server, you need to
update the servers properties.
There are two ways to do this:
Updating a single servers properties, as described in Updating a single 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 212.
If you are using servers in a virtual environment (such as vCenter or IBM frames),
you must define values for certain properties that allow communication with the
servers virtual infrastructure. For more information, see the section on Setting up a
virtual environment in the BMC BladeLogic Server Automation Installation Guide.
Updating a single servers properties

Use this procedure to update intrinsic properties for a single server.
1 Open the Servers folder.
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 displays.
4 Click Verify .
BMC BladeLogic 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.
Configuring 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 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

Creating Update Server Properties Jobs
For more details on these properties, see the section on Setting up a virtual environment
in the BMC BladeLogic Server Automation Installation Guide.
Renaming a server using its properties

Use this procedure to change the name of a server. Performing this procedure
changes the name of the server in the BMC BladeLogic database.
NOTE
There are many caveats you should understand before performing this procedure. Please refer
to the release notes for a full discussion of issues relating to server renaming.
WARNING
BMC BladeLogic 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 BladeLogic 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 on this command.
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 212.
5 In the Servers folder, refresh the folder holding the renamed server.
Creating Update Server Properties Jobs

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
BladeLogic 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.

General
For information on modifying an existing Update Server Properties Job, See

Modifying Update Server Properties Jobs on page 219.
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:
General
Targets
Schedules
Properties
Permissions
General
The General panel lets you provide basic information that identifies an Update Server
Properties Job.
1 For Name, enter an identifying name for the job. For Description, you can optionally
2 For Save in, specify a location in the Jobs folder where the job should be stored by
clicking Browse .
3 Under Data 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.

Targets
An Update Server Properties Job always updates the status of a target servers
RSCD agent.
managed servers.
Targets
The Targets panel lets you choose the servers whose properties you want to update.
When first defining and saving an Update Server Properties Job, you do not have to
specify target servers. You can specify target servers at a later time.

occurrence.

Schedules
to choose a server.
Schedules
recurring basis.
Execute job now.
information:

Schedules
4 Use the tabs on the Add New Schedule window to provide the following
categories of information:
Schedule
Schedule Job Notifications
The new schedule displays in a list on the Schedules panel.
Schedule
NOTE
yyyy/mm/dd format.
(00:00 to 23:59).

Schedules

to 23:59).
Schedule Job Notifications

notifications.

Permissions
a server.
1 Properties
The Properties panel shows a list of properties automatically assigned to an Update

Server Properties Job. You can modify the value of any properties in this list that are
defined as editable. For more information on assigning property values, see Setting
values for system object properties on page 140.
The default list of properties assigned to an Update Server Properties Job is

determined by the Job built-in property class in the Property Dictionary. If necessary,
you can use the Property Dictionary to create new properties. For more information,
see Using the Property Dictionary on page 118).
Permissions
The Permissions panel is an access control list granting roles access to this Update
Server Properties Job. Access to all objects in BMC BladeLogic, including the sharing
of objects between roles, is controlled through ACLs. For more information on
NOTE
If you grant UpdatePropertiesJob.Execute to a role so that the role can execute this job, you
must also grant that role UpdatePropertiesJob.Read. You cannot execute a job without being
able to read the job.
Modifying Update Server Properties Jobs

Use this procedure to modify an existing Update Server Properties Job.

Organizing servers
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 the following tabs:
General
Targets
Schedules
These tabs correspond to panels in the New Update Server Properties Job
wizard. Use them to modify the job definition.

page 98.
Organizing servers
Using the Servers folder, you can organize servers into groups. BMC BladeLogic 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:

Adding a server
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 Managing BMC BladeLogic resources
on page 84.
Adding a server
Access to servers is controlled through BMC BladeLogics system of role-based and
object-based authorizations. Typically the ability to add servers is restricted to
administrators with the highest level of user privileges. Assuming you have the
necessary privileges, there are two ways to add servers to the systems list of
available servers:
Adding servers one by one, using the BMC BladeLogic console. This is described in
Adding a server using the BMC BladeLogic console on page 222.
Adding multiple servers to a server hierarchy by specifying a text file that contains
a list of server names. This is described in Importing servers on page 223.
When you add a server to the list of available servers, it automatically appears in any
smart server groups whose criteria it matches, and it is ready for you to explicitly add
to server groups.
For information on setting up smart server groups, see Defining a smart group
on page 92.
For information on adding a server to a server group, see Assigning a server to a

server group on page 226.
When you add or import a server, you can choose to license it using the BMC
BladeLogic Licensing Portal, a utility that issues licenses without requiring additional
interaction. If you do not use the Licensing Portal, licensing a server requires you to
run a series of commands to obtain and issue the license. For more information on
that process, see the BMC BladeLogic Server Automation Installation Guide. To use
automatic licensing, the Application Server must be configured to communicate with
the Licensing Portal. For more information on that process, see the BMC BladeLogic

Adding a server using the BMC BladeLogic console
Adding a server using the BMC BladeLogic console

Use this procedure to add a server using the BMC BladeLogic console. When you add
a server, you have the option of explicitly adding it to a server group or the Servers
node (the top node in the Servers folder).
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 226).
To add a new server, your role must be granted the Server.Create authorization. For
more information on granting authorizations, see Chapter 6, Managing access.
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 In the Name/IP Address field, enter a resolvable host name or an IP address. For
4 Select Automatically License if this server should be automatically licensed using

the BMC BladeLogic Licensing Portal.
NOTE
If automatic licensing fails for any reason, the operation to add the server will also fail.
5 Click Verify . BMC BladeLogic displays the properties already associated with
this server.
6 If necessary, edit the properties associated with this server, as described in Setting
If the server is a vCenter server or IBM frame, you should define values for certain
properties that allow the Application Server to communicate with a web service
(vCenter) or HMC (IBM frame) that accesses the virtual infrastructure. For more
details on these properties, see the section on Setting up a virtual environment in the
BMC BladeLogic Server Automation Installation Guide.

Importing servers
7 Click Next to display the Permissions panel of the Add New Server wizard. Use the
Permissions panel to define permissions for this server.
The Permissions panel defines permissions for this server in the form of an access
control list (ACL). The ACL specifies the roles that have access to the server and
the types of actions those roles are authorized to perform. For more information on
8 To preview the agent ACLs that are ready to be pushed to this server, click Agent
ACLs Preview.
Selecting this option opens the Agent ACL Preview window. It displays the
current agent ACLs for the server. Agent ACLs are based on the authorizations
and other information currently defined for the roles granted access to this server.
This information is presented in the form of a users configuration file for the RSCD
agent on this server. For more information on using this window, see Previewing
and pushing agent ACLs on page 194.
For detailed information on agent ACLs, see Using agent ACLs on page 192.
9 To push agent ACLs, select Push agent ACLs.
Selecting this option launches an ACL Push Job after this server has been added to
the system. For more information on ACL Push Jobs, see Creating ACL Push
Jobs on page 195.
10 Click Finish.
The server is now 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 226.)
Importing servers
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. To create your
text file, follow the formatting instructions in Server import file format on page 225.
When you import servers, you can import them to the Servers node (the top node in
the Servers folder) or a server group.

Importing servers
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 226).
When you import servers to a server group, the system adds those servers to its
internal list of servers being managed and immediately shows those servers as being
assigned to a server group.
To import servers, your role must be granted the Server.Create authorization. For
more information on granting authorizations, see Chapter 6, Managing access.
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 Using the Import Servers wizard, navigate to the file containing the list of servers
you want to import. Select the file.
3 From File encoding, select the type of character encoding that should be used for
the exported data, such as UTF8 or UTF16.
4 Select Automatically license servers with Licensing Portal if the servers being
imported should be automatically licensed.
NOTE
If automatic licensing fails for any reason for a particular server, the operation to import
that server will also fail. Other servers included in the same operation may be successfully
imported.
5 Select Update Intrinsic Properties to instruct 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.

Importing servers
6 Click Next to display the Permissions panel of the Import Servers wizard. Use the
Permissions panel to define permissions for this server.
The Permissions panel defines permissions for the servers being imported.
Permissions are in the form of an access control list (ACL). The ACL specifies the
roles that have access to these servers and the types of actions those roles are
authorized to perform. For more information on defining an ACL, see Defining
7 Click Finish.
A progress dialog displays. It gives the name of each server being processed. When
the import is complete, a dialog displays the results of the import. It 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.
Server import file format

Create your server import text file using the following comma-separated values
(CSV) format:
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 on how to add a property to the property dictionary, see
Using the Property Dictionary on page 118.
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

Assigning servers to server groups
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"
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.
BMC BladeLogic provides several ways to organize servers in a server hierarchy:
Assigning a server to a server group (see Assigning a server to a server group on

page 226).
Moving existing servers between server groups (see Moving or copying a server
between server groups on page 227).
Assigning a server to a server group

Use this procedure to assign a server to a specific 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
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 on
page 221) or imported through a text file (see Importing servers on page 223).
You can use the Available Servers drop-down menu if you want to limit your
display to servers of a particular operating system.

Moving or copying a server between server groups
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 73). 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.
Click Filter to display the Filters dialog. 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.
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.
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.

Removing a server: decommissioning
Removing a server: decommissioning

There are times when you may want to remove one or more servers from BMC
BladeLogic:
The servers have become obsolete.
You want to repurpose servers. 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.
When you decommission a server, you can choose to deregister its license using the
BMC BladeLogic Licensing Portal, a utility that issues and degisters licenses without
requiring additional interaction. To use this utility, the Application Server must be
configured to communicate with the Licensing Portal. For more information on that
process, see the BMC BladeLogic Server Automation Administration Guide.
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 will not run on the server when you add it back into the system, even if
you keep the same host name for the machine. For information about setting up jobs, see
Chapter 10, Managing jobs..
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 Table View. A child explorer
view opens. Select the servers you want to decommission.
2 Right-click and select Administration Task => Decommission Server.
The Decommission Servers dialog displays.
3 Select Deregister licenses for decommissioned servers with Licensing Portal if licenses
should be automatically deregistered for the servers being decommissioned.
NOTE
If automatic license deregistration fails for any reason for a particular server, the operation
to decommission that server will also fail. Other servers included in the same operation
may be successfully decommissioned. If you want to decommission a server even though
deregistration has failed, clear this option and repeat the decommissioning procedure.

Browsing servers
4 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 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. For
information on the dialog and background operations, see Running operations in
the background on page 67.
Browsing servers
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 230.
NOTE
In previous releases, BMC BladeLogic 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 438.
Snapshot ResultsShows the results of all Snapshot Jobs involving the server. For
more information, see Viewing snapshot and change tracking results on
page 466.
Audit ResultsShows the results of all Audit Jobs involving the server. For more
information, see Viewing audit results on page 492.

Contents of the Live node

The contents of the Live node vary by operating system, as described in the following
table. In addition, virtual environments contain specialized Live node children,
which are described in Contents of the Live node in virtual environments on
page 593.
Operating System Server Objects

AIX Components
Configuration
Daemons
Extended Objects
File System
Hardware Information
Packages
Patches
Processes
System Info
UNIX Groups
UNIX Users
HP-UX Bundles
Components
Configuration
Daemons
Extended Objects
File System
Patches
Processes
Products
System Info
UNIX Groups
UNIX Users
Linux Components
Configuration
Daemons
Extended Objects
File System
Processes
RPMs
System Info
UNIX Groups
UNIX Users

Operating System Server Objects

Solaris Components
Configuration
Daemons
Extended Objects
File System
Packages
Patches
Processes
System Info
UNIX Groups
UNIX Users
Windows .NET Global Assemblies
Active Directory
Applications
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
applysee Limitations for Windows
security settings on page 556)
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.
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 information on creating and using components, see
Chapter 8, Components and component templates.

Managing server objects
ConfigurationLists files that present the contents of configuration files for the
operating systems BMC BladeLogic supports. To deliver this information in a
standard format, BMC BladeLogic parses the contents of those files using grammar
files. (In this respect, configuration file objects are similar to extended objects.) If
necessary, you can identify additional configuration files, as described in
Identifying configuration files on page 629.
Extended ObjectsShows custom objects that consist of information after it is

parsed by a BMC BladeLogic grammar file (see Grammar files on page 632) so it
can be presented in a standard format. Extended objects can deliver information
not included in a standard BMC BladeLogic installation, such as local user account
data or network settings. For information on creating extended objects, see
Creating extended objects on page 636.
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 detailed 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.
Managing server objects

The most common actions you perform on server objects are as follows:
BrowseUsing the hierarchical tree in the Servers folder, expand servers to

examine the server objects they contain. For more information on server objects,
see Browsing servers on page 229.
SnapshotCreate Snapshot Jobs that record the configuration of server objects.

For more information, see Chapter 11, Snapshot Jobs.
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 Chapter 12, Audit Jobs.
ComplianceCreate Compliance Jobs that determine whether one or more servers

satisfy collections of compliance rules. For more information, see Creating

Copying and pasting files and directories
DeployDeploy software and packages of server objects to other servers. For

more information, see Deploying a software package on page 525 and
Deploying a BLPackage on page 527. Before you can run a Deploy Job, you must
first bundle server objects into a BLPackage or software package (see Chapter 9,
Creating packages and other depot objects). To deploy files, you can also use a
File Deploy Job (see Chapter 13, Deploying files and directories).
The Servers folder also lets you perform the following administrative tasks while
managing server objects:

Deleting files and directories
Starting and stopping services
Viewing server objects
Using custom configuration objects

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.
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 displays 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.


From the Servers folder you can delete files and directories.
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 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.
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 prompts you to confirm the action.

From the Servers folder, you can use the following procedures to view the properties
and security information for many types of server objects:
Viewing server object properties

Viewing security information for files and registry keys
Viewing server object properties

Use this procedure to view properties for server objects.

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 displays attributes for the selected server object. The
categories of information provided on the Properties dialog differ for different
types of server object. See Viewing security information for files and registry
keys on page 235 for more about viewing security information for files.
3 Click Close to close the Properties dialog.
Viewing security information for files and registry keys

Use this procedure to 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.
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 displays. 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 displays. 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 BladeLogic 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 displays the permissions granted or denied for this
file to the selected user. Click Close to close the dialog.
3 To view audit settings, click the Auditing side tab. A dialog 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).
4 To view detailed 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 shows the permissions that
cause events to be logged to the Windows system event log. Click Close to close the
dialog.
5 Click Close to close the dialog.

BMC BladeLogic provides a set of custom configuration objects that are available on
all managed servers running the current release.
In some situations you may be able to use additional custom configuration objects. To
do so, you must use the Configuration Object Dictionary to add the custom
configuration object (see Adding a custom configuration object on page 628). Then
you must distribute implementation information for the object to any servers where
you want to use the object (see Creating a Distribute Configuration Objects Job on
page 642).

The following list shows the custom configuration objects BMC BladeLogic currently
provides in a standard agent installation. If you are using associated products, such
as Application Automation, other custom configuration objects may be installed as
part of that product.
Hardware Information (available on all platforms)

Daemons (available on UNIX platforms)
Processes (available on UNIX platforms)
UNIX Groups (available on UNIX platforms)
UNIX Users (available on UNIX platforms)
In addition to the list shown above, the following objects are included in the
Configuration Object Dictionary in a default installation of any Application Server:
Active Directory
HyperV
IBM Frame
SolarisZone
VMware
All of these objects can be distributed to servers. For more information on setting up
the Active Directory object, see Setting up an Active Directory object on page 239.
For information on setting up the other objects, see the BMC BladeLogic Server
Automation Installation Guide.
The custom configuration objects BMC BladeLogic provides allow you to obtain
information from managed servers. The UNIX objects also allow you to perform the
following standard tasks:
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. Typically, with each release of BMC
BladeLogic, the version level of the custom configuration objects that are
automatically installed is increased by 1.
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.0,
when you install an agent running 8.0, custom configuration objects that correspond
to version 8.0 are automatically installed and ready for your use on that server.
If your Application Server has been upgraded from a previous 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 7.5 and then
was upgraded to release 8.0, you should be able to see and use custom configuration
objects on servers running release 7.5 and release 8.0. However, if agents were added
to your system when they were running a previous release and those agents were
later upgraded, to see and use custom configuration objects on those servers, you
must register the objects, as described below.
To register custom configuration objects:
Run an Update Server Properties Job on the server
Manually refresh the server by selecting the server and selecting Verify from the
pop-up menu
Deployable actions for UNIX objects

When server objects are packaged and deployed, BMC BladeLogic can usually roll
back those deployments. However, the actions you can deploy for UNIX objects
cannot be undone because BMC BladeLogic 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 UNIX objects, 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
Daemon Stop
Start
Start with dependencies (for 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.
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 on running this type of job, see Creating a Distribute
Configuration Objects Job on page 642.
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 169.

Executing custom commands
3 Associate the automation principal with a role that should have access to Active
Directory information.
For more information, see Agent ACL on page 175.

Use this procedure to execute a custom command. A custom command allows you to
take 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.
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 BladeLogic 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.
For information on creating custom commands, see Administering custom

commands on page 623.
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 Administering custom commands on page 623.
2 Right-click the server group, server, file, or directory and select Run Custom
Command from the pop-up menu. The Command Selection dialog 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.

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.


Chapter
8
Components and component
8
templates
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, WebLogic, or Oracle. 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.
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.
Typically an expert user defines a component template and then uses the template to
discover components on servers. Once 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 BladeLogic recommends a standard methodology for using components (see

Process for using components on page 245). Following these recommendations
may help you implement components efficiently and achieve the greatest benefit
from them.

Process for using components
Process for using components

While the BMC BladeLogic Console offers a flexible user interface that allows
multiple approaches to a single problem, BMC BladeLogic suggests a standard
process for using components. The process consists of the following phases:
Establishing requirements (see Component requirements on page 245)

Designing components (see Component design on page 245)
Discovering components (see Component discovery on page 248)
Implementing usage of components (see Component usage implementation on
page 248)
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.

Component design
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 (see Creating a component template on
page 251). Then you refine the templates definition during an editing process (see
Editing a component template on page 260). 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.

Component design
Once 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 once a

component has been associated with a server.
Snapshot and AuditSpecifies the individual template parts that will be used in
Snapshot and Audit Jobs once 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
problem. 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.

Component discovery
Component discovery
Once 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
(see Creating Component Discovery Jobs on page 294). 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 BladeLogic 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 BladeLogic also provides a mechanism for manually associating a component

with a server (see Adding components to servers manually on page 303). This
procedure is mainly useful as a way to quickly add a single component. 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 usage implementation

After you have discovered components, you can begin to implement their use.

Component usage implementation
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 343).
If you are ensuring compliance to a policy, you typically run a Compliance Job (see
Creating Compliance Jobs on page 312) based on a component template. Then you
can view the Compliance Job results (see Viewing and using compliance results on
page 331). If you prefer, you can export the results to view them in another format
(see Exporting compliance results on page 344).
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 an 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 340).
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 303) or modifying an existing
component (see Modifying components on page 307).
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
objectyou 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.

Organizing components and component templates
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 demonstrating 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 345.
Organizing components and component

templates
BMC BladeLogic provides two folders for creating and using components:
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 (see Adding components to a component group on page 312).
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
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 Managing BMC
BladeLogic resources on page 84.

Creating a component template
Creating a component template

Use this procedure to create a component template, which, at its most basic, is the
definition of the parts that make up a component. To more fully develop the
component definition, including its signature and compliance rules, you must edit
the component (see Editing a component template on page 260). For a general
description of designing component templates, see Component design on page 245.
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.
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, as described in the following sections:
General
Parts
Properties
Permissions
A dialog asks if you want to edit the component template.
4 Click OK to begin editing the component template. To save the component

template without editing it, click No.
For a description of how to edit a component template, see Editing a component

template on page 260.
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.
1 For Name, enter an identifying name for the component template. For Description,
2 For Save in, identify the component template folder where you want to store this
component template by clicking Browse . The Select Folder dialog opens. Use it
to select a group and click OK.

Parts
If necessary, you can create a new folder during this process by clicking Create New
Folder .
3 Under Allowed Operations, check 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.
4 For Notes, you can enter additional information about the component template.
Parts
The Parts panel lets you specify the server objects that make up the component
template. 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.

Parts
If you prefer, you can create an empty component template by skipping this panel of
the wizard. Later, during the editing process, you can add parts to the component
template (see Editing a component template on page 260).
When specifying component template parts, the following procedures are possible:
Adding template parts

Updating a template part
Defining includes and excludes for a part
Specifying snapshot and audit options
Adding template parts

Use this procedure to add a part to a component template.
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
If you are planning to use component template parts as the basis for compliance rules, you
may want to consider system performance when choosing those parts. Often, you may be able
to improve performance by selecting a collection of server objects rather than many individual
server objects. For example, you can select the Applications list rather than individual
applications. Or, you can select a configuration file rather than many individual settings in
that configuration file. Every time the system processes a component template part, it must
contact an agent for information about that part. If compliance rules reference ten separate
template parts, the system must contact the agent ten times. If compliance rules reference ten
parts that are all part of the same collection, the system only contacts the agent to retrieve the
collection.
1 On the Parts list, click Add . The Add Parts window open
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.

Parts
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. (See Local configuration objects on page 293
for information on creating these objects.) 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
, which displays the New Component Template Part dialog. 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 the Select Property , as described in Inserting a
parameter on page 142. Finally, click OK. The path and server object 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 If you are adding hierarchical server objects such as directories to the parts list, and
you want those server objects to include all subfolders, select those server objects
in the 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 have selected in the Parts list.
NOTE
On target 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.

Parts

Use this procedure to update a part included in a component template.
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 the Select
Property , as described in Inserting a parameter on page 142.
3 Click OK. The path and server object you have specified appears in the Parts list.
4 If you are updating a hierarchical server object such as a directory, and you want
the server object to include all subfolders, select the server objects in the Parts list.
Then check Recurse subfolders at the bottom of the Includes/Excludes list.
server object that you have selected in the Parts list.
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 might want to exclude all log files
or backup files in a directory. You can include or exclude software objects, such as
packages or hotfixes, and 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 wild cards, as described below:
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].

Parts
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
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 lowercase 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.
When you define an include or exclude for a component template and you browse a
component based on that component template, the results are somewhat different
than when you examine a snapshot or audit based on that same component. In a
snapshot or audit, when an include or exclude definition means a folder should not
contain any server objects, the snapshot or audit does not display the folder. If you
browse a component and an include or exclude definition means a folder should not
contain any server objects, you still see the folder, but it does not contain any server
objects.
1 To include or exclude server objects from the Template Parts list, select an item in
the list and do one of the following:
Click Add New Include/Exclude . The New Include/Exclude dialog displays.

For Path, enter a path to the server object you want to include or exclude,
relative to the object you selected in the previous step. Include a leading slash
when specifying the server object. For example, enter /autoconf instead of
autoconf. If necessary, use wild cards in the path.

Parts
Click Add New Include/Exclude . The Include/Exclude Selection dialog opens.

In the list on the 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 you want to include or
exclude, relative to the object you selected in the previous step. The path can
include wildcards. The path can also include parameters, which you can type or
enter by clicking Select Property .
Click an existing include or exclude definition. Then click Modify . The Edit
Include/Exclude dialog displays. For Name, enter a path to the server object you
want to include or exclude, relative to the object you selected in the previous
step. If necessary, use a wildcard in the path.
2 Depending on what you are specifying, click Include or Exclude.
3 Click OK.
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.
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 - Snapshot or compare the owner of a file or registry key.
Auditing ACL - Snapshot or 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.

Parts
Checksum - Calculate a unique key (an MD5 checksum) based on all the data in a
file and snapshot that key or use it 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 - Snapshot or 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 - Snapshot or compare whether an object inherits access

control entries in the System Access Control List (SACL) from its parent object.
Inherit Permission ACL - Snapshot or 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 snapshot or 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.

Properties
Permission ACL - Snapshot or 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.
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.
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.
If you disable 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.
Select a part in the Parts list and check in the Snapshot or Audit column for any
attribute that should have snapshot or audit functionality enabled.
Properties
The Properties panel is a list of properties automatically assigned to this component
template object, as determined by the Component Template built-in property class in
the Property Dictionary (see Using the Property Dictionary on page 118). These
properties are typically used for sorting component templates into smart groups and
assigning characteristics to the template, such as its testing and development status.
You can also assign local properties to a component template during the template
editing process (see Editing a component template on page 260). Parameters in a
component template refer to those local properties; they cannot refer to the properties
in this list.
You can modify the value of any properties on the Properties panel that are defined
as editable. For more information on assigning values to properties in this list, see
Setting values for system object properties on page 140.

Permissions
Permissions
The Permissions panel is an access control list granting roles access to this component
template. Access to all objects, including the sharing of objects between roles, is
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 (see Validating a
component on page 308).
1 In the Component Templates folder, navigate to the component template that you
want to edit. Right-click the component template and select Open from the pop-up
menu.
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 you can edit for the component template.
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
displays 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
General
Parts
Discover
Browse
Snapshot/Audit
Compliance
Local properties
Local configuration objects
3 After editing the component template, click Save to save your changes.
General
The General tab lets you choose the types of operations that can be based on this
component template.
1 On the content editor, click the General tab.
2 To modify the operations for which this component template can be used, check
any of the following:
DiscoveryRun 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.

Parts
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.
3 For Notes, you can enter additional information about the component template.
Parts
The Parts tab lets you add and update the parts that make up a component template.
Most of the procedures you can perform on the Parts tab are essentially the same as
those you perform on the Parts panel of the Create New Component Template
wizard. These procedures are described in the following sections:
Adding template parts on page 253

Defining includes and excludes for a part on page 255
Specifying snapshot and audit options on page 257
When editing a component template, the procedure for updating a template part is
slightly different than when initially creating the component template, as described in
Updating a template part on page 262.

Use this procedure to update an existing component 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.

Parts
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 the Select Property , as described in Inserting a parameter on
page 142. 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, for inclusion of the part in signature matching when running
Component Discovery Jobs, appears in gray and cannot be controlled here. The Discover
operation is turned on when the part is included 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 will have a gray check. For example, if you can browse
one part but not browse another, the Browse operation shows a gray check. You
can check a grayed out 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 path and server object that you have specified appears in the All
Parts list. The list also shows the operations that you have 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.
server object that you have selected in the All Parts list.

Discover
Discover
The Discover tab lets you create a component signature through a Rule Editor by
defining conditions that must be satisfied for a component to be associated with a
server. All the possible conditions are derived from parts included in the component
template and properties of the target server or the component template itself.
You can define basic conditions in a signature to 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.
For example, such conditions can be used to search 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.
In addition, you can include conditional constructs within a signature, to organize

multiple conditions in an if-then-else logical sequence.
For more information, see Basic conditions on page 277 and Conditional
constructs on page 280.
The Discovery tab also lets you test whether a component template can be
successfully associated with a server by determining whether the server satisfies the
component templates signature conditions. This tab does not actually associate a
component with a server. To perform that procedure, see Creating Component
Discovery Jobs on page 294 or Adding components to servers manually on
page 303.
NOTE
When using the Discovery tab, you can define an empty signature by simply not adding any
signature conditions. If you have turned on the discover operation for this component
template (see General on page 261), all servers will satisfy this signature for the component
template.
The process of defining a signature is very similar to the process of defining a compliance rule,
and the Discovery tab is very similar to the Rule Definition tab of the Compliance Rule Editor
(see Compliance Rule Editor Rule Definition on page 275). Note, however, that loops can
be used within compliance rules but not within 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.

Discover
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 panel is divided into two areas. The lower half displays the Rule Editor, which
contains the signature, and the upper half lists the parts specified for analysis
within the signature.
NOTE
The only way to include a part in signature matching is to include that part in a condition
within the signature, through the Rule Editor.
2 Click the Edit button on the right.
To edit an existing condition within the signature, double-click (to select) the
line that you want to edit. The text within the selected line is displayed in
editable fields.
To add the first element to an empty signature, click the New Condition
button for a basic condition, or click the drop-down arrow beside this button
and select from the full range of available elements.
Basic Condition for a basic condition

If Then End, Elseif, or Else for a conditional construct or block within it
To add a new element to a signature that already contains other elements, select
the line above where you want the element to appear before using the New
Condition button.
To copy elements 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 elements 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 rule element in the following
sections:
To define a basic condition on page 277

To define a conditional construct on page 281

Discover
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 3 and 4 for all the elements that you want to include in the signature.
6 To modify the logical organization of multiple elements, you can use any of the
following additional options:
Set logical operators between elements at the ends of lineseither AND or OR.
Within one block of elements, all elements on the same level must be connected
using the same logical operator.
To rearrange the order of elements in the signature, select the relevant lines and
click either Move up selected conditions or Move down selected conditions .
Use the NOT button 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 an element, select the relevant line and click Delete .
7 To test the signature, see Testing a component signature.
8 Click Save .
Testing a component signature

Use this procedure to test whether servers satisfy the signature conditions you have
specified on the Discovery tab of the component template editor. This procedure does
not actually associate a component with any servers. To perform that procedure see
Creating Component Discovery Jobs on page 294 or Adding components to
servers manually on page 303.
1 On the Discover tab of the component template editor, click the Edit button on
the right.
2 In the Rule Editor on the Discover tab, click Test .
The Test Signature window opens.
3 In the Target Selection area on the left, click Add .
The Add Servers window opens.

Discover
4 Select one or more servers or server groups where you want to test the component
template signature, and click the right arrow to move your selections to the right
panel.
If you select server groups, all the servers in the group are moved to the right
panel.
5 Click OK to close the Add Servers window.
The servers that you selected are added to the Target Selection area. To view the
servers that you added, you may need to expand the Servers tree.
6 Click Test to test the signature on all selected servers.
Discovered components appear under the servers, each with a green success or
red failure icon beside it.
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 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
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.

Browse
9 Click Close to close the Test Signature window.
Browse
The Browse tab lets you identify the component parts that can be browsed after a
component template has been discovered on a server. By default, all component
template parts can be browsed.
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 (see Adding template
parts on page 253). If you add a part, the only operation allowed on that part is
browsing. You can modify that setting using the Parts tab (see Parts on
page 262).
4 Click OK to close the Select Parts window.
Snapshot/Audit
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 269

Specifying Snapshot/Audit options on page 269

Snapshot/Audit
Specifying parts to include in Snapshots and Audits

Use this procedure to specify the component template parts on which you can run
Snapshot and Audit Jobs.
1 On the content editor, click the Snapshot/Audit tab.
3 From the All Parts list, select the parts that should be available for snapshots and
audit.
Snapshots and Audits list, click the double-left arrow.
parts on page 253). If you add a part, it can only be used for snapshots and audits.
You can modify that setting using the Parts tab (see Parts on page 262).
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.
The following list describes user-selectable attributes for built-in server objects. This
list describes some of the more important attributes as well as attributes with names
that may not completely describe their function. There are many additional attributes
that you can select.
ACL Owner - Snapshot or compare the owner of a file or registry key.

Snapshot/Audit
Auditing ACL - Snapshot or 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
file and snapshot that key or use it to compare entire files and detect changes that
occur anywhere in a file. Computing full checksums requires significant
processing.
Contents - Snapshot or compare file content when performing an audit based on a

snapshot of file content.
Inherit Auditing ACL - Snapshot or compare whether an object inherits access

control entries in the System Access Control List (SACL) from its parent object.
Inherit Permission ACL - Snapshot or 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 snapshot or 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.
each server.

Compliance
Permission ACL - Snapshot or 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.
Version - Compare file version information for DLL, EXE, and other types of files.
If you disable audits for the entire component template using the General tab, the
Audit column does not display in the Snapshot/Audit Options section of this tab.
After clicking the Snapshot/Audit tab, select a part in the Parts list and check in the
Snapshot or Audit column for any attribute that should have snapshot or audit
functionality enabled.
Compliance
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 BladeLogic can deploy a
BLPackage to the component to correct the failure. It can also ignore the failure.

Compliance
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 BladeLogic 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:
Manually specifying parts to include in Compliance Jobs

Adding a compliance rule group
Adding or editing a compliance rule
Commenting out and uncommenting a compliance rule
Copying, cutting, and pasting a compliance rule
Manually specifying parts to include in Compliance Jobs

A list of component template parts on which you can run Compliance Jobs appears
on the Compliance tab above the list of compliance rules to be analyzed on these
parts. Any part specified through the Parts panel (during template creation) or the
Parts tab is inherited automatically for compliance and appears on the Compliance
tab, provided that the Compliance operation was included as an allowed operation at
the time that the part was specified.
To manually add other component template parts for association with Compliance
Jobs, use the following procedure.
1 On the content editor, click the Compliance tab.
3 From the All Parts list, select the parts that should be available for Compliance
Jobs.

Compliance
Compliance list, click the double-left arrow.
parts on page 253). If you add a part, it can only be used in Compliance Jobs. You
can modify that setting using the Parts tab (see Parts on page 262).
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, as described in Updating a template part on page 262.
Adding a compliance rule group

Use this procedure to add a compliance rule group. Collecting compliance rules into
groups can make it easier to re-position compliance rules.
2 If you want to add a new rule group as the child of an existing rule group, select
the existing group in the Rules on Collected parts section.
If you do not select a rule group, the new rule group is added at the top level of the
rule hierarchy.
3 Click Add New Rule Group . The Add Compliance Rule Group window opens.
4 For Name, enter an identifying name for the rule group. For Description, you can
5 For Reference Number, enter any identifier needed to synchronize this rule group
with some external system.
6 For Notes, you can enter additional information about the compliance rule group.
7 Click OK.
Adding or editing a compliance rule

Use this procedure to add a new compliance rule or edit an existing compliance rule.

Compliance
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
Compliance Rule .
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:
Compliance Rule Editor General

Compliance Rule Editor Rule Definition
Compliance Rule Editor Remediation Options
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.
Compliance Rule Editor General

The General tab lets you provide identifying information for a compliance rule.
1 For Name, enter an identifying name for the compliance rule. For Description, you
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 on commenting out compliance rules, see Commenting out
and uncommenting a compliance rule on page 290.
4 For Notes, you can enter additional information about the compliance rule.

Compliance
Compliance Rule Editor Rule Definition

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 elements:
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 312 or Viewing and using compliance results on page 331.

Compliance
To create or edit a rule
1 On the Rule Definition tab, do one of the following:
To edit an existing rule element, double-click (to select) the line that you want to
edit. The text within the selected line is displayed in editable fields.
To add a new rule element, select the line above where you want the element to
appear. Then click the New Condition button for a basic condition, or click the
drop-down arrow beside this button and select from the full range of available
elements.

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 copy elements 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 elements 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 rule element in the following
sections:

To define a loop on page 282
3 Repeat steps 1 and 2 for all the rule elements that you want to include in the rule.
4 To modify the logical organization of multiple rule elements, you can use any of
the following additional options:
Set logical operators between elements at the ends of lineseither AND or OR.
Within one block of elements, all elements on the same level must be connected
using the same logical operator.
To rearrange the order of elements in the rule, select the relevant lines and click
either Move up selected conditions or Move down selected conditions .
Use the NOT button 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 an element, select the relevant line and click Delete.

Compliance
5 To test the rule, see Testing a compliance rule on page 287.
6 Click Save .
Basic conditions
Basic conditions can be used to perform the following analyses:
Check for the presence, absence, or number of occurrences (the cardinality) of a

configuration object.
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 283. 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
button), click the Select (down arrow) button of the LHS (left-hand side) field.
2 Define the LHS operand through the displayed selection box, and then click Close.
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.

Compliance
Branch How to use

Component Properties Expand this branch to select a component property from a
hierarchical list of component properties.
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 list of server objects, and then click OK to return to the
initial selection box. Afterwards, do one of the following:
If you want to check for the presence or number

(cardinality) of the configuration object, click the string that
represents the configuration object.
If you want to analyze a property of the configuration

object, select one of the properties listed below the
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.
Loop Iterator Propertiesa 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 Loops on page 282.
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 279.
a
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??).

Compliance
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 277, 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.
[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 283.
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.

Compliance
Click the Select (down arrow) button and select a configuration object property,
a component property, or (within a loop) a loop variable property, as done in
the LHS field.
Conditional constructs
Conditional constructs organize multiple rule elements (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
elements (conditions or loops) 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 (or loops), 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 (or loop) 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

Compliance
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 button and select the If Then End option.
2 Define a pair of rule elements (conditions or loops) for the if-then block, in the
following manner:
A Select the if line.
B Click the New Condition button for a basic condition, or click the drop-down
arrow beside this button and select from the full range of available elements.

Foreach Loop, Count Loop, or Exists Loop for the loop of your choice
C In the displayed fields, define the rule element as discussed in one of the
following sections:

To define a loop on page 282
D Double-click the then line and repeat steps B and C 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 button
and select the Elseif option. Then insert a pair of rule elementsone after the
elseif line and the other after the then lineas described in step 2 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 button, and then insert one rule
element after the else line.

Compliance
Loops
Loops enable the iterative analysis of rule elements (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 button, 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, or between)
a constant value or values to which to compare, or, alternatively, a

parameterized, Integer-type configuration object property or component
property

Compliance
2 Define a condition in the loop body in the following manner:
A Select the loop line.
B Double-click the New Condition button for a basic condition, or click the
drop-down arrow beside this button and select from the full range of available
elements.

If Then End for a conditional construct
C In the displayed fields, define the rule element as discussed in one of the
following sections:

The most typical rule element 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 Date the LHS operand value falls within
Decimal the range defined by two RHS
Integer operands
contains Long Text the LHS operand contains the string
String defined by the RHS operand

Compliance

contains Long Text the LHS operand contains the case-
(case sensitive) String sensitive string defined by the RHS
operand
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 not relevant (cardinality condition) the number of occurrences of the
equal configuration object specified in the
LHS operand does not equal the
value defined by the RHS operand
count equals not relevant (cardinality condition) the number of occurrences of the
configuration object specified in the
LHS operand equals the value
defined by the RHS operand
count greater than not relevant (cardinality condition) the number of occurrences of the
LHS operand is greater than the
value defined by the RHS operand
count greater than not relevant (cardinality condition) the number of occurrences of the
or 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
LHS operand is not one of the
values defined by the RHS operand
count is one of not relevant (cardinality condition) the number of occurrences of the
LHS operand is one of the values
count less than not relevant (cardinality condition) the number of occurrences of the
LHS operand is less than the value
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 Long Text the LHS operand does not contain
String the string defined by the RHS
operand
does not contain Long Text the LHS operand does not contain
(case sensitive) String the case-sensitive string defined by
the RHS operand

Compliance

does not end with Long Text the LHS operand does not end with
operand
does not end with Long Text the LHS operand does not end with
(case sensitive) String the case-sensitive string defined by
the RHS operand
does not equal all data types the LHS operand does not equal the
string or number defined by the
RHS operand
does not equal Long Text the LHS operand does not equal the
(case sensitive) String case-sensitive string defined by the
RHS operand
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
does not match Long Text the LHS operand does not match the
String string defined by the RHS operand
does not match FilePermission ACE the LHS operand does not match the
mask mask defined by the RHS operand
does not start Long Text the LHS operand does not start with
with String the string defined by the RHS
operand
does not start Long Text the LHS operand does not start with
with (case String the case-sensitive string defined by
sensitive) the RHS operand
ends with Long Text the LHS operand ends with the
ends with Long Text the LHS operand ends with the case-
operand
equals all data types the LHS operand equals the string
or number defined by the RHS
operand
equals (case Long Text the LHS operand equals the case-
sensitive) String sensitive string defined by the RHS
operand
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)

Compliance

greater than Decimal the LHS operand value is greater
Integer than the value defined by the RHS
operand
greater than or Decimal the LHS operand value is greater
equal to Integer than or equal to the value defined
by the RHS operand
has ACE FileAudit ACE the LHS operand has an ACE mask
matching mask FilePermission ACE matching the one defined by the
RegistryAudit ACE RHS operand
RegistryPermission ACE
has all flags UNIX Permission the LHS operand does not have a
flag matching the UNIX permission
has any flag UNIX Permission the LHS operand has any flag
matching the UNIX permission
has flag UNIX Permission the LHS operand have a flag
has no ACE FileAudit ACE the LHS operand has no ACE mask
matching mask FilePermission ACE matching the one defined by the
RegistryAudit ACE RHS operand
has no flags UNIX Permission the LHS operand has no flags
has only ACEs FileAudit ACE the LHS operand has only ACE
matching masks FilePermission ACE masks matching the ones defined by
RegistryAudit ACE the RHS operand
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 defined by the RHS operand
is not substring of Long Text the LHS operand is not a substring
String of the string defined by the RHS
operand
is not substring of Long Text the LHS operand is not a case
(case sensitive) String sensitive substring of the string
is one of all data types the LHS operand is one of the items
is substring of Long Text the LHS operand is a substring of
operand

Compliance

is substring of Long Text the LHS operand is a case sensitive
(case sensitive) String substring of the string defined by
the RHS operand
less than Decimal the LHS operand value is less than
Integer the value defined by the RHS
operand
less than or equal Decimal the LHS operand value is less than
to Integer or equal to the value defined by the
RHS operand
matches Long Text the LHS operand matches the string
String defined by the RHS operand
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 Long Text the LHS operand starts with the
starts with Long Text the LHS operand starts with the case
operand
Testing a compliance rule

Use this procedure to 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 312 or Viewing and using compliance results
on page 331.
1 On the Rule Definition tab in the Compliance Rule Editor, click Test .
The Test Rule window opens.
2 In the Target Selection area on the left, click Add .
The Add Components window opens.

Compliance
3 Select the components where you want to test the compliance rule, and click the
right arrow to move your selections to the right panel.
4 Click OK to close the Add Components window.
The components that you selected are added to the Target Selection area under
their respective servers.
5 Click Test to test the rule on all selected components.
6 Expand the Servers branch to view test results.
A green success or red failure icon appears beside each component.
7 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 rule elements (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 bottom pane displays
compliance details on the target component for a selected condition.
8 In the top pane, select a basic condition within the rule.
(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 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.

Compliance
9 Click Close to close the Test Rule window.
Compliance Rule Editor Remediation Options

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. The Remediation
Options panel lets you specify the actions to take for a compliance rule. 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 problem.
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 345.
1 Under Specify Remediation Action, 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. If you select this option, proceed to
the next step.
2 When remediating a compliance rule, do the following:
A For Package, click Browse to navigate to the BLPackage 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 on
page 261).

Compliance
3 If the BLPackage 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

Use this procedure to 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 BladeLogic 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 has been commented out, nor does the rule appear in any Compliance Job
results.
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

Use this procedure to copy and paste or cut and paste a compliance rule. This allows
you to copy or move a compliance rule within a component template or between
component templates. Because compliance rules can be very complex, you can often
save time by copying and pasting or cutting and pasting an existing rule.
When you paste a rule, BMC BladeLogic checks its validity, confirming whether the
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 is
displayed but is flagged as invalid with a red circle.
2 Navigate to the compliance rule or rules you want to copy and paste or cut and
paste.

Local properties
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, you can paste at the top level of the rule group hierarchy (that is,
outside of any rule group) by right-clicking in some empty area of the Rules on
Collected Parts panel and selecting Paste.
Local properties
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

Adding or modifying instances of a local property set
Adding or modifying local properties

Use this procedure to add a local property to a component template or to modify an
existing local property.

Local properties
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.
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. For more information about adding a property, see
Adding or modifying properties on page 125. For more information about
modifying a property value, see Setting values for system object properties on
page 140.
Adding or modifying instances of a local property set

Use this procedure to add a local property set to a component template or to modify
values of local properties in an existing 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 opens.
3 For Name, enter the name of the instance. For Description, you can optionally
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.
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 . For more information, see Inserting a parameter on page 142.
6 Click OK.

When editing a component template, you can create a local configuration object,
which is a configuration file, or extended object that only applies to this 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 345.
1 On the content editor, click the Local Configuration Objects tab.
2 Use the icons on the tab to add, copy, or delete local configuration files or extended
objects.
The procedures for creating or modifying a local configuration object are almost
identical to the procedures for creating standard configuration objects in the
Configuration Object Dictionary. For those procedures, see Using the
Configuration Object Dictionary on page 627.

Creating Component Discovery Jobs
Creating Component Discovery Jobs

Use this procedure to run a Component Discovery Job, which associates one or more
components with a server.
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 on
page 271) and then run a Compliance Job (see Creating Compliance Jobs on
page 312).
Once you have discovered 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.
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 will create 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.
See Modifying Component Discovery Jobs on page 302 for information on

modifying an existing 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.

General
The New Component Discovery Job wizard opens.
2 Define the Component Discovery Job, as described in the following sections:
General
Component Templates
Targets
Schedules
Properties
Permissions
General
The General panel lets you provide information that identifies a Component
Discovery Job.
1 For Name, enter an identifying name for the Component Discovery Job. For
2 For Save in, identify the Job folder where you want to store this Component
Discovery Job by clicking Browse . The Select Folder dialog opens. Use it to select
a folder and click OK.
managed servers.

Component Templates
Component Templates
The Component Templates panel lets you select the component templates that you
want to discover.
For each component template you select, you can specify a local 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 296.
1 In the Available Templates list, select the component templates you want to
discover.
If you opened the Component Discovery Job wizard by right-clicking a template,

that template already appears in the Selected Templates list.
2 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.
If you select a component template group or smart component template group, the
Component Discovery Job runs against all component templates in that group.
3 Under Evaluate All Instances of Selected Property, check a local property that refers
to a custom property class that you want to use when evaluating target servers.
You can only select one local property at a time.
For a complete description of this capability, see Basing discovery on a shared set
of custom property values on page 296.
Basing discovery on a shared set of custom property values

If you want to create multiple instances of one or more component templates, you
may want to 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

Component Templates
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 you want
to discover.
The Evaluate All Instances of Selected Property section of the Component Templates
panel lets you use this approach for discovering components. The following
procedure explains how to set up a custom property class and a component template
so you can use this feature.
1 Create a custom property class. Define multiple instances for the custom property
class.
For more information on creating custom property classes, see Adding a custom
property class on page 123. For more information on defining instances of a
property class, see Creating or modifying an instance of a property class on
page 129.
2 Create a component template, and then define a local property for that component
template. The local property should be a property class property that references
the custom property class you created in step 1.
For more information on creating component templates, see Creating a

component template on page 251. For more information on defining local
properties for a component template, see Local properties on page 291.
3 In the component template, 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 you set up in
step 1.
For more information on defining component template signatures, see Discover

on page 264.
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 you created in step 2.
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.

Targets
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.
Targets
The Targets panel lets you select the servers and server groups where you want
component discovery to occur.
1 In the Available Targets list, select the servers or server groups you want to
discover components.
occurrence.

Schedules
a server.
Schedules
recurring basis.
Execute job now.
information:
Schedule

Schedules
Schedule
NOTE
yyyy/mm/dd format.
(00:00 to 23:59).

to 23:59).

Schedules

notifications.
to choose a server.

Properties
Properties
The Properties panel shows a list of properties automatically assigned to a
Component Discovery Job. You can modify the value of any properties in this list that
are defined as editable. For more information on assigning property values, see
The default list of properties assigned to a Component Discovery Job is determined

by the Job built-in property class in the Property Dictionary. If necessary, you can use
the Property Dictionary to create new properties. For more information, see Using
the Property Dictionary on page 118.
Permissions
Component Discovery Job. Access to all objects, including the sharing of objects
NOTE
If you grant DiscoveryJob.Execute to a role so that the role can execute this job, you must also
grant that role DiscoveryJob.Read. You cannot execute a job without being able to read the job.
Modifying Component Discovery Jobs

Use this procedure 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. Right-click the job and select Open from
the pop-up menu. The content editor displays the following tabs:
General
Component Templates
Targets
Schedules

Adding components to servers manually
These tabs correspond to panels in the New Component Discovery Job wizard.
Use them to modify the job definition.
the properties, permissions, or audit trail information that apply to this job. For
page 98.
Adding components to servers manually

Use this procedure to add a component to a single server without running a
Component Discovery Job. This procedure is mainly 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 have been
defined for a component template. For example, suppose you have created a
component template with an INSTALL_DIR property, and you define values for this
property using multiple instances of local property sets. One instance sets the value of
INSTALL_DIR to /opt/qa while another sets it to /opt/dev. If you run a Component
Discovery job, it substitutes the /opt/qa and /opt/dev values from the two local
property set instances. However, if you want to provide a different value for one
server, you can insert that value using this procedure.
1 Open the Component Templates folder and navigate to the component template for
which you want to create a component. Right-click the component template and
select New => Component from the pop-up menu.
The New Component wizard opens.
2 Define the new component, as described in the following sections:
General
Properties
Permissions
Compliance exceptions
3 Click Finish after completing the last step of the wizard. The component you have
defined is associated with the designated server.

General
General
The General panel lets you provide information that identifies the component
template and the server where you want to create a component.
1 For Name, enter 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. For Description, you can optionally
2 For Component Template, click Browse and navigate to the component template
that forms the basis of this component.
By default, this field uses the component template you initially selected when
launching the New Component wizard.
3 For Property Set Instance, select 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 (see
Properties on page 304) to define value for individual local properties.
4 For Server, click Browse and navigate to the server where you want to create this
component.
Properties
component, as determined by the Component built-in property class in the Property
Dictionary (see Using the Property Dictionary on page 118). This list also shows
any local properties defined for this component. You can modify the value of any
properties in this list that are defined as editable. For more information on assigning
property values, see Setting values for system object properties on page 140.
Permissions
component. Access to all objects, including the sharing of objects between roles, is

The Compliance Exceptions panel lets you specify compliance rules that a component
does not have to satisfy.
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 saying 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 the Name value in that file must be either
Admins or SupportLevel2. Using a wild card in this context instructs the compliance
rule to examine all values listed within the /etc/password 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 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 Configuration Manager to ignore the path //etc/passwd//
SupportLevel1 when evaluating this compliance rule. The result is that Admins,
SupportLevel1, and SupportLevel2 are all permissible values for Name in the /etc/
passwd file for that component.
This procedure specifies that a single component is excused from certain compliance
rules. BMC BladeLogic provides a similar procedure that lets you define compliance
rule exceptions for multiple components simultaneously. For more on that procedure,
see Setting multiple components as exceptions to compliance rules on page 309.
When you define compliance rule exceptions, you group them. Each group can have
a different expiration date.
1 To add a new compliance rule exception, click Add New Exception . To edit an
existing exception, select the 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, for Name, enter an identifying name for this compliance rule
exception. For Description, you can optionally provide descriptive text.

3 For Reference Number, enter any identifier needed to synchronize this exception
4 For Duration, click Never expires unless you want the exception to last a limited
period of time. If you do, click Expires and pick the date when the exception should
expire.
5 For Notes, you can enter additional information about the compliance rule
exception.
6 Click the Associated Compliance Rules tab.
7 Click Add Compliance Rule . The Select Compliance Rules dialog opens.
8 Use the Select Compliance Rules dialog to define compliance rule exceptions by
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. The procedure is
complete.
If you want to limit this exception, specify a path to a particular system object by
clicking the Edit Ignored Paths icon. The Edit Ignored Paths dialog opens.
A. On the Edit Ignored Paths dialog, from Type, select the type of server object
that should be ignored.
B. For Path, enter the path to the server object. The path can include wild cards.
C. 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 Name property in that file must
equal Admin or SupportLevel2. If you want to create an exception that allows
Name to equal SupportLevel1, use this dialog to specify a type of
Configuration File and enter the path /etc/passwd//SupportLevel1.
D. On the Edit Ignored Paths dialog, click OK.

Modifying components
E. On the Select Compliance Rules dialog, click OK.
9 On the Add Compliance Exception dialog, click OK. The exception you have
defined is added to the Compliance Exceptions list. To add another exception,
repeat this procedure.
Modifying components
Use this procedure to modify an existing component. Typically, when you modify a
component, you change the component template and your changes are automatically
applied to all components based on that template (see Editing a component
template on page 260). 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.
1 Using the Component Templates, Components, or Servers folders, navigate to a

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 the following tabs:
General
Properties
Permissions
The tabs on the Edit Component window correspond to the panels in the New
Component wizard (used for manually creating components). Use these
procedures referenced above to modify various aspects of the component,
including any compliance exceptions.
2 Click OK to save your revisions to the component.

Validating a 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.
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 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
can now be used to display 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.
NOTE

Setting multiple components as exceptions to compliance rules
Setting multiple components as exceptions to

compliance rules
Use this procedure to excuse multiple components from compliance rules for a
component template.
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 saying 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 the Name value in that file must be either Admins or
SupportLevel2. Using a wild card in this context instructs the compliance rule to
examine all values listed within the /etc/password 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 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 Admins, SupportLevel1, and
SupportLevel2 are all permissible values for Name in the /etc/passwd file for that
component.
1 If you have not already done so, 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.

General
In the Component Templates folder, navigate to a component template that has

multiple components associated with it. In the Child Explorer view (if not
already open, choose Window => Show View => Child Explorer), 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. In the Child Explorer view (if not already open, choose
Window => Show View => Child Explorer), select multiple components. Right-
click and select Exceptions from the pop-up menu.
2 Define exceptions to compliance rules for a component template, as described in

the following sections:
General
Associated compliance rules
Components
3 Click Finish after completing the last step of the wizard. The components you have
specified are excused from the compliance rules you have specified.
General
The General panel lets you assign a name to a group of component exceptions. You
can also specify a date when the exception expires.
1 For Name, enter an identifying name for this compliance rule exception. For
2 For Reference Number, enter any identifier needed to synchronize this exception
3 For Duration, click Never expires unless you want the exception to last a limited
period of time. If you do, click Expires and pick the date when the exception should
expire.
4 For Notes, you can enter additional information about the compliance rule
exception.


The Associated Compliance Rules panel lets you specify compliance rules that the
selected components do not have to satisfy.
1 Click Add Compliance Rule . The Select Compliance Rules dialog opens.
2 Use the Select Compliance Rules dialog to define compliance rule exceptions by
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.
The procedure is complete.
If you want to limit this exception, specify a path to a particular system object by
clicking Edit Ignored Paths . The Edit Ignored Paths dialog opens.
A. On the Edit Ignored Paths dialog, from Type, select the type of server object
that should be ignored.
B. For Path, enter the path to the server object. The path can include wild cards.
C. 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 Name property in that file must
equal Admin or SupportLevel2. If you want to create an exception that allows
Name to equal SupportLevel1, use this dialog to specify a type of
Configuration File and enter the path /etc/passwd//SupportLevel1.
D. On the Edit Ignored Paths dialog, click OK.
E. On the Select Compliance Rules dialog, click OK.

Components
Components
The Components panel lets you choose the components that can be excused from the
compliance rules you selected in the previous panel.
1 In the Available Components list, select the components that should be excused
from the compliance rules you specified in the previous panel.
If you opened the component exception wizard by selecting some components,

those components already appear in the Selected Components list.
2 Click the right arrow to move selected components 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.
Adding components to a component group

Use this procedure to add components to a component group. You can add
components that have been discovered or manually created.
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
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.
Creating Compliance Jobs

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.

Creating Compliance Jobs
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 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 340).
After you run a Compliance Job, you can do any of the following:
View the results of the job. (See Viewing and using compliance results on
page 331.)
Export some or all of the results of the Compliance Job. (See Exporting
compliance results on page 344.)
See Modifying Compliance Jobs on page 330 for information on modifying an

existing Compliance Job.
1 To create a new Compliance Job, do one of the following:
New => Compliance Job from the pop-up menu.
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, as described in the following sections:
General
Component templates for filtering
Components
Auto-remediation
Default notifications
Schedules
Properties
Permissions

General
General
The General panel lets you provide information that identifies a Compliance Job and
provides some options for how the job should execute.
1 For Name, enter an identifying name for the Compliance Job. For Description, you
2 For Save in, identify the Job folder where you want to store this Compliance Job by
click OK.
For more information on using these options, see Defining a Job Execution
Override for a Role and User.
managed servers.
5 Check Continue despite compliance data collection errors if you want the job to
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.


The Component Templates for Filtering panel lets you identify component templates
that form the basis of a Compliance Job. Any components based on that template can
be included in the Compliance Job.
In the Available Templates list on the left, select the component templates you want
to base the Compliance Job on and click the right arrow to move your selections to the
Selected Templates list in the right panel.
Use Control-click or Shift-click to select multiple component templates. Use the left
arrow to remove an item from the Selected Templates list. Use the double left arrow
to remove all items from the Selected Templates list.
If you opened the Compliance Job wizard by right-clicking a component template,

that component already appears in the Selected Templates list.
Components
The Components panel lets you choose the components that should satisfy
compliance rules established for the component template. Each component is
compared to the compliance rules defined for its component template.
1 In the Available Components list, select the 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.
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.

Auto-remediation
Auto-remediation
The Auto-remediation panel lets you enable automatic remediation of any
compliance rule failures that a Compliance Job discovers. Each compliance rule
definition can specify a BLPackage that should be deployed if a component fails the
rule and remediation is required. When you enable auto-remediation, BMC
BladeLogic automatically collects and deploys the BLPackages needed to correct
compliance rule failures. You can select the component templates that should be
automatically remediated.
When you remediate a Compliance Job failure, Configuration Manager creates a

remediation package containing the BLPackages required to remediate each failed
compliance rule. When checking compliance for multiple components, Configuration
Manager 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, Configuration Manager 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, Configuration Manager 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 has failed the same set of compliance rules. If this procedure creates
multiple Deploy Jobs, Configuration Manager combines those Deploy Jobs into a
Batch Job so the entire remediation can be launched as one job.
Remediating a Compliance Job is different than 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 of and/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.

Auto-remediation
When you choose to auto-remediate Compliance Job results, the remediation jobs are
started 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 (see Manually remediating compliance results on page 340).
When BMC BladeLogic automatically creates Deploy Jobs for remediation jobs, it
applies default settings to those Deploy Jobs. BMC BladeLogic 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 on the procedure, see Setting
deploy options for remediation jobs on page 318
When BMC BladeLogic automatically creates Deploy Jobs or Batch Jobs for
remediation, it sets the AUTO_GENERATED property to True for those jobs.
Similarly, if BMC BladeLogic automatically creates BLPackages for remediation, it
sets AUTO_GENERATED to True for those BLPackages. When these objects have
AUTO_GENERATED set to True, they will be automatically deleted at a later date
according to the retention policy you have set up for automatically generated objects.
For more information on managing BMC BladeLogic data and deletion of auto-
generated objects, see the BMC BladeLogic Server Automation Administration Guide.
Auto-remediation is often used for the initial provisioning of servers. 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.
1 Check Remediate after compliance analysis completes to enable automatic

remediation of compliance rule failures.
2 For Remediation name, enter a name for the remediation job. BMC BladeLogic
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.
3 For Save package in, click Browse and navigate to the depot folder where you
want to store the BLPackages that are generated by the remediation job.
4 For Save remediation/deploy job in, click Browseand navigate to the job group
where you want to store any Deploy Jobs (and potentially a Batch Job) that this
procedure generates.
5 In the Template list, select the component templates that should be automatically
remediated. This list only displays component templates for which auto-
remediation has been enabled at the template level. For more information on that
procedure, see General on page 261.

Auto-remediation
6 Select Keep each local property name unique in remediation package if you want the
remediation package to include duplicate property names for individual
compliance rules that have failed. Although their names are the same, each
property is indexed so that all references to a particular property are retained. In
addition, the default value for each property is also retained.
If you clear this option, property names are left untouched. However, the default
value assigned to the property becomes the value of the property for the first failed
compliance rule that is merged into the remediation package.
7 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
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.
Setting deploy options for remediation jobs

Use this procedure to 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
BladeLogic automatically creates Deploy Jobs to deploy remediation packages. Those
Deploy Jobs use default settings. If you want to modify those settings, you have to
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 accomplish this, you must create an instance of the DeployOptions built-in
property class. The instance includes properties that control Deploy Job behavior. Set
the value of each property according to your needs. (See the table below for a
description of each property.) Then, when you run a Compliance Job, you must
define a property called DEPLOY_OPTIONS_INSTANCE_FOR_REMEDIATION so
that its value refers to the instance of the DeployOptions property class. After you run
the Compliance Job and you remediate components that are not in compliance, either
automatically or manually, the Deploy Jobs that are created use the settings you
defined for the instance of the DeployOptions property class.
The following table describes the DeployOptions properties that can be set to control
the behavior of automatically generated Deploy Jobs.

Auto-remediation
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.
If you do not enter any value or you enter 0, the job waits
indefinitely.
BY_PHASE_ALL_HOST_ Boolean Enter True to instruct the job to undo the Commit phase for all
MUST_PASS_COMMIT target servers if any servers do not successfully complete the
Commit phase. By default this option is set to False. This option is
only applicable when the FLOW_CONTROL option is set to
ByPhase.
COPY_LOCKED_FILES Boolean Enter True to instruct a target server to create copy on boot files
when locked files are encountered during the Commit phase of a
Deploy Job.
Entering False means the job generates an error and fails if it

encounters locked files.
Note that a Deploy Job only creates copy on boot versions of

read-only files if the OVERWRITE_READONLY_FILES option is
set to True.
DEPLOY_JOB_TYPE Enumerated Specify the Deploy Job type:
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.

Auto-remediation

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_ Boolean Enter True to instruct a server to begin the Commit phase of the
BOOT_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.

Auto-remediation

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_ Boolean Enter True if any end-of-job reboots specified in
REBOOT REBOOT_OPTIONS should be Solaris reconfiguration reboots.
IS_SIMULATE_ Boolean Enter True to enable the Simulate phase of the Deploy Job. The
ENABLED 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_INDIRECT Boolean Enter True to enable indirect staging, which means the Deploy 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_ Boolean Enter True to instruct a server to overwrite read-only files when
READONLY_FILES read-only files are encountered during the Commit phase.

Auto-remediation

PRESERVE_STAGING_ Boolean Enter True to retain data copied to a staging area on a target server
DIR_ON_FAILURE 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

jobPrevents 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.

Auto-remediation

REGISTER_COM_ Boolean Enter True to register COM objects.
COMPONENTS
When a deployment encounters a file with a file extension of DLL,
EXE, or OCX, the job determines whether the file is a COM object.
If it is and the file being copied replaces an existing COM object,
the deployment unregisters the existing object, copies in the new
object, and registers the new object. If the file being copied is a new
object, the deployment copies the file and registers it.
RESET_JOB_ON_ Boolean Setting this option to True allows a job to be run again even
FAILURE 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
USER_MODE_ Enumerated Specify user mode behavior (only applicable to UNIX-style target
OPTIONS_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.
1 Using the Property Dictionary, create an instance of the DeployOptions built-in

property class.
For more information, see Creating or modifying an instance of a property class

on page 129.
2 When defining the DeployOptions instance, define values for all properties with
an entry in the Value Source column that reads DeployOptions. These values
control the settings for a group of automatically generated Deploy Jobs. Use the
table above to understand the values that you can assign to these properties

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 Auto-remediation on page 316) or you use Compliance Job results to
manually remediate non-compliant components (see Manually remediating
compliance results on page 340), 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.
occurrence.
The Default Notifications panel also lets you define email messages and SNMP traps
that are generated based on the results of the Compliance Job. You can send
notifications when target components have compliant configurations, non-compliant
configurations, or both.

to choose a server.
4 To send email based on results of the Compliance Job, do the following:
A Under Compliance Results Notifications, check Send email to and enter the
email address of the accounts that should be notified about compliance results.
Separate addresses with a space.
B For When results are, specify the type of compliance results that should trigger
an email by checking Consistent, Inconsistent, or both.
C To include compliance results in the email, check Append compliance results to

email.
D To limit the size of the email that is generated by appending compliance results,
check Limit email body size to and then enter the maximum, in kilobytes, in the
text box to the right.
5 To generate an SNMP trap based on compliance results, check Send SNMP trap to
and then enter the name or IP address of the server that should be notified when
the job completes with a status that you specify. Alternatively, you can click
Browse and use the Select Server dialog to choose a server.
6 Specify the compliance result statuses that determine whether an SNMP trap
should be generated by checking Consistent, Inconsistent, or both.
For example, if you select Inconsistent and a Compliance Job indicates that two
components are inconsistent, an SNMP trap is sent.
When a job completes, an SNMP trap is sent to the specified server, where it can be
read using software that can receive and interpret SNMP traps.

Schedules
Schedules
recurring basis.
Execute job now.
information:
Schedule
Scheduled job notifications
Schedule

Schedules
NOTE
yyyy/mm/dd format.
(00:00 to 23:59).

to 23:59).

Schedules
Scheduled job notifications

notifications.
The Scheduled Job Notifications tab 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 consistent configurations, inconsistent
to choose a server.
4 To send email based on results of the Compliance Job, do the following:

Properties
A Under Compliance Results Notifications, check Send email to and enter the
email address of the accounts that should be notified about compliance results.
Separate addresses with a space.
B For When results are, specify the type of compliance results that should trigger
an email by checking Consistent, Inconsistent, or both.
C To include compliance results in the email, check Append compliance results to

email.
D To limit the size of the email that is generated by appending compliance results,
check Limit email body size to and then enter the maximum, in kilobytes, in the
text box to the right.
5 To generate an SNMP trap based on compliance results, check Send SNMP trap to
and then enter the name or IP address of the server that should be notified when
the job completes with a status that you specify. Alternatively, you can click
Browse and use the Select Server dialog to choose a server.
6 Specify the compliance result statuses that determine whether an SNMP trap
should be generated by checking Consistent, Inconsistent, or both.
For example, if you select Inconsistent and a Compliance Job indicates that two
components are inconsistent, an SNMP trap is sent.
read using software that can receive and interpret SNMP traps.
Properties
Compliance Job. You can modify the value of any properties in this list that are
The default list of properties assigned to a Compliance Job is determined by the Job
One property, DEPLOY_OPTIONS_INSTANCE_FOR_REMEDIATION, is used to

specify options for Deploy Jobs that are automatically created when you define a
Compliance Job to perform auto-remediation or you are manually remediating
Compliance Job results. For more information on this, see Setting deploy options for
remediation jobs on page 318.

Permissions
Permissions
Compliance Job. Access to all objects in BMC BladeLogic, including the sharing of
NOTE
Audit Jobs, Compliance Jobs, and Patch Analysis Jobs are all controlled by AuditJob
authorizations. If you grant AuditJob.Execute to a role so that the role can execute this job, you
must also grant that role AuditJob.Read. You cannot execute a job without being able to read
the job.
Modifying Compliance Jobs

Use this procedure to modify an existing Compliance Job.
To modify the definition of an existing Compliance Job, open the Jobs folder and
General
Components
Auto-remediation
Schedules
These tabs correspond to panels in the New Compliance Job wizard. Use them
to modify the job definition.
properties, permissions, or audit trail information that apply to this job. For
page 98.

Viewing and using compliance results
Viewing and using 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.
Selecting the following nodes in this tree displays detailed information for the job
run:
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.
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 332.
To view Compliance Job results, any of the following procedures are possible:
Viewing compliance results by rule

Viewing compliance results by server
Viewing the results of a compliance rule
Viewing and using auto-remediation results
To use Compliance Job results, any of the following procedures are possible:

Undoing auto-remediation
Editing a compliance rule
Defining exceptions for components
Manually remediating compliance results
Creating a remediation package
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 344).

Compliance statuses of compliance rules
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 log includes a message saying that
job results are truncated. For more on configuring the Application Server, see the BMC
Compliance statuses of compliance rules

BMC BladeLogic 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.
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.
Viewing compliance results by rule

Use this procedure to see which components satisfy the compliance rules for the
component template.
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 Compliance column in the right pane shows the compliance status for each
component.

Use this procedure to determine if components on servers satisfy compliance rules.
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 content editor provides summary information for the components on the
server or the rule groups associated with the component.
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.


Use this procedure to view how a particular component satisfies a compliance rule
for a component template.
Compliance Job, and do one of the following:
Select the Server View node, expand a server, expand a component, expand a
rule group, and then select a rule.
Select the Rules View node, expand a component template, expand a rule group,
expand a rule, and then select a component.
Two panes display on the right. The top pane displays the full rule as defined
through the Rule Editor, including all its rule elements (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 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.
(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 a Foreach loop, details are displayed in the bottom pane only for the non-compliant
configuration objects. In a Count loop, details are displayed for all relevant configuration
objects (whether compliant or not), but only if the entire loop was non-compliant.
4 If an exception has been defined for a rule, you can view that exception by doing
the following:
A Click View Exceptions. The View Associated Exceptions dialog 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 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.
E Click Close to close the View Associated Exceptions dialog.
For information about defining compliance rule exceptions, see Defining

exceptions for components on page 337.
5 If a condition includes ACL information, you can view detailed ACL information
for a target component by doing the following:
A Select an entry in the Target pane that includes ACL information and click View
Selected Exception . 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.


Use this procedure to access the Compliance Rule Editor for a particular compliance
rule while viewing the results of a Compliance Job.
Expand the Rules View node, expand a component template, and then select a
rule.
Expand the Rules View node, expand a component template, expand a rule, and
then select a component.
Expand the Server View node, expand a server, expand a component, and then
select a rule.
3 Right-click and select Edit Compliance Rule from the pop-up menu. The
Compliance Rule Editor opens, displaying information about the relevant
compliance rule.
4 Do one or both of the following:
To edit the compliance rule, click the Rule Definition tab. For more on editing
compliance rules, see Compliance Rule Editor Rule Definition on page 275.
To edit remediation options, click the Remediation Options tabs. For more on
remediation options, see Compliance Rule Editor Remediation Options on
page 289.
You can edit the compliance rule and save your changes, thus creating a new
version of the component template.


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.
The following approaches let you define exceptions for a single component or
multiple components:
Flagging one component as an exception to compliance rules on page 337

Flagging multiple components as exceptions to compliance rules on page 337
Flagging one component as an exception to compliance

rules
Use this procedure to excuse a single component from compliance rules for a
component template.
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 from the pop-up menu. The Edit
Component dialog opens, and the Compliance Exceptions tab is automatically
selected.
4 Use the Edit Component dialog to define any compliance exceptions. For more on
this procedure, see Compliance exceptions on page 305.
Flagging multiple components as exceptions to compliance

rules
Use this procedure to excuse multiple components from compliance rules for a
component template.

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 from the pop-up menu.
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
from the pop-up menu.
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 from the pop-up menu.
The Set Component Exceptions wizard displays.
3 Use the Set Component Exceptions wizard to define any compliance exceptions.
For more on this procedure, see Compliance exceptions on page 305.

Use this procedure to view auto-remediation results. BMC BladeLogic 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 (see Phases of a Deploy Job on page 522). The Log Messages tab
shows messages that were generated for the entire remediation job.
Compliance Job, and select the Remediation View node.
3 Use the Deploy Status tab to do any of the following:
Remove a server from the target servers for this job by selecting a server where
the job is incomplete, right-clicking, and selecting Remove.
Retry the job on a server by selecting a server 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 servers 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 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.
Use this procedure to undo packages that have been committed to target servers as
part of a Deploy Job that automatically remediated Compliance Job results.
When you perform this procedure on a job in an Incomplete state, the job remains in
an Incomplete state. If you perform it on a job in a Failed or Succeeded state, the job
remains in a Failed or Succeeded state.
To undo 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 from the
pop-up menu.
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 from the pop-up menu.
A confirmation dialog shows the remediation job that is being rolled back and lists
the servers where you are undoing remediation.
2 Click OK to confirm the undo. A dialog 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.
Selecting a cell under the Rollback column displays messages for the undo on that
server.


Use this procedure to 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 312).
When you remediate a Compliance Job failure, Configuration Manager creates a

remediation package containing the BLPackages required to remediate each failed
compliance rule. When checking compliance for multiple components, Configuration
Manager 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, Configuration Manager 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
After creating remediation packages, Configuration Manager 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 has failed the same set of compliance rules. If this procedure creates
multiple Deploy Jobs, Configuration Manager combines those Deploy Jobs into a
Batch Job so the entire remediation can be launched as one job.
Remediating a Compliance Job is different than 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 of and/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.

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. See Creating a
remediation package on page 342 for details on that procedure.
When you manually remediate Compliance Job failures and BMC BladeLogic
automatically creates Deploy Jobs for a remediation job, the system applies default
settings to those Deploy Jobs. BMC BladeLogic 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 on the procedure, see Setting
deploy options for remediation jobs on page 318.
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 from the pop-up menu. The Remediate Job Result
window opens.
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 on defining compliance rules, see Compliance on
page 271.
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.
want to store the BLPackage generated by this procedure.
6 For Save remediation/deploy job in, click Browse and navigate to the job group
where you want to store any Deploy Jobs (and potentially a Batch Job) that this
procedure generates.

7 Select Keep each local property name unique in remediation package if you want the
remediation package to include duplicate property names for individual
compliance rules that have failed. Although their names are the same, each
property is indexed so that all references to a particular property are retained. In
addition, the default value for each property is also retained.
If you clear this option, property names are left untouched. However, the default
value assigned to the property becomes the value of the property for the first failed
compliance rule that is merged into the remediation package.
8 Select Use servers as remediation target if you want any Deploy Jobs to target the
servers (or other devices) associated with the components that are the targets of a
Compliance Job. If you clear this option, the Deploy Jobs use the components that
are targets of the Compliance Job as the targets for the remediation job.
9 Click OK.
BMC BladeLogic examines the failed compliance rules and creates a remediation
job by doing one of the following:
If you are remediating multiple components and BMC BladeLogic has created
more than one Deploy Job to deploy multiple remediation packages, a Batch Job
displays. The Batch Job is defined to run the Deploy Jobs needed to remediate
the target components. For more information on modifying or running a Batch
Job, see Chapter 16, Creating Batch Jobs.
If you are remediating a single component or BMC BladeLogic has created one
remediation package that applies to multiple components, a Deploy Job
displays. For more information on modifying or running a Deploy Job, see
Deploying a BLPackage on page 527.

Use this procedure to 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.
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 340. 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 312).

Packaging and deploying a component
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.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
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 from the pop-up menu. The
Create Remediation Package window opens.
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 on defining compliance
rules, see Compliance on page 271.
4 For Package name, enter a name for the BLPackage created for remediation.
want to store the remediation package generated by this procedure.
6 Click OK.
BMC BladeLogic creates a remediation package for the targeted component and
stores it in the Depot.
Packaging and deploying a component

Use this procedure to 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 Application Release Manager.

Exporting compliance results
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.
For more information on the Create BLPackage wizard, see Adding a BLPackage
to the Depot on page 375.
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.
For more information, see Deploying a BLPackage on page 527.
Exporting compliance results

Use this procedure to export the results of a Compliance Job. 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
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
displays.
4 On the dialog, 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:

Using component templates to ensure compliance for multiple instances of an application
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.
6 On the Export Results dialog, click Save.
Using component templates to ensure

compliance for multiple instances of an
application
A BMC BladeLogic system offers many tools for ensuring compliance with
organizational standards for application configurations. This section 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
following directories:
D:\oracle1
D:\oracle2
The following procedure is a generalized description. Each step describes a BMC

BladeLogic procedure you can perform. Most steps include a reference to more
detailed information about that procedure.

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 on local properties and property instances, see Local properties on
page 291.
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 on local configuration files, see Local configuration objects on

page 293.
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 on component template parts, see Parts on page 262.
E Create a signature for the component template. The only requirement for the
signature is that the listener.ora file must exist.
For more on creating signatures, see Discover on page 264.
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 on Component Discovery Jobs, see Creating Component Discovery

Jobs on page 294.

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 on creating BLPackages, see Adding a BLPackage to the Depot on

page 375.
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 following path:
/d/??ORACLE_PATH??/product/10.1.0/network/ADMIN/listener.ora//**
/DESCRIPTION/ADDRESS/PORT
must exist, and
Value1 (the first entry in the configuration file) cannot equal 1521.
For more on creating compliance rules, see Compliance on page 271.
B For remediation, select the Oracle_port BLPackage, created in the step 3.
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.

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 on running Compliance Jobs, see Creating Compliance Jobs on

page 312.
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 on remediating the results of Compliance Jobs, see Manually

remediating compliance results on page 340.
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.

Chapter
9
Creating packages and other depot
9
objects
BMC BladeLogic lets you create packages and other types of objects that you can
store in the Depot. Once you have created 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-style executables. See the following for information

about creating software packages:
Overview of software packages

Adding software to the Depot
Adding a hotfix to the Depot
BLPackagesAggregations of many types of server objects. BLPackages can be

used to deploy complex server configurations. See the following for information
about creating or modifying BLPackages:
Overview of BLPackages
Adding a BLPackage to the Depot
Editing a BLPackage
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 404.
FilesFiles that can be stored as depot objects and then added to BLPackages. See
Adding files to the Depot on page 409.
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 Creating the Virtual Guest Package on page 604.

Organizing depot content
Organizing depot content

In the Depot folder, you can perform any of the following procedures to organize
depot content:
Create folders and smart groups. (A smart depot group is a group for which you
define membership conditions based on depot object properties.)
Cut and paste folders
Copy, cut, and paste smart depot groups
Delete depot objects, depot folders, and smart depot groups
Overview of software packages

BMC BladeLogic lets you package both Windows and UNIX-style software. When
you package software, you identify a source file and provide the necessary
commands to install and uninstall that software unattended on remote hosts. For
more information on this procedure, see Adding software to the Depot on
page 353. If an install or uninstall command references additional files, those files are
also included in the software package. Manually adding Windows patches and
service packs to the Depot requires a slightly different procedure, described in
Adding a hotfix to the Depot on page 365.
BMC BladeLogic provides built-in support for packaging many types of Windows
and UNIX software as well as a range of custom software applications. Built-in
support means BMC BladeLogic 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.
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 a description of this procedure, see Deploying a software package
on page 525.

BMC BladeLogic also 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 557.
A BLPackage is an aggregation of many types of server objects that are packaged
together so they can be deployed unattended on multiple remote hosts. When you
create a BLPackage, you store it in the Depot. For a description of how to create
BLPackages, see Adding a BLPackage to the Depot on page 375.
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.
BLPackages can consist of either Windows or UNIX-style server objects. A BLPackage

cannot mix Windows and UNIX-style server objects.
For Windows, a BLPackage can include the following:
Applications
COM+/MTS settings
Configuration files
Event logs
Hotfixes
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-style systems, a BLPackage can include the following:
AIX packages and patches

Configuration files
RPMs
Daemons
Processes
UNIX users
UNIX groups
Virtual host server and virtual machine configurations
Solaris packages, patches, and patch clusters
HP-UX product, patches, and bundles
External commands
After you create a BLPackage, you must sometimes edit the package to insert new
values for server objects, including parameterized property values. You can also
change the order in which server objects are processed, insert additional commands
and server objects, and make many other package- and object-level modifications.
BMC BladeLogic provides many tools for editing the contents of a BLPackage (see
Editing a BLPackage on page 383).
When you deploy a BLPackage, BMC BladeLogic 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.
For more information on deploying BLPackages, see Chapter 14, Software and
BLPackage Deploy Jobs.


Use this procedure to add one or more software packages to the Depot. A software
package consists of all the files necessary to perform an unattended installation of a
software executable. BMC BladeLogic provides built-in support for packaging the
following types of software:
Operating System Supported Software Types

Windows Operating system service packs
MSI packages
InstallShield packages
Hotfixes require a related procedure, described in

Adding a hotfix to the Depot on page 365
Solaris Packages
Patches
Patch clusters
Linux RPMs
AIX Packages
Patches
HP-UX Products
Patches
Bundles
When packaging the software types shown above, the system automatically
generates the appropriate install and uninstall commands. If necessary, these
standard commands include references to support files. For example, installing some
types of software requires a response file. When you add software to the Depot, you
must provide the location of those support files.
In addition to the standard types of software listed above, you can 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 what command line options are needed for silently installing and
uninstalling the software. The install and uninstall commands should reference any
necessary support files.
After adding a software package to the Depot, you can deploy it using a Deploy Job.
For a description of this procedure, see Deploying a software package on page 525.
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 and then
select the type of software package you want to create.

Add Software
Using the Servers folder, right-click a server and select Browse from the pop-up
menu, which display the Live node in 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 HP-UX bundle,
select one or more server objects and right-click. From the pop-up menu, select
Add To Depot As, and then select the type of software package you want to
create.
NOTE
Selecting Add To Depot => Hotfix initiates a related procedure, described in Adding a
hotfix to the Depot on page 365.
Using the results of a Snapshot Job, select software packages that should be
added to the Depot, as described in Adding software to the depot from
snapshot results on page 471.
Using the Select Matching Software window, you can add software packages to
the Depot, as described in Matching software with depot items on page 373.
The Select Matching Software window displays in many contexts throughout
the BMC BladeLogic console.
The Add Depot Software wizard opens.
2 Provide information for the wizard, as described in the following sections:
Add Software
Properties
Permissions
3 After completing the last step of the wizard, click Finish.
A background process saves the software package to the Depot. Depending on

how you have specified behavior for background processes, either a dialog 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. For
Add Software
The Add Software panel lets you choose the software items you want to package. You
can specify multiple software items, if necessary.

Add Software
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.
During a Deploy Job, the software package 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 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 are packaging 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 will all need to 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 any support files that
are needed for an installation, such as a response file.
All software, when being installed or uninstalled, generates a return code that BMC
BladeLogic processes. Currently, BMC BladeLogic treats all non-zero 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 BladeLogic 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 will use the default logicthat is, all non-zero return codes are treated as
errors (except 3010 for Windows).
If the Select Installable Sources dialog is displayed, proceed to step 2 on

page 356.
The Select Installable Source dialog displays if you did not select source files to
begin this procedure (as described in Adding software to the Depot on
page 353).

Add Software
If the Add Software window does not show the appropriate source file for a
software package, select that package in the left pane. Then, in the right pane,
for Installable source, click Browse to specify the source file for the selected
package. The Select Installable Source dialog opens. Proceed to step 2.
If the left pane of the Add Software window lists all the 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 358.
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
opens. See the next step for details on using the Select Installable Sources dialog.
To delete a software item from the list on the left, select the item and click Delete
.
2 Using the Select Installable Sources dialog, do the following:
A Using the hierarchical tree in the dialog, select one or more source files. Your
selections are listed in the Source Location field. If you select multiple items,
semicolons separate each item. If you prefer, you can skip this step and
manually enter the path to source files, as described in step C on page 356.
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 those source
files using the procedure described in step C on page 356.
B Do one of the following:
Select Upload source to File Server if you want to copy source files to the file
server. Proceed to step E on page 357.
When you select this option, you cannot edit the contents of the Source
Location field.
Select Refer to source at its current location if you do not want to copy the
source files to the file server. Instead, the source files reside at their network
location until deployment. Proceed to step C on page 356.
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 on using this tool, see Inserting a parameter on page 142.

Add Software
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
BladeLogic standard for network data transmission. See URL syntax for
network data transmission on page 362 for more information on using a
network-based URL.
NOTE
If you manually enter a source location, BMC BladeLogic does not validate your 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 different 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 would resolve to smb; on others it would resolve 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 C on page 356) must
provide a URL that complies with BMC BladeLogic requirements for network
data transmission, including a data transmission protocol of RSCD, NFS, or
SMB. See URL syntax for network data transmission on page 362 for
detailed information about the required syntax.
Agent mounts source for direct use at deployment (no local copy)The Deploy
Job instructs an agent to mount or map the device specified in the URL and
deploy the software package directly to the agent. When you select this
option, the agent uses the data transmission protocol specified in the URL to
access the specified source files. The software package is not copied to a
staging area on the agent, so no local copy of the source file is created.
To use either this option, the Source Location field (see step C on page 356)
must provide a URL that complies with BMC BladeLogic requirements for
network data transmission, including a data transmission protocol: either
NFS or SMB. See URL syntax for network data transmission on page 362
for detailed information about the required syntax.
E Click OK to close the Select Installable Sources dialog.
The files you have selected display in the left pane of the Add Depot Software
window.

Add Software
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 displays. Use the dialog 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 is only displayed for custom software.
B From Custom software type, select the type of software you are packaging.
BMC BladeLogic provides pre-packaged 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 displays 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 sources
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.

Add Software
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 only) To identify the software being deployed, click Browse to the
right of the Software info list. The Select Installable Location dialog 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 BladeLogic can
automatically populate the Software Info list.
If you do not use parameters when providing a network location and there is
an agent installed at the source location, the system can always automatically
determine the software that should be deployed for UNIX-based packages. It
accomplishes this by checking a list of applicable software packages and
version numbers contained within the software package itself. 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
that should be deployed. Similarly, BMC BladeLogic cannot access the list if
an agent is not installed on the host where the source files are located.
(Windows only) If you are adding Windows software to the Depot, you must
manually identify the files that must be deployed. To add an item to that list,
click the + sign to the right of the Software info list. The Software Part
Information dialog 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 are adding a Windows MSI package, you can open the Optional MSI
Customization Properties dialog by clicking Edit beside Optional Install MSI
Customization Properties or Optional Uninstall MSI Customization Properties.
Use these dialogs to create answers that replace the standard answers used in an
MSI-based silent install or uninstall. To create custom properties, use Name and
Value to enter a name/value pair and then click . The names that you enter
should correspond to standard names used in an MSI file. These name/value
pairs are used when you execute the MSI file. They do not change the MSI
package itself in any way. To delete an item from the list of name/value pairs,
select the item and click .
E 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 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 BladeLogic 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

Add Software
all parameters included in default install and uninstall commands. 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 software package is encapsulated in a
BLPackage, parameters can reference local properties for the BLPackage.
Option Description of Use Applies to:

??DEPLOYPATH?? The path to a sub-directory in a staging Typically used with support
directory on a target server. The sub- files but can be used with any
directory is named for the package type of file required for
being deployed. The sub-directory deployments or rollbacks.
contains files used for deployments and
rollbacks.
??INSTALL_RESPONSEFILE?? The response file used by the InstallShield packages
installable. Solaris packages
??INSTALL_ADMINFILE?? The admin file used by the installable. Solaris packages
??PACKAGEFILE?? The deploy path followed by the name HP-UX products
of the installable. HP-UX patches
??PACKAGENAME?? The name of the installable. RPMs
??PATCHID?? An identifier used in the uninstall Solaris patches
command.
??SOURCE?? The directory holding the software in OS service packs
the package being deployed. InstallShield packages
MSI packages
If the source is a zip file, the file name Solaris patches
extension is not used when resolving Solaris patch clusters
this parameter. For example, RPMs
install_dir.zip resolves to install_dir. AIX patches
AIX packages
Custom software
??SOURCEORPARENTDIR?? The source file being deployed if the Solaris packages
installable is a file; otherwise, the
parent directory if the installable is a
directory.
??SUBPACKAGES?? The subpackages you want to install or Solaris packages
uninstall. AIX packages
HP-UX products
HP-UX bundles
??SUBPATCHES?? The subpatches you want to install or AIX patches
uninstall. HP-UX patches
HP-UX bundles
??UNINSTALL_ADMINFILE?? The admin file used to uninstall the Solaris packages
installable.
??UNINSTALL_RESPONSEFILE?? The response file used to uninstall the InstallShield packages
installable.
??WINDIR?? The environment variable representing OS service packs
the Windows directory, such as
/c/winnt.

Add Software
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??. Any
reference you create in this way appears 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 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.
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 have modified the install command so it does not include 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 have modified the uninstall command so it does not include a
??SUBPACKAGES?? parameter, the command is left untouched. There is no uninstall
command for AIX patches. These automatic modifications of AIX packages and patches
are not visible within the Add Software wizard. They occur when the software package
is actually created.
F For Uninstall command, enter the command, including any arguments, that
invokes the uninstall. This field automatically displays the default uninstall
command for the type of software you are packaging. 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
displays. For File location, use Browse or enter the location of the file being
referenced. Clicking Browse displays a dialog 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 356. If necessary, you can enter a URL to identify a
network location. You can also use parameters in the file name, but parameters
are not substituted if you are entering a URL for a network location. If you do

Add Software
not want the system to insert values for any parameters that appear within the
body of this file, check Skip parameter substitution for this file. (This is typically
necessary when a support file is binary, such as an MSI package with a required
CAB file.) Finally, 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 358 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).

Add Software
NOTE
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 BladeLogic 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 BladeLogic consults the NFS server to determine which
initial sub-string in the path is exported. BMC BladeLogic combines this sub-string
with the absolute path defined using the Path component.

Properties
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.
Properties
The Properties panel shows a list of properties automatically assigned to a software
package, as determined by the DepotObject built-in property class in the Property
Dictionary (see Using the Property Dictionary on page 118). These properties are
typically used for sorting packages into smart groups and assigning characteristics to
the package, such as its testing and development status. You can modify the value of
any properties on the Properties panel that are defined as editable. For more
information on assigning property values, see Setting values for system object
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.

Permissions
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.
Permissions
The Permissions panel is an access control list granting roles access to this software
package. Access to all objects, including the sharing of objects between roles, is
Adding a hotfix to the Depot

Use this procedure to add one or more hotfixes to the Depot.
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, as described in Adding software to the
Depot on page 353.
After adding a hotfix to the Depot, you can deploy it using a Deploy Job. For a
description of this procedure, see Deploying a software package on page 525.
software package. From the pop-up menu, select New => Software => Hotfix.

Add Software
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, as described in Adding software to the depot from snapshot results
on page 471.
Using the Select Matching Software window, you can add hotfixes to the Depot,
as described in Matching software with depot items on page 373. The Select
Matching Software window displays in many contexts throughout the BMC
BladeLogic console.
The Add Depot Software wizard opens.
Add Software
Properties
Permissions
A background process saves the patch or hotfix to the Depot. Depending on how
you have specified behavior for background processes, either a dialog 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. For
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.
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.

Add Software
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.
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 displays, 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 displays. You must manually provide all
of the required information for each of the hotfixes listed on this window. Click
OK on this dialog and proceed to step 2 on page 367 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 displays. Proceed to step 2 on page 367.
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 opens. Proceed to step 2.
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 opens. See the
next step for details on using the Select Installable Sources dialog.
To delete a hotfix from the list on the left, select the item and click Delete .
2 Using the Select Installable Sources dialog, do the following:

Add Software
A Using the hierarchical tree in the dialog, select one or more source files. Your
selections are listed in the Source Location field. If you select multiple items,
semicolons separate each item. If you prefer, you can skip this step and
manually enter the path to source files, as described in step 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 those source
files using the procedure described in step C.
B Do one of the following:
Select Upload source to File Server if you want to copy source files to the file
server. Proceed to step E.
When you select this option, you cannot edit the contents of the Source
Location field.
Select Refer to source at its current location if you do not want to copy the
source files to the file server. Instead, the source files reside at their network
location until deployment. Proceed to step 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 on using this tool, see Inserting a parameter on page 142.
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
BladeLogic standard for network data transmission. See URL syntax for
network data transmission on page 362 for more information on using a
network-based URL.
NOTE
If you manually enter a source location, BMC BladeLogic does not validate your 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 different 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 would resolve to smb; on others it would resolve to nfs.

Add Software
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 C) must provide a URL
that complies with BMC BladeLogic requirements for network data
transmission, including a data transmission protocol of RSCD, NFS, or SMB.
See URL syntax for network data transmission on page 362 for detailed
information about the required syntax.
Agent mounts source for direct use at deployment (no local copy)The Deploy
Job instructs an agent to mount or map the device specified in the URL and
deploy the software package directly to the agent. When you select this
option, the agent uses the data transmission protocol specified in the URL to
access the specified source files. The software package is not copied to a
staging area on the agent, so no local copy of the source file is created.
To use either this option, the Source Location field (see step C) must provide
a URL that complies with BMC BladeLogic requirements for network data
transmission, including a data transmission protocol: either NFS or SMB. See
URL syntax for network data transmission on page 362 for detailed
information about the required syntax.
E Click OK to close the Select Installable Sources dialog.
The files you have selected display in the left pane of 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 displays. Use the dialog 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.

Add Software
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 F on page 371 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.

Add Software
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 BladeLogic 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 369 for each item listed in the left pane.

Properties
Properties
The Properties panel shows a list of properties automatically assigned to a patch or
service pack, as determined by the DepotObject built-in property class in the Property
typically used for sorting objects into smart groups and assigning characteristics to an
object, such as its testing and development status. You can modify the value of any
properties on the Properties panel that are defined as editable. For more information
on assigning property values, see Setting values for system object properties on
page 140.
The property called DEPENDENCY_LIST lets you specify dependencies a hotfix 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 hotfix
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 any hotfix does not include that hotfix as a
dependency. In other words, the DEPENDENCY_LIST property for Hotfix1 should not have a
default value that includes Hotfix1. Use the Property Dictionary to define a default value for
the DEPENDENCY_LIST property.
Permissions
The Permissions panel is an access control list granting roles access to this patch or
service pack. Access to all objects, including the sharing of objects between roles, is
Modifying a software package

Use this procedure to modify a software package or hotfix that you have already
added to the Depot.

Matching software with depot items
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 containing a Software Properties Panel, which corresponds to the options on
the Add Software panel of the Add Depot Software wizard. For more
information on these options, see any of the following:
Add Software (for software packages)

Add Software (for hotfixes)
properties, permissions, or audit trail information that apply to this software
package or hotfix. For more information, see Properties, Permissions, and
Audit Trail tab group on page 98.

Use this procedure to 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 BladeLogic to add it, and the system
launches a utility for adding that software item to the Depot.
If you are adding software to the Depot as part of an uninstall process, you have the
option of instructing the system to use the default command to uninstall the software.
If you choose this option, you do not have to add a software package to the Depot to
perform the uninstall. This option is only available when you are selecting software
that should be uninstalled and the default uninstall command does not require
additional information to perform the uninstall. In some situations, such as the
creation of a BLPackage from audit results, you may be both installing and
uninstalling installables. In that situation, the Select Matching Software window
displays two tabs. Use one tab for matching software needed for installs. Use the
other tab for matching software needed for uninstalls.

1 If the Select Matching Software dialog displays tabs, do one of the following. If the
dialog 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
dialog displays. Do one of the following:
Using the navigation tree in the dialog, 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 on using this window, see Adding a
hotfix to the Depot on page 365, a procedure specifically for adding
Windows patches and service packs to the Depot, or Adding software to the
Depot on page 353, a generalized procedure for adding all other types of
software.
Select Ignore to exclude an item from the group of installables you are
deploying, packaging, or uninstalling.
Select Use Default Uninstall Command if the default uninstall command for this
software item does not require additional information, such as an installable
source file. When you select this option, the system uses the default command to
uninstall the software. Selecting Use Default Uninstall Command means you do
not have to add an installable source file to the Depot to perform an uninstall.
This option is only available when you are uninstalling, and it is only available
for the following types of software:
RPM
Solaris package
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 374.
4 Click OK.

Use this procedure to add a BLPackage to the Depot. 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 BladeLogic 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 BladeLogic 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.
BLPackage. From the pop-up menu, select New => BLPackage.
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.

Package Type
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.
The Create BLPackage wizard displays.
Package Type
Package Contents
Package Options
Properties
Permissions
A background process saves the BLPackage to the Depot. Depending on how you
have specified behavior for background processes, either a dialog 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. For information
on the dialog and background operations, see Running operations in the
background on page 67.
After saving the BLPackage, you may want to use the BLPackage editor to modify
the BLPackage (see Editing a BLPackage on page 383).
After saving the BLPackage, you can now deploy it, as described in Deploying a
BLPackage on page 527. If you accessed the Create BLPackage wizard by
selecting a component to deploy, the New Deploy Job wizard opens automatically.
Package Type
The Package Type panel asks you to identify the package and choose a method for
creating the package.
1 For Package name, enter a name for the BLPackage you are creating.
2 For Save in, click Browse and navigate to the depot folder where you want to
save the BLPackage.

Package Contents
3 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.
Package Contents
This panel lets you choose the contents of the BLPackage you are creating. The
contents and name of this panel depend on how you decided to create a BLPackage in
the previous panel. The following sections describe the possible options:
Select Server Objects

Components
Snapshots
Depot files
Software
Master Snapshot
Select Server Objects

Use the Select Server Objects panel to 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.
1 Click Add . The Select Server Objects window opens.
2 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.
3 Click OK. The selected server objects display in the Server Objects list in the Select
Server Objects panel.

Package Contents
4 Use the Includes and Excludes section of the Select Server Objects panel to refine
your choices for the server objects included in the BLPackage.
5 To recursively select all subfolders in a folder, select Recurse subfolders in the

Includes/Excludes section.
6 If the server objects you have chosen include software that does not match
software stored in the depot, the Select Matching Software window displays. 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 373.
Components
Use the Components panel to select components for a BLPackage.
1 Click Add Components . The Select Components dialog opens.
2 Select the components to include in the BLPackage and click OK.
Snapshots
Use the Snapshots panel to select snapshots for a BLPackage.
1 Click Add Snapshot . The Select Snapshots dialog opens.
2 Select a snapshot for a server and click OK.
Depot files
Use the Depot Files panel to select files stored in the Depot that should be included in
a BLPackage.
1 Click Add Depot Files . The Select Depot Files dialog opens.
2 Select one or more files and click OK.
Software
Use the Software panel to select software packages stored in the Depot that should be
included in a BLPackage.
1 Click Add Depot Software . The Select Depot Software dialog opens.
2 Select one or more software packages and click OK.The Depot Software list on the
Select Server Objects panel shows the packages you have selected.

Package Contents
3 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 .
Master Snapshot
If you have chosen the delta method to create a BLPackage, use the Master
Snapshot panel to identify a snapshot, which BMC BladeLogic 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.
1 Click Browse to identify the snapshot on which packaging is based.
Includes and Excludes

The Includes/Excludes section lets you include and exclude server objects from the
list of server objects that make up a BLPackage. For example, you might want to
exclude all log files or backup files in a directory. You can include or exclude software
objects, such as packages or hotfixes, and any of the following types of hierarchical
server objects:

COM+
Metabase
Registry
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].

Package Contents

current directory
??? Match server objects that contain exactly
three characters
*.[a-z] Match all server objects in the current
directory that have a one-letter lowercase
extension
[Ww]eb Match server objects called either Web or
web
When you define an exclude, any server objects not matching the definition are
excluded. For example, if you define the exclude as *.log, any objects ending in .log
are excluded.
1 To include or exclude server objects from a BLPackage, select an item in the list of
server objects that make up the BLPackage and do one of the following:

For Name, enter a path to the server object you want to include or exclude,


Package Options
3 Click OK.
Package Options
The Package Options panel lets you specify options that control how a BLPackage is
created.
1 Under Depot Asset Options, do one of the following:
Check Soft linked to gather the contents of the BLPackage at the time of
deployment rather than the time of package creation.
Clear Soft linked to gather the contents of the BLPackage when you finish
defining the job.
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 itself can be cached on a repeater, its contents cannot
reference any objects that may already be stored in the repeaters cache.
2 Under File Options, check any of the following characteristics to control how files
are handled when a BLPackage is created:
Collect file/directory attributesRecord 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.

Properties
Copy file contentsCopy the contents of all files included in the BLPackage.
Collect access control list (ACL) attributesCollect permission and log

information for files. This option is only applicable if the servers or snapshots
being compared use Windows NT File System (NTFS).
3 Under Registry Options, check Collect access control list (ACL) attributes to instruct
the BLPackage to gather ACLs for Windows registry entries.
This option is only available if you are packaging registry information.
4 Under Patch Package Options, check Include dependent packages to instruct the
BLPackage to gather any patches that are prerequisites for the patches you have
included in this BLPackage. The BLPackage will sequence patches according to
their dependencies.
This option is only available if you are packaging patches.
Properties
BLPackage, as determined by the BLPackage built-in property class in the Property
typically used for sorting packages into smart groups and assigning characteristics to
the BLPackage, such as its testing and development status.
You can modify the value of any properties on the Properties panel that are defined
as editable. For more information on assigning property values, see Setting values
You can assign local properties to a BLPackage during the package editing process
(see Editing a BLPackage on page 383). Parameters in the BLPackage refer to those
local properties; they do not refer to the properties in this list.
Permissions
The Permissions panel is an access control list granting roles access to this BLPackage.
Access to all objects, including the sharing of objects between roles, is controlled

Editing a BLPackage
Editing a BLPackage
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.
The BLPackage editor allows you to manually modify the contents of a BLPackage.
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 396). Local
properties are particularly valuable when deploying multiple instances of the same
BLPackage to a single server.
The BLPackage editor displays 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 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.
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 on using parameters, see Inserting a
parameter on page 142. For a discussion of the rules that apply when entering paths,
see Rules for entering paths on page 47.
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 displays
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.

Editing a BLPackage
NOTE
When packaging configuration options for VMware, 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 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 Understanding audit results for
configuration files.
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.

Opening a BLPackage to edit
When editing a BLPackage, you can perform any of the following procedures:

Changing object attributes in a BLPackage
Adding a local property to a BLPackage
Moving an object within a BLPackage
Ordering software within a BLPackage by dependency
Deleting an object in a BLPackage
Providing password information in a BLPackage
Finding and replacing text in a BLPackage
Importing assets into a BLPackage
Creating an RPM group
Changing network-based software deploy options
Commenting out assets
Verifying assets in a BLPackage
Closing the BLPackage editor

Use this procedure to open a BLPackage for editing. 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.
BMC BladeLogic warns you if another user is also editing a BLPackage.
1 Using the Depot folder, navigate to the depot folder holding the BLPackage you
want to edit.
2 Right-click the BLPackage and select Open from the pop-up menu.
A new tab with the name of the selected BLPackage displays.
When you open a BLPackage that includes an older 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.

Use this procedure to change the attributes of an object in a BLPackage.

1 In the hierarchy view, select the object that you want to modify. The right pane
shows 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 UNIX 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 on using this tool, see Inserting a parameter on page 142.
When changing attributes of objects in BLPackages, note 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 UNIX objects or a Hardware Information object 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 opens. Use it to change the password, as described in Providing
password information in a BLPackage on page 398.
When editing a Windows local user, be aware that the Action field has the
following effects:
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-style files lets you click Browse to display
a dialog where you can edit the files permissions.
For additional procedures explaining how to change attributes of objects in a

BLPackage, see the following:
Working with soft-linked objects

Setting single-user mode for an object
Setting a reboot for an object
Setting action on failure
Editing Windows security settings
Changing file ownership attributes
Editing multi-value registry entries
NOTE
For a discussion of the rules that apply when entering paths to server objects, see Rules for
entering paths.
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
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.
1 In the hierarchy view, select an object that is soft-linked. The right pane shows 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 except files, 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 asks for confirmation. Once 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, click Yes.
Setting single-user mode for an object

Use this procedure to specify that an object be deployed in single-user mode.
Single-user mode is a minimal UNIX environment typically used when installing or

removing software. 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 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 BladeLogic cannot
communicate with the agent on that server.
NOTE
Solaris servers use reboots. All other UNIX-style 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-based 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.
Once 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 BladeLogic 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.
1 In the hierarchy view, select an object included in the BLPackage. The right pane
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 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

Use this procedure to specify a reboot for an object in a BLPackage. 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 Solaris, is
required for some new hardware and for some software patches.
1 In the hierarchy view, select an object included in the BLPackage. The right pane
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 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

By editing object attributes in a BLPackage you can specify how a Deploy Job reacts to
a failure when installing a software package or executing an external command. The
options 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 403), and run the Deploy Job
again.
For example, suppose you are installing five RPMs named A, B, C, D, and E.
Installation of A and B have no effect on the operation of C, D, and E. If another
RPM is required to install A and B, their installation will fail. However, if you set
ActionOnFailure to Ignore the A and B RPMs, you could let the Deploy Job
continue so the C, D, and E RPMs install successfully. Later, you could install the
missing RPM, use the BLPackage editor to comment out the C, D, and E RPMs that
already installed successfully, and run the job again.
ContinueThe failure is ignored and the job continues. Deploy Job results show
the job as failing.
The Continue action takes precedence over the Ignore action. If a Deploy Job includes
multiple commands that have failed and the ActionOnFailure for these commands is
defined as both Ignore and Continue, the overall job appears to have failed.
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

Use this procedure to modify options available 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.
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 displays when you click in the Value column. (For more information
on using this tool, see Inserting a parameter on page 142.) If the package has a
network-based location, the URL you enter must comply with BMC
BladeLogics standard for network data transmission (see URL Syntax for
Network Data Transmission).
Select Staging and then click in the Value column. A drop-down list displays.
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 BladeLogics requirements for network data
transmission, including a data transmission protocol: either NFS or SMB. See
URL Syntax for Network Data Transmission 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.

Editing Windows security settings

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. This
section details all possible results to help you understand the behavior of a
deployment or rollback that includes a Windows security setting.
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.
Single or
Full or Multiple
Action Replace Empty Value Values Deployment Rollback
Add or Modify Yes or No Value is Single Replaces the single Writes an Add or
provided value currently in the Modify (depending
For keys that can file with the value on the original
only have one passed in. command) using the
value, the original single value.
Replace option On rollback, that
is ignored. value replaces the
new value.
Add or Modify Yes or No Empty value Single Replaces the single Writes an Add or
value currently in the Modify (depending
For keys that can file with a blank on the original
only have one value. This action command) using the
value, the effectively performs a original single value.
Replace option delete. It is useful On rollback, that
is ignored. 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.

Single or
Full or Multiple
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 that
an entry being added did not exist before
already exists in the the command was
targets Value list, 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.
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 effectively command) using the
deletes all entries. It is original list of values.
useful when you need On rollback, those
to empty a value and values replace the
you do not know how blank entry.
that value is set on all
targets.
Delete Yes or No Value is Single If the target is set to a Writes an Add
provided value, this action command to change
The Replace deletes that value and the deleted value
setting is renders the entry back to its original
ignored for all blank. setting.
Delete
commands.

Single or
Full or Multiple
Delete Yes or No Empty value Single No action occurs. Writes a Delete
command for the
The Replace single empty value,
setting is which essentially
ignored for all results in no action.
Delete
commands.
Delete Yes or No Values are Multiple If the target has Writes an Add
provided entries in a value list, command that adds
The Replace this action removes only those values that
setting is those entries. were deleted from
ignored for all original list.
Delete
commands.
Delete Yes or No Empty value Multiple No action occurs Writes a Delete
command for a list
The Replace with multiple empty
setting is values, which
ignored for all essentially results in
Delete no action.
commands.
Changing file ownership attributes

When deploying files or rolling back a file deployment, a Deploy Job can fail because
users who are not owners of the existing files cannot change the ownership attributes
of those files. This procedure lets you specify whether to apply or ignore file owner
attributes. This capability can be used during a deployment or a rollback.
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.
1 In the hierarchy view, select any file included in a BLPackage. The right pane
shows the attributes associated with that file.

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.
Editing 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.
The Data field for the registry value concatenates the names of all nodes and displays
their names in encoded form. If the Multivalue property for the registry value is set to
1, the BLPackage uses the name set for each individual node. If the Multivalue
property is set to 0, the BLPackage uses the collective name created by concatenating
the names of all nodes.
When you use a BLPackage to add an entry to a registry value, the entry is added to
the end of the list of entries. When you use a BLPackage to delete an entry from a
registry value, the system deletes the first entry it encounters that matches the entry
you have specified.
NOTE
You cannot use a BLPackage to change the sequencing of nodes in a multi-value registry
value. Also, BLPackages cannot accommodate multi-value registry values with multiple
nodes that have the same name.

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.
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 older releases of BMC BladeLogic, 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??.
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 125.

Use this procedure to move an object within a BLPackage. You cannot move an object
to a higher level in the hierarchy, in effect changing the parent of that object.
1 In the hierarchy view, select the object you want to move. 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.
Ordering software within a BLPackage by dependency

Use this procedure to order software packages within a BLPackage 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.

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.

Use this procedure to delete an object within a BLPackage.
1 In the hierarchy view, select the object you want to delete. Right-click and select
Delete from the pop-up menu. A message prompts you to confirm that you want to
delete the selected item and its children. If you do, click Yes.
Providing password information in a BLPackage

Use this procedure to provide password information in the Password Required
window. The Password Required window displays when you do any of the
following:
Edit the password field for a Windows service or COM+ object.
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.

1 On 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.

Use this procedure to find text and optionally replace text within a BLPackage. Both
searching for and replacing text are particularly valuable tools when editing large
BLPackages.
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 displays. Contents of the dialog vary depending on whether you
are finding text or finding and replacing text.
2 For Find what, enter the text string you are searching for.
3 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.
4 Under 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.
5 Under Object Types, specify the type of objects you want to search by doing one of
the following:
Select All object types to search all types of objects included in the BLPackage.
Select Selected object types to search for instances of a particular object type. You
can choose from any of the object types that might be included in the
BLPackage, such as File System, Registry, or Metabase.
6 Under Object Scope, specify what 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.
7 Under 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.
8 Do one of the following to find and optionally replace text:
To find text, do the following:
A. Click Find. When the search utility finds a match, it highlights the text string
and displays a dialog.
B. Click one of the following:
Find NextSearches for another instance of the text string.
CancelCancels the search.

Adding a custom action to an asset
To find and replace text, do the following:
A. Click Replace. When the search utility finds a match, it highlights the text
string and displays a dialog.
B. 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.
Adding a custom action to an asset

Use this procedure to add an asset that includes a custom action to a BLPackage.
Currently, the only assets that allow custom actions are the UNIX objects.
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
displays.
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 server objects that have deployable actions.
3 For Path, click Browse , which displays a selection dialog. (The name of the
dialog depends on the type of asset you selected in the previous step.) Using the
dialog, 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.


Use this procedure to add assets to 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 displays.
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 375). 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.
Creating an RPM group

Use this procedure to 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.
1 Add RPMs to the BLPackage, as described in Importing assets into a BLPackage

on page 402.
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.

Adding an external command to a BLPackage
Adding an external command to a BLPackage

Use this procedure to add an external command to a BLPackage. An external
command is any type of command that can be issued on a command line interface
such as Network Shell. 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.
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:
Cmdprovides a command to be executed when the BLPackage is deployed.
UndoCmdprovides a command to be executed when the BLPackage

deployment is undone.
3 If necessary, enter a value for ActionOnFailure (see Setting action on failure on

page 391).
4 Move the external command to the correct position in the BLPackage (see Moving
an object within a BLPackage on page 397).
Commenting out assets

Use this procedure to 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.
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


Use this procedure to 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.
1 Right-click in the hierarchy view and select Verify from the pop-up menu. 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 on an error or message to see which node in the package has generated the
error or warning.
Double-clicking on a message displays the text of the message in the Verification

Messages section of the tab. Click Close to close the panel.
Closing the BLPackage editor

Use this procedure to close the BLPackage editor. When you save the contents of the
BLPackage, your edits completely replace the existing version of the BLPackage.
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.
Adding a Network Shell script

Use this procedure to add a Network Shell script to the Depot. For information on
deploying Network Shell scripts, see Creating Network Shell Script Jobs on
page 567. For information on modifying an existing Network Shell script, see
Modifying a Network Shell script on page 408.

Script Options
1 To add a new script, do one of the following:
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:
Script Options
Parameters
Properties
Permissions
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.
1 For Name, enter an identifying name for the script. For Description, you can
2 For Save in, specify a location in the Depot where the script should be stored by
clicking Browse . The Select Folder dialog opens. Choose a depot folder and click
OK.
3 For File location, enter the full path to the script (including host name for remote
locations) or click Browse to navigate to the script.
4 From File encoding, select the type of character encoding that is used for the script,
such as UTF8 or UTF16.
5 Under Script Type, select one of the following:
Execute the script separately against each hostThe script executes repeatedly,
each time running on a different server. This option uses the Network Shell
runscript program, which can run the same command on multiple machines.

Parameters
Execute the script once, passing the host list as a parameter to the scriptThe 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.
Copy and execute the script against each host separatelyThe script is repeatedly
copied to different servers and then executed on each of those servers. 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 on Windows user mapping, see Create automation principals on
page 149. For more information on setting up a secure file, see the BMC BladeLogic Server
Parameters
The Parameters panel lets you define parameters that are replaced with server
property values when a script runs. You can add flags to those 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. For more information on server properties, see Properties and
servers.
When you deploy a Network Shell script, BMC BladeLogic 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 once against multiple hosts (as defined using the Script
Options on page 405 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.

Parameters
1 Display the Add Parameter dialog by clicking Add Parameter or selecting a

parameter in the Script Parameters list and then clicking Update Parameter .
The Add Parameter dialog displays.
2 For Name, enter the name of the parameter. The name you enter must exactly
match a parameter name defined within the script. You can optionally provide an
entry for Description.
3 For Flag, you can optionally 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.
4 If the flag can accept a value, do the following:
A Check Parameter flag required at runtime 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.
B Check Accepts value.
C To provide a default value for the flag, enter a value for Default 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 on using this tool, see Inserting a parameter
on page 142.
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 opens. For Property
class, click Browse. The Property Class Selection dialog opens. Select a custom
property class and click OK. Then, for Property class instance, click Browse. The
Choose Property Class Instance dialog opens. Select an instance of a custom
property class and click OK. Then click OK to close the Property Class Instance
dialog.
D If a value for the flag is required for the script to execute, check Value required at
runtime.
E If the value can be edited when you run the script, check Editable.

Properties
5 Click OK.
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 .
Properties
The Properties panel shows a list of properties automatically assigned to a Network
Shell script, as determined by the DepotObject property class in the Property
Dictionary (see Using the Property Dictionary on page 118). You can modify the
value of any properties in this list that are defined as editable. For more information
on assigning property values, see Setting values for system object properties on
page 140.
Permissions
object (in this case, a Network Shell script). Access to all objects, including the sharing
of objects between roles, is controlled through ACLs. For more information on
Modifying a Network Shell script

Use this procedure to modify a Network Shell script that you have already added to
the Depot.
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 wizard. For more information on these options, see any of the
following:
Script Options
Parameters
Script
Use the Script tab to display and modify the contents of the script.

Script
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 displays 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 on using
editors, see Working with content editors on page 68.
properties, permissions, or audit trail information that apply to this Network
Shell script. For more information, see Properties, Permissions, and Audit Trail
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 404).
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 on using editors, see Working with content editors on page 68.
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

Use this procedure to add a file to the Depot.
After you have added a file to the Depot you can edit it using your choice of editors.
For more information on using editors, see Working with content editors on
page 68. To see or modify any properties, permissions, or audit trail information that
apply to this file, select the Properties, Permissions, and Audit Trail view. For more
information, see Properties, Permissions, and Audit Trail tab group on page 98.
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.

General
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 => File.
2 Provide information for the file, as described in the following sections:
General
Properties
Permissions
General
The General panel lets you provide identifying information for the file you are
adding to the Depot.
1 For 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.
2 For Name, enter a name for the file if a name is not already displayed in this field or
you want to identify the file using a different name. If you also want a description
for the file, enter one in the Description field.
3 For Save in, specify a location in the Depot where the file should be stored by
clicking Browse button. The Select Folder dialog opens. Choose a depot folder and
click OK.
Properties
The Properties panel shows a list of properties automatically assigned to a file, as
determined by the DepotObject property class in the Property Dictionary (see Using
the Property Dictionary on page 118). You can modify the value of any properties in
this list that are defined as editable. For more information on assigning property
values, see Setting values for system object properties on page 140.

Permissions
Permissions
object (in this case, a file). Access to all objects, including the sharing of objects

Permissions

Chapter
10
10 Managing jobs
A job is a set of instructions for performing a task on one or more servers. BMC
BladeLogic provides many types of jobs, described below:
ACL Push JobsConvert the permissions for servers into entries in access control
lists and then copies those lists to agents. For more information, see Creating ACL
Push Jobs on page 195.
Atrium Import JobsTransfer business service data from a BMC Atrium CMDB to
the BMC BladeLogic database. For more information on these jobs see BMC
BladeLogic Integration for Atrium: Implementation Guide.
Audit JobsDetermine whether server configurations comply with a standard

configuration. For more information, see Chapter 12, Audit Jobs.
Batch JobsRun a concatenated series of other jobs on remote servers. For more
information, see Chapter 16, Batch Jobs.
Compliance JobsDetermines whether components satisfy compliance rules

established for a component template. For more information, see Creating
Component Discovery JobsAssociates components with servers that match

conditions you define for each component template. For more information, see
Creating Component Discovery Jobs on page 294.
Deregister Configuration Objects JobsRemoves implementation files for custom

server objects from servers. For more information, see Creating a Deregister
Configuration Object Job on page 656.
Distribute Configuration Objects JobsDistributes implementation files for

custom server objects to servers where you want to use these objects. For more
information, see Creating a Distribute Configuration Objects Job on page 642.
File Deploy JobsCopy files and directories from a managed server to multiple
locations. Fore more information, see Chapter 13, File Deploy Jobs.

Network Shell Script JobsDeploy and execute Network Shell scripts on remote
servers. For more information, see Chapter 15, Network Shell Script Jobs.
Patching jobsManage 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. For more information, see chapters 19
through 23.
Provision Jobs Perform unattended installations of operating systems on new

machines (bare metal machines) or re-provision existing machines. For more
information, see Creating a Provision Job on page 1024.
Software and BLPackage Deploy JobsDeploy BLPackages and software

installables to remote servers without user interaction. For more information see
Chapter 14, Software and BLPackage Deploy Jobs.
Snapshot JobsRecord the configuration of a group of server objects at a point in

time. For more information, see Chapter 11, Snapshot Jobs.
Update Server Properties JobsObtains the most recent property settings from
agents and updates them in the BMC BladeLogic console. For more information,
see Creating Update Server Properties Jobs on page 212.
Upgrade Model Objects JobsUpgrade policy-based objectsthat is, component

reference the most recent version of a server object. For more information, see
Creating an Upgrade Model Objects Job on page 649.
Virtual Guest JobDeploy a new VMware virtual machine on the VMware

vCenter server (which must be a BMC BladeLogic managed server). For more
information, see Adding a new Virtual Machine on page 601.
Virtual Infrastructure Discovery JobProvides a view of the virtual machine

inventory, without having to manually find and register each virtual machine. For
more information, see Creating the Virtual Infrastructure Discovery Job on
page 616.
A job run is the result of executing a job at a particular time on one or more servers.
There may be many job runs for a single job. 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 on defining permissions, see Chapter 6,
Managing access. 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 a Batch Job, basic Deploy Job, File Deploy Job, or Network Shell
Script Job.
Each instance of the job cannot target any of the same servers.
To view, obtain information about, and cancel jobs in progress, use the Tasks in
Progress view, as described in Managing jobs in progress on page 427. To view and
obtain information about scheduled jobs using the Jobs folder, see Viewing job
schedules on page 443.
BMC BladeLogic provides many ways to access jobs. The Jobs folder holds all jobs.
From there you can execute jobs and view job history, job logs, and job definitions.
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. For information
on the actions you can perform on jobs in the Jobs or Servers folder, see the following:
Viewing history for a job

Viewing job activity
Viewing the status of a job
Viewing the job definition of a job run
Viewing job logs
Exporting job logs
Managing jobs from the Jobs or Servers folder
For information about assigning properties to jobs, see Properties and jobs on
page 416. To avoid problems running jobs against unresponsive servers, you can
update the status of agents, as described in Updating server status before running a
job on page 446.
BMC BladeLogic provides procedures that can help you avoid or resolve problems
that may occur when a job encounters an unresponsive or unlicensed server. For
more information, see Avoiding problems with hung jobs on page 443.
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

Organizing jobs
schedules for different target servers and to coordinate job schedules with upcoming
maintenance windows on the various servers. For information about the creation and
management of Execution Tasks, see Using Execution Tasks to manage job runs on
page 429.
BMC BladeLogic lets you export jobs so they can be saved in an external file system,
and then import those jobs back into BMC BladeLogic. For information on this
process, see Importing and exporting BMC BladeLogic objects on page 101.
BMC BladeLogic includes a retention policy utility that allows you to mark old job
runs for deletion from the database. For more information, see the section on marking
data for deletion in the BMC BladeLogic Server Automation Administration Guide.
Organizing 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.
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.
BMC BladeLogic 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. For more information on the Property Dictionary, see Using the


In the Jobs and Servers folders, you can take the following actions on jobs:
Opening a job
Executing a job
Executing a job against specific targets
Executing a job against failed targets
Defining a job execution override for a role and user
Executing 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.)
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.
For more information on these procedures, see Managing BMC BladeLogic

resources on page 84.
Opening a job
Use this procedure to open an existing job so you can view and modify its definition.
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 displays in a
tabbed window, where you can view and edit job properties.

Executing a job
Executing a job
Use this procedure to execute a job. You can monitor the progress of the job in the
progress pane (see Managing jobs in progress on page 427).
NOTE
To perform this procedure you must have, at minimum, Read and Execute authorizations for
the job. For example, to use this procedure to execute an Audit Job, you must have, at
minimum, AuditJob.Read and AuditJob.Execute.

2 Right-click the job and select Execute from the pop-up menu.
Executing a job against specific targets

Use this procedure to execute a job one time against servers that you specify.
Performing this procedure does not modify the existing definition of a job.
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.
NOTE
To perform this procedure you must have, at minimum, Read, Execute, and ModifyTargets
authorizations for the job. For example, to use this procedure to execute an Audit Job, you
must have, at minimum, AuditJob.Read, AuditJob.Execute, and AuditJob.ModifyTargets.
Executing against specific targets is not relevant and cannot be performed for the following
types of jobs: Atrium Import Job, 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.

2 Right-click the job and select Execute Against from the pop-up menu.

3 In the Execute Job Now window, use the following steps to select target servers:
A From Available Servers, specify the operating system of the servers you want to
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 By Name at the bottom of the window. The left panel lists servers by name
in a table view. Sort servers in ascending or descending order by clicking on any
column header. Click one or more servers.
If you select a server group, the job runs against the servers assigned to that
group at the time of execution. The servers assigned to smart groups can change
dynamically based on their server properties. You can modify static server
groups manually by adding or removing servers.
C Click the right arrow to move your selections to the right panel.
To remove a server from the list on the right, select it and click the left arrow.
To remove all servers from the list on the right, click the double left arrow.
4 Click OK to execute the job immediately.

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 problems 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
To perform this procedure you must have, at minimum, Read and Execute authorizations for
the job. For example, to use this procedure 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.
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.
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 steps 1 and 2 if you are repeating this procedure after having
already created an Execution Task during a previous execution against failed targets (see
step 4), 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, see
Using Execution Tasks to manage job runs on page 429.
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).
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 (see note on page 420).

BMC BladeLogic 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 (see Executing a job against failed targets on page 419 and
Executing a job against specific targets on page 418). Those actions do not modify a
jobs definition. One role:user combination can set up an execution override, while
another role:user combinations 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.
On the Job Options panel of the Batch Job wizard or the General panel of every 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.
Clear an existing override by clicking Clear 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.

The BMC BladeLogic 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 on configuring the
connection to BMC Atrium Orchestrator and BMC Remedy ITSM, see BMC BladeLogic
You can specify an approval type when you execute a job or schedule a job for
execution, as shown in the following table.

Action Result
Executing a job by If BMC Remedy ITSM approval is not
required, the job executes immediately.
selecting the Execute Now checkbox in
the job creation wizard. If BMC Remedy ITSM approval is required,
the Enter approval information dialog is
right-clicking an existing job and displayed. See Setting the approval type
selecting Execute. on page 423.
execute a job against failed targets
using an execution task

When you add a schedule: If BMC Remedy ITSM approval is not
required, the job executes according to the
by using a wizard to create a new job schedule.
by editing an existing job If BMC Remedy ITSM approval is required,

the Approval Information tab is displayed.
See Setting the approval type on
page 423.
Setting the approval type

You select an Approval type and enter the BMC Remedy ITSM parameters needed to
create a new change ticket or use an existing one.
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.
Approval parameters determine the values of the corresponding BMC Remedy ITSM
change ticket parameters that are created when the job definition is completed.

On the Enter approval information dialog or the Approval Information tab, do the
following:
1 Choose the Approval type from the list of pre-defined options:
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.

Timing value of No impact and an Urgency value of Medium.
Emergency approval Use this option for jobs that need immediate attention and must be
run immediately.

Timing value of Emergency and an Urgency value of High.
No approval If you select No approval, you are not required to enter the
additional BMC Remedy ITSM parameters.
If a job type requires approval and you select No approval, the

approval mechanism is bypassed and the job executes either
immediately (Execute now) or as scheduled. This option enables
users with the authorization to select No approval to bypass the
approval process for special circumstances.
The Job Approval type defines what values must be populated in the change
request by the BMC Remedy ITSM user.
2 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 BladeLogic 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 as part of the BMC Continuous Compliance for Server Automation
solution, the categorization tiers are set automatically.
4 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.
Verifying the job

Once the job definition is completed, BMC BladeLogic 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 BladeLogic
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 by completing the following tasks:
1 Select the job from the Jobs folder.
2 Right-click and select Open.
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)
Once the job starts executing after approval the information in the job schedule log is
rolled into job log.
NOTE
If any of the following conditions exist, then the job schedule is terminated and an error
message is logged in the BMC BladeLogic 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
Special considerations for jobs with multiple users

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.
Considerations for the Using existing Change Ticket option

If you choose the Using existing Change Ticket option on the Approval information
tab, note that the Change ID can be from:
an already approved but unused Change ticket or a
a change ticket where the task has the operational categorizations required for
approval in BMC Remedy ITSM. In this case, make sure that the task has the
following organizational tiers:
Organizational tier 1: Operator Initiated Change

Organizational tier 2: BMC BladeLogic

This setting is required for BMC Atrium Orchestrator to recognize that the alert is for
the operator-initiated change scenario. If you are using the change template and task
template installed by the BMC Atrium Orchestrator Content Installer, then the values
are set by default.

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 jobs.
When jobs are executing in the background, you can close the BMC BladeLogic
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.
For information about running other operations in the background, such as adding
packages to the Depot, see Running operations in the background on page 67.
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 Tasks in Progress view provides the following information:
ProgressProgress bar shows how much of the job or task has executed.
ActivityStatus of the job or task. This column provides values such as Running,
Cancel Pending, Completed Successfully, Completed With Errors, and Completed
With Warnings.
Start TimeTime when the job began.
NameName of the job that is executing.
TypeType of job.
UserUser who executed the job.
RoleName of the role of the user who executed the job.
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 approvalWhen 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.
There are additional statuses possible if BMC BladeLogic is configured to integrate

with BMC Remedy ITSM. See Viewing job run information through an Execution
Task on page 436 for more information.
Host Name(Provision Job only) Name of the host on which the job is executing.
Device Type(Provision Job only) The provisioning technology being used to provision
the servercan be PXE, JumpStart, or NIM.
Device Description(Provision Job only) Description of the device being provisioned.
With the Tasks in Progress view you can perform the following procedures:
Canceling jobs in progress

Closing the Tasks in Progress view
Canceling jobs in progress

Use this procedure to cancel one or more jobs in progress.
NOTE
To cancel any job, a role must be granted both Read and Cancel permissions for that type of
job. For example, to cancel a Deploy Job, your role must be granted DeployJob.Cancel and
DeployJob.Read.
1 Select one or more jobs listed in the Tasks in Progress view. Use Shift-click or
Control-click to select multiple tasks.
2 Click Cancel .
Closing the Tasks in Progress view

Use this procedure to show or hide the Tasks in Progress view, which lets you cancel
and view information about jobs in progress.
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.
To hide the Tasks in Progress view, choose Close on the tab or right-click the Task
in Progress view tab and choose Close.

Using Execution Tasks to manage job runs
Using Execution Tasks to manage job runs

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 and choice of target servers 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
NOTE
Execution Tasks are not relevant and are not available for the following types of jobs: Atrium
Import Job, Provision Job, Upgrade Model Objects Job, Virtual Guest Job, and Virtual
Infrastructure Discovery Job. Advanced Deploy Jobs are also not supported by Execution
Tasks.
Depending on how you want to use an Execution Task, you can choose from the
following tasks:
Creating an Execution Task while executing a job against failed targets

Creating and defining an Execution Task manually
Modifying Execution Task definitions
Executing a job through an Execution Task
Viewing job run information through an 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, as described in Executing a job against failed targets on page 419.
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.

NOTE
authorization.
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 (as described in Modifying Execution Task
definitions on page 435).
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
runsthe 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.

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 and
choose target servers 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.
NOTE
authorization.
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 In the General panel of the Create New Execution Task wizard, enter a name and
(optionally) a description for the Execution Task.
3 To select a job with which to associate the Execution Task, click Browse beside
the Job Selection field, and select a job in the displayed dialog box. Then click Next.
If you accessed the Create New Execution Task wizard through a specific job, that
job already appears as the associated job.
4 In the Targets panel select any number of target servers for the Execution Task, and
transfer them from the list of available servers to the list of selected servers using
the right arrow. Then click Next.
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.
5 In the Schedules panel, define any number of schedules for the Execution Task in
the list of schedules, and then click Next. 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.
Schedule
Schedule Servers
Delete an existing schedule by selecting it in the list and clicking Remove

Schedule .

6 The Properties panel shows 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. For more information on assigning property values, see
The default list of properties assigned to an Execution Task is determined by the

Execution Task built-in property class in the Property Dictionary. If necessary, you
can use the Property Dictionary to create new properties. For more information,
see Using the Property Dictionary on page 118.
7 In the Permissions panel, define permissions for the Execution Task.
The Permissions panel is an access control list granting roles access to the
Execution Task. 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 186.
NOTE
If you grant ExecutionTask.Execute to a role so that the role can execute this Execution
Task, you must also grant that role ExecutionTask.Read. You cannot execute an Execution
I Task without being able to read the Execution Task.
8 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.
Schedule
NOTE

yyyy/mm/dd format.
(00:00 to 23:59).

to 23:59).

notifications.

to choose a server.
Schedule Servers
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.
1 Click the Schedule Servers tab.
2 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.


Use this procedure to modify an existing Execution Task.
NOTE
To perform this procedure you must 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.
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 General, Targets, and Schedules panels as tabs
(rather than wizard windows, as when creating a new Execution Task).
Continue defining Execution Task settings as described in Creating and
defining an Execution Task manually on page 430.
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 .
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. For more information, see
Properties, Permissions, and Audit Trail tab group on page 98.
2 Click Save to save your revisions to the 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.
When you want to execute an Execution Task immediately rather than wait for the
next scheduled execution, you can choose between the following options.
NOTE
To perform this procedure you must have, at minimum, Read and Execute authorizations not
only for the job (for example, AuditJob.Read and AuditJob.Execute), but also for the Execution
Task (ExecutionTask.Read and ExecutionTask.Execute).
To execute the job against all target servers defined in the Execution Task, even
those targets where the job already completed successfully, perform one of the
following procedures:
Navigate to the Execution Task in the Jobs folder, right-click it, and select
Execute.
Right-click the Execution Task and select Show Results. Then right-click the
Execution Task in the root node and select Execute.
To execute the job only against target servers where previous job runs have not
completed successfully, perform one of the following procedures:
Navigate to the Execution Task in the Jobs folder, right-click it, and select
Execute Against Failed Targets.
Right-click the Execution Task and select Show Results. Then right-click a failed
job run under the Execution Task and select Execute Against Failed Targets.

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, 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. Selecting a job run displays basic information about the job run, as
displayed for job runs under expanded jobs. This information appears in tabular form
on the 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 Paging Options setting in the Preferences dialog box, with a default value of
50. If more job runs exist, a Next Page arrow is displayed at the end of the list or a Previous
Page arrow is displayed at the beginning of the list. You can double-click these arrows to
display the next or previous group of job runs. You can also right-click the arrow and choose
from additional options (First Page, Next Page, Previous Page, Last Page, or Jump To Page).
Selecting the Execution Task in the root node displays 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:
Namethe name of the target server

Statusthe overall current status of job at this target server
Next Schedulethe next 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 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, a Next Page arrow is
displayed at the end of the list or a Previous Page arrow is displayed at the beginning of the
list. You can double-click these arrows to display the next or previous group of servers. You
can also right-click the arrow and choose from additional options (First Page, Next Page,
Previous Page, Last Page, or Jump To Page).
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, 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.
If you prefer to completely delete the job run from the job, right-click the job run and
select Delete.


Use this procedure 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 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

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 can give you a sequential
view of all jobs run on a server. It also lets you view a jobs definition (see Viewing
the job definition of a job run on page 441) and all log messages pertaining to each
job run (see Viewing job logs on page 441).
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.

Once 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.
Checking job status

Use this procedure to check the status of a job that has been submitted for execution.
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.
Green - Completed Successfully

Yellow - Completed with Warnings
Red - Completed with Errors
Viewing job status 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).
Applicable status types for jobs configured for BMC

Remedy ITSM approval
When you display job results, an approved schedule is shown with the yellow
Completed with Warnings icon. Failed schedules are displayed with the red Completed
with Errors icon.

Viewing job status for change management approval jobs
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 The change request has been approved in BMC Remedy
for schedule ITSM, and job 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
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 BladeLogic 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 BladeLogic 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
at a later time. If the change request remains in a Rejected or Canceled state after the job
schedule expires, the job will not be executed and the change request will be closed.
When a job that requires approval in Waiting for Approval status is cancelled (for example,
the job is canceled due to time-out), the BMC Remedy ITSM change request is
automatically closed.
Example scenario
An operator in the IT operations organization is using BMC BladeLogic 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
BladeLogic has been notified, the job is executed.

Use this procedure to display the definition of a job that has been run. All data
displayed in a job definition is read-only.
Audit Results or Snapshot Results tab to navigate to a job. Expand the job to
display the job runs.
Activity tab to display the job runs (see Viewing job activity on page 438).
Open the Jobs folder, navigate to a job, right-click the job and select Show
Results to display its job runs.
2 Select a run of a job, right-click, and select Show Job from the pop-up menu.
A window displays the job definition that was used to generate the job run.
3 Select tabs on the window to display different panels.
Viewing job logs

Use this procedure to show the messages generated by a job. With this procedure you
can view all messages generated for an entire run of a job or only those messages
pertaining to a specific server. You can filter the log to show specific types of job
results. You can also see the servers on which a job ran and whether the job succeeded
on those servers.

Exporting job logs
2 Select a run of a job, right-click, and select Show Log from the pop-up menu.
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 on
the left.
The list of messages on the right displays only messages related to the selected
server.
5 To display messages in a dialog that allows you to scroll through messages one by
one, double-click on a message. The Log Item Details dialog opens. Click the Up
arrow or the Down arrow to scroll through messages one by one. Click Close to
close the dialog.
6 Click Close to close the log messages window.
Exporting job logs

Use this procedure to export the log generated by a job. Logs are exported in CSV
format so you can easily import their contents into spreadsheets and databases.

Viewing job schedules
2 Select a run of a job, right-click, and select Export Log from the pop-up menu.
The Export Results dialog 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 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.
Viewing job schedules

Use this procedure to see a list of jobs scheduled for execution. If you are logged in as
BLAdmin, you can see all jobs for all roles in the BMC BladeLogic system. Otherwise,
you see the jobs for which your role has Read permission. The job list shows the job
name, type, schedule, next run time, and the role and user who executed the job.
Select Configuration => Job Schedules View. A list of scheduled jobs is displayed,
containing all currently scheduled jobs that you have permission to see.
Avoiding problems with hung jobs

BMC BladeLogic provides the following procedures, which can help you avoid or
resolve problems that may occur when a job encounters an unresponsive or
unlicensed server:
Defining time-outs for jobs

Updating server status before running a job


Use this procedure to define time-out values for jobs or parts of jobs. 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. 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 (see
Overriding job part time-out behavior on page 445). You can also set a value for
how long the canceling of a job part should take (see Specifying a maximum time for
canceling a job part on page 445).
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 processing of a job part never requires more than two minutes, you might set the
job part time-out to be five minutes. For a description of how jobs are divided into job
parts, see Managing jobs in progress on page 427.
In the Jobs folder, navigate to a job, right-click the job and select Show Results.
2 Right-click the job and select Properties from the pop-up menu. The job displays in
a tabbed window, where 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 that should elapse
before the job is automatically canceled.

NOTE
Be aware of the following when applying job-level time-outs:
Job-level time-outs only apply to scheduled jobs. (Jobs that are set to run
immediately are also considered scheduled jobs.)
In the case of Batch Jobs, only the Batch Job itself can be scheduled. BMC BladeLogic
ignores job-level time-outs set for member jobs that make up a Batch Job.
In the case of 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 that should
elapse before a job part is canceled.
5 Click OK or Finish to close the job.
Overriding job part time-out behavior

If you are assigning job part time-outs, the job part is canceled when it exceeds the
time period you have defined in the JOB_PART_TIMEOUT property. 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 for the Application Server. For more
information on configuring the Application Server, see the BMC BladeLogic Server
Specifying a maximum time for canceling a job part

You can specify a maximum period of time (in minutes) that can elapse for a job part
to be canceled. If cancellation of a job part exceeds this maximum, the entire job is
canceled. This option prevents situations where cancellation of a job is not
performing as expecting 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 for the Application Server. For more
information on configuring the Application Server, see the BMC BladeLogic Server


Use this procedure to update server status information before running a job.
Performing this procedure can prevent problems that a job might encounter because
of an unresponsive or unlicensed server. It also allows you to manually take a server
off line so no jobs can run against the server.
This procedure includes two approaches for updating server status:
Manually setting the IS_ONLINE property to False. This explicitly sets the servers
status. Using this capability, any user can specify that a server is unavailable for
jobs.
Running a script that updates the latest information about agents. The script
obtains a value for the AGENT_STATUS property, which is an intrinsic, read-only
property that can have one of the following values:
agent is alive
agent not licensed
agent not responding
If you run any job (except a Deploy Job) against a server that is off line (that is, either
the IS_ONLINE property is set to False or the AGENT_STATUS property is not set to
agent is alive), the job can have three results:
Success
Failure
Success with warnings, which means the job has succeeded on some servers but
encountered other servers that are not accessible.
When a Deploy Job runs against one or more servers that are off line, the job fails.
Using the IS_ONLINE and AGENT_STATUS server properties, you can create a
smart group (see Defining a smart group on page 92) consisting only of live
servers. Then you can define jobs to run against that smart group.
1 Update the status of servers by doing one or both of the following:
If you want to specify individual servers that should not be included in a job, set
the IS_ONLINE property for those servers to False.
For more information on setting properties, see Setting values for system object
Run the update-server-agent-status.nsh script by doing the following:

A Generate a user information file for the BMC BladeLogic command line
interface. For a description of this procedure, see the BMC BladeLogic Installation
Guide.
B From a command line, start Network Shell.
C Invoke the update script by entering the following:
./update-server-agent-status.nsh -m all|group|list name
In the command shown above:
all indicates that all servers are updated. For example:
./update-server-agent-status.nsh -m all
group requires the name of a server group, such as:
./update-server-agent-status.nsh -m group WindowsOnline
list requires a colon-delimited list of servers to be updated, such as:
./update-server-agent-status.nsh -m list serv1:serv2:serv3


Chapter
11
11 Snapshot Jobs
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 BladeLogic and external changes and back out the
changes (see Differentiating between internal and external changes on page 468).
Display the deploy jobs that may have produced the BMC BladeLogic changes (see
Showing deploy activity on page 469).
Bundle snapshot results into a BLPackage or software package (see Bundling

snapshot results into a BLPackage on page 469).
Export the snapshot and change tracking results (see Exporting the results of an
audit or snapshot on page 472).
For more information on defining Snapshot Jobs, see Creating Snapshot Jobs on
page 452. For information on modifying an existing Snapshot Job, see Modifying
Snapshot Jobs on page 465. For more information on using the results of a Snapshot
Job, see Viewing snapshot and change tracking results on page 466.

Snapshot and audit basics
For more information on tracking changes, see Viewing snapshot and change
tracking results on page 466. For more information in differentiating between
changes made by BMC BladeLogic and external changes, see Differentiating
between internal and external changes on page 468. For more information on
removing changes, see Backing out of changes on page 468.
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. For information on managing and organizing jobs, see Chapter 10,
Managing jobs.
Snapshot and audit basics

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 BladeLogic, 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. See Running Snapshot Jobs and Audit Jobs on
hosts on page 595.
Symbolic links
When taking snapshots or performing audits, BMC BladeLogic supports symbolic
links at the top level of the file system. In other words, 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 BladeLogic 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 BladeLogic 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
Snapshot storage
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 generally saved in the database. Snapshots of file systems,
however, can contain actual content. Content is saved in the file server. The following
table describes where snapshot information is stored. All component machines in a
BMC BladeLogic system should have their clocks synchronized.
Object Location Saved

.NET Global Assemblies database
applications, packages, patches, RPMs, database
bundles, and products
COM+/MTS database; values longer than 255 characters
are stored in the file server
components server objects that constitute the component
are stored in the location appropriate for that
server object
configuration files database
daemons database
event logs database
extended object database
file system file attributes are stored in the database; file
content is stored in the file server
hardware information database
hotfixes database
local groups database
local users database
metabase database; values longer than 255 characters
processes database
registry database; values longer than 255 characters
security settings database
services database
system info database
UNIX groups database
UNIX users database

Creating Snapshot Jobs
Creating Snapshot Jobs

Use this procedure to define a Snapshot Job, which specifies that the system take a
snapshot of components or specific server objects on different servers or the same
server. By taking a snapshot, you make a record of a servers configuration at a point
in time.
See Modifying Snapshot Jobs on page 465 for information on modifying an existing
Snapshot Job.
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.
Open the Components or Component Templates folder and select a component.

Right-click and select Snapshot from the pop-up menu.
New => Snapshot Job from the pop-up menu.
The New Snapshot Job wizard opens.
2 Define the Snapshot Job, as described in the following sections:
General
Components Templates for Filtering
Server Objects
Targets
Schedules
Properties
Permissions
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.

General
1 For Name, enter an identifying name for the Snapshot Job. For Description, you can
2 For Save in, identify the job folder where you want to store this Snapshot Job by
click OK.
3 Under Select Snapshot Job Type, select one of the following:
Snapshot componentsChoose the component templates that form the basis of

the Snapshot Job. The snapshot records information for all components
(specified using templates) which are discovered on the target servers you
specify.
Snapshot server objectsDefine a Snapshot Job based on server objects selected

from live servers. Using those selections, the snapshot is taken of target servers
you specify.
managed servers.


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 have been 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.
In the Available Templates list on the left, select the component templates you want
to base the snapshot on and click the right arrow, which moves your selections to the
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.
The Server Objects panel asks you to provide the following categories of information:
Server Objects
Snapshot/Audit Options
Server Objects
The Server Objects list lets you choose server objects that form the basis of a Snapshot
Job.
With the Server Objects list, you can add new server objects and modify or delete
existing server objects.
The Server Objects list lets you select any version of a custom configuration object,
Object Dictionary.
1 Using the Server Objects list, add a new server object by clicking Add or modify
an existing server object by selecting it and clicking Update . The Select Server
Objects window opens.
To delete an existing server object, select it in the Server Objects list and click Delete
.

Server Objects
2 Using the server tree on the left, choose a server object that should be included.
Use Control-click or Shift-click to select multiple objects. Click the right arrow to
move your selections to the right panel.
expand the tree and select the directories or individual items you want.
, which displays the New Server Object dialog. From Type, select the server
object type you want to add. For Name/Path, either enter the path to the server
object or click the browse button and navigate to the server object you want to add.
Then click OK. The path and object type you specify appear in the Selected Server
Objects list on the right. For a discussion of the rules that apply when entering
paths to server objects, see Rules for entering paths on page 47.
3 Click OK to close the Select Server Objects window. The server objects you have
defined appear in the Server Objects list.
4 If you are adding hierarchical server objects such as directories to the Server
Objects list, 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.
server object you have selected in the Server Objects list.
NOTE

The Includes/Excludes section of the Server Objects panel lets you specify server
objects that should be included or excluded from a Snapshot Job. For example, you
might want to exclude all log files or backup files in a directory. You can include or
exclude software objects, such as packages or hotfixes, and any of the following types
of hierarchical server objects:

COM+
Metabase
Registry

Server Objects
as [a-z].

current directory
three characters
extension
web
are excluded.

Server Objects
To include or exclude server objects from a Snapshot Job, select a server object in the
Server Objects list and do one of the following in the Includes/Excludes section:

For Name, enter a path to the server object you want to include or exclude,

6 Click OK.
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.
1 To specify information that should be collected during a snapshot, select an object

in the Server Objects list.
2 Using the Snapshot/Audit Options section, check the Snapshot column to select
any of the following attributes:
ACL Owner - Store the owner of a file or registry key.

Targets
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
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.
Inherit Auditing ACL - 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.
Inherit Permission ACL - 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.
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 templates, the job will take 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. If you 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.

If you are basing a snapshot on server objects, the job will take 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.
1 From Available Targets, select the targets by doing any of the following:
Select a server group to select all servers within the group.

Select one or more servers, if necessary expanding server groups.
Select a component group to select all components within the group.
Select one or more components, if necessary expanding component groups or
The Default Notifications panel lets you send email messages and generate SNMP
traps when a job completes. 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 (see
Scheduled Job Notifications on page 463).
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.

to choose a server.
4 To send email notifications when any changes to the snapshot occur, under
Snapshot Change Notifications, do the following:
notified when the Snapshot Job has a change status that you specify in the next
step. Separate multiple email addresses with semicolons, such as
B For When results are, check the job statuses that determine whether an email
should be generated. You can select a status indicating changes occurred, did
not occur, or both.
C To include the snapshot changes in the email, check Append snapshot change
results to email.
D To limit the size of the email that is generated by appending snapshot changes,
check Limit email body size to and then enter a maximum, in kilobytes, in the text
box to the right.
5 To send SNMP trap notifications when any changes to the snapshot occur, under
should be notified when the job has a change status that you specify in the next
step. Alternatively, you can click the browse button and use the Select Server
dialog to choose a server.
B For When results are, check the job statuses that determine whether an SNMP
trap should be generated. You can select a status indicating changes occurred,
did not occur, or both.

Schedules
Schedules
recurring basis.
Execute job now.
information:
Schedule
4 When you finish entering information on the Add New Schedule window, click
OK.
Schedule

Schedules
NOTE
yyyy/mm/dd format.
(00:00 to 23:59).

to 23:59).

Schedules

The Scheduled Job Notifications tab lets you generate emails and SNMP traps when a
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.
to choose a server.
4 To send email notifications when any changes to the snapshot occur, under

Properties
notified when the Snapshot Job has a change status that you specify in the next
step. Separate multiple email addresses with semicolons, such as
B For When results are, check the job statuses that determine whether an email
should be generated. You can select a status indicating changes occurred, did
not occur, or both.
C To include the snapshot changes in the email, check Append snapshot change
results to email.
D To limit the size of the email that is generated by appending snapshot changes,
check Limit email body size to and then enter a maximum, in kilobytes, in the text
box to the right.
5 To send SNMP trap notifications when any changes to the snapshot occur, under
should be notified when the job has a change status that you specify in the next
step. Alternatively, you can click the browse button and use the Select Server
dialog to choose a server.
B For When results are, check the job statuses that determine whether an SNMP
trap should be generated. You can select a status indicating changes occurred,
did not occur, or both.
Properties
The Properties panel shows a list of properties automatically assigned to a Snapshot
Job. You can modify the value of any properties in this list that are defined as
The default list of properties assigned to a Snapshot Job is determined by the Job
Property Dictionary on page 118).

Permissions
Permissions
The Permissions panel is an access control list granting roles access to this Snapshot
NOTE
If you grant SnapshotJob.Execute to a role so that the role can execute this job, you must also
grant that role SnapshotJob.Read. You cannot execute a job without being able to read the job.
Modifying Snapshot Jobs

Use this procedure to modify an existing Snapshot Job.
To modify the definition of an existing Snapshot Job, open the Jobs folder and
General
Server Objects
Targets
Schedules
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 displays 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.

page 98.

Viewing snapshot and change tracking results

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.
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.
Using snapshot results, you can perform the following tasks:
Differentiate between BMC BladeLogic and non-BMC BladeLogic changes. (See

Differentiating between internal and external changes on page 468.)
Back out of undesired changes. (See Backing out of changes on page 468.)
Show the deploy jobs that can cause the change. (See Showing deploy activity on
page 469.)
Export some or all of the results of a snapshot or change tracking into HTML or
CSV format. (See Exporting the results of an audit or snapshot on page 472.)
Bundle the results as a BLPackage. (See Bundling snapshot results into a

BLPackage on page 469.)
View file properties and ACL information for files on servers using Windows
NTFS by double-clicking the file. (See Viewing server objects on page 234.)
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.
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
At the server view level, Change Tracking displays the component names, the
external changes, the number failed changes, the number of changes 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 server view component level, Change Tracking displays 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 server view component parts/Delta information level, Change Tracking displays
the 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.

Differentiating between internal and external changes
Items in blue indicate 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.
Items in red indicate 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.
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.
Differentiating between internal and external changes

BMC BladeLogic attempts to differentiate between changes caused by BMC
BladeLogic 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 BladeLogic activities or by external actions. However, if no BMC
BladeLogic activities have occurred during the period, the changes detected are
considered external changes.
If BMC BladeLogic 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
activity on page 469) 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.
Backing out of changes

Not all changes are desirable. You may recognize that a specific change has a negative
impact on performance or may have been deployed at an inappropriate time. The
system lets you remove external changes or all changes, depending upon where the
changes have been made.
Do one of the following:
At the server level, right-click the server and select Back Out All Changes or Back
Out All External Changes.

Viewing the changes using the Compare Editor
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 the changes using the Compare Editor

You can compare file assets in a current snapshot with file assets in a previous
snapshot to see changes using the Compare Editor. The changes are color coded to
make them easier to identify. Just right-click the Snapshot result and select Compare.
Showing deploy activity

The changes that occur between snapshots may be caused by BMC BladeLogic or
external activity. If there was no deploy activity during the period, you know that it
was an external change.
You can view the Deploy Jobs that have caused the changes reported on the Change
Tracking tab. This feature displays the associated File Deploy Jobs, NSH Script Jobs
and Deploy Job Attempts that might have caused the changes detected by the current
Snapshot run.
To view the jobs that may account for the change, select the Server view, Server view
component, Server view component part, or delta asset level, right-click and choose
Show Deploy Activity.
Bundling snapshot results into a BLPackage

Use this procedure to bundle snapshot results 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.
1 Use the Jobs folder to display the results of a snapshot, as described in Viewing
snapshot and change tracking results on page 466.
2 Expand the results of a job run.
3 Expand the Server View node and do one of the following:

Bundling snapshot results into a BLPackage
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 displays. Proceed to
step 4.
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
displays. Proceed to step 4.
Bundle the contents of everything 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. For more
information on using this wizard, see Adding a BLPackage to the Depot on
page 375.
4 If the package includes software that does not match software stored in the depot,
the Select Matching Software window displays. 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 373.
Package Type
Package Options
Package Type
The Package Type panel asks you to name the package and specify where to store it.
1 For Package Name, enter a name for the BLPackage you are creating.
2 For Save in, click Browse and navigate to the depot group where you want to
store the BLPackage.
Package Options
Package Options panel lets you make choices about how to create a BLPackage.

Adding software to the depot from snapshot results


2 Under Registry Options, check Collect access control list (ACL) attributes to
instruct the BLPackage to gather ACLs for Windows registry entries.
their dependencies.
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.
1 Use the Jobs folder to display the results of a snapshot, as described in Viewing
snapshot and change tracking results on page 466.
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 displays.
5 Use the window to add software to the Depot. For more information, see the
following:
Adding a hotfix to the Depot on page 365, a procedure specifically for adding
Windows patches and service packs to the Depot

Exporting the results of an audit or snapshot
Adding software to the Depot on page 353, a generalized procedure for

adding all other types of software

Use this procedure to export the results of an audit or snapshot. For snapshots, you
can exports the results of the snapshot and change tracking. 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 are exporting 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
pick a server object, such as Registry, all server objects of that type are exported. If
you pick a particular server object, such as a file directory or a registry hive, the
contents of that server object are exported.
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, as described in Viewing audit results by server on page 495.
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 displays.
4 On the dialog, 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.
6 On the Export Results dialog, click Save.


Chapter
12
12 Audit Jobs
Using Audit Jobs, you can determine whether server configurations match a standard
configuration.
Audit Jobs share some basic functionality with Snapshot Jobs. For a description of
this core functionality, see Snapshot and audit basics on page 450.
For more information on defining Audit Jobs, see Creating Audit Jobs on page 475.
For information on modifying an existing Audit Job, see Modifying Audit Jobs on
page 491. For information on using the results of an audit, see any of the following:
Viewing audit results

Grouping non-compliant servers
Using audit results to synchronize servers
Packaging audit results
Audit Jobs are stored in the Jobs folder. For information on managing and organizing
jobs, see Chapter 10, Managing jobs.
Creating Audit Jobs

Auditing allows you to compare components, servers, or snapshots to determine
whether their configurations match a standard configuration. With audits you can
quickly identify discrepancies between server configurations. When you identify
discrepancies, you can bundle the necessary changes into a BLPackage and deploy
those 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.

Creating Audit Jobs
Performing an audit requires 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.
After you run an Audit Job, you can use audit results to do any of the following:
View the results of the audit. (For more information, see Viewing audit results
on page 492.)
Synchronize a server so its configuration matches the master server. (For more
information, see Using audit results to synchronize servers on page 499.)
Export some or all of the results of the audit. (See Exporting the results of an audit
or snapshot on page 472.)
See Modifying Audit Jobs on page 491 for information on modifying an existing
Audit Job.
1 To create a new Audit Job, do one of the following:
Open the Server folder and select a server. Right-click and select Audit from the
pop-up menu.
Open the Components or Component Templates folder and select a 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 from
the pop-up menu.
The New Audit Job wizard opens.
2 Define the Audit Job, as described in the following sections:
General
Masters
Server Objects
Targets
Schedules
Properties
Permissions
3 Click Finish after completing the last step of the wizard, or click OK to save your
revisions to an existing job.

General
General
The General panel lets you provide information that identifies an Audit Job. It also
lets you select the approach to defining the auditby selecting components or live
server objects. If you audit by component, the system audits all components
discovered on the targets you specify that match the templates you select.
1 For Name, enter an identifying name for the Audit Job. For Description, you can
2 For Save in, identify the Job folder where you want to store this Audit Job by
click OK.
3 Under Select Audit Job Type, select one of the following:
Audit componentsThe Audit Job is based on components.
Audit server objectsThe Audit Job is based on live server objects that you select
from a master (either a snapshot or a server).
managed servers.

Component Templates for Filtering

The Component Templates for Filtering panel lets you choose the component
templates that form the basis of an audit. The Component Templates for Filtering
panel is only available when you are defining an Audit Job based on components.
1 In the Available Templates list on the left, select the component templates you want
to base the audit on and click the right arrow, which moves your selections to the
Masters
When an audit is based on components, 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 defining an Audit Job based on
components.
For each component template listed in the Masters list, do the following:
1 Select a component template and click Update .
The Select Master dialog opens for the selected entry. The dialog 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 the 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.
3 Click OK. The Master Entries list shows the master you have selected.

Server Objects
Server Objects
The Server Objects panel lets you choose a server or snapshot that functions as a
master and the server objects on the master that you want to audit. You can also
refine the information included in an audit by excluding server objects and
identifying additional types of information that should be included in the audit.
The Server Objects panel asks you to provide the following categories of information:
Master
Server Objects
Master
The Master option lets you choose the mastereither a live server or snapshoton
which you are basing the audit. After choosing a master, you can select the server
objects you want to audit.
1 For Master, click Browse . The Select Master dialog opens. Use it to select a live
server or snapshot on which you want to base an audit. Then click OK.
Server Objects
The Server Objects list lets you choose the server objects that should be audited. 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.
1 Using the Server Objects list, add a new server object by clicking Add or modify
an existing server object by selecting it and clicking Update . The Select Server
Objects window opens.
To delete an existing server object, select it in the list and click Delete .
2 Using the server tree on the left, choose a server object that should be included.
Use Control-click or Shift-click to select multiple objects. Click the right arrow to
move your selections to the right panel.
expand the tree and select the directories or individual items you want.

Server Objects
, which displays the New Server Object dialog. From Type, select the server
object type you want to add. For Name/Path, either enter the path to the server
object or click the browse button and navigate to the server object you want to add.
Then click OK. The path and object type you specify appear in the Selected Objects
list on the right. For a discussion of the rules that apply when entering paths to
server objects, see Rules for entering paths on page 47.
3 Click OK to close the Select Server Objects window. The server objects you have
defined appear in the Server Objects list.
4 If you are adding hierarchical server objects such as directories to the Server
Objects list, 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.
server object you have selected in the Server Objects list.
NOTE

The Includes/Excludes section of the Server Objects panel lets you specify some
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. You can include or
exclude software objects, such as packages or hotfixes, and any of the following types
of hierarchical server objects:

COM+
Metabase
Registry

Server Objects
as [a-z].

current directory
three characters
extension
web
are excluded.
1 To include or exclude server objects from an audit, select a server object in the
Server Objects list and do one of the following:

For Path, enter a path to the server object you want to include or exclude,

Server Objects

3 Click OK.
The Snapshot/Audit Options section of the Server Objects panel lets you specify
information associated with server objects 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.
1 To specify information that should be compared during an audit, select an object in

the Server Objects list.
2 Using the Snapshot/Audit Options section, check the Audit column for any
attribute that should have snapshot or audit functionality enabled.
The following list describes user-selectable attributes for built-in server objects.
This list describes some of the more important attributes as well as attributes with
names that may not completely describe their function. There are many additional
attributes that you can select.
ACL Owner - Compare the owner of a file or registry key.

Server Objects
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
file and use that key to compare entire files and detect changes that occur
anywhere in a file. Computing full checksums requires significant processing.
Contents - Compare file content when performing an audit based on a snapshot

of file content.
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.
each server.

Targets
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.
Size - Compare the sizes of files.
Version - Compare file version information for DLL, EXE, and other types of
files.
Targets
The Targets panel lets you identify the servers, server groups, components,
component groups, or snapshots that should be audited.
If you are basing an audit on component templates, the job will audit 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 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. If you 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.
If you are basing an audit on server objects, the job will audit 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.

Using the Components folder, select one or more servers. Select a component
group to select all components within the group.
Using the Component Templates folder, navigate to a component template,

expand the component template, and select one or more components.
Using the Servers folder, select one or more servers. Select a server group to
select all servers within the group.
Using the Jobs folder, navigate to a Snapshot Job, expand the job, expand a run
of the Snapshot Job, and select one or more snapshots.
occurrence.
The Default Notifications panel also lets you define email messages and SNMP traps
that are generated based on the results of the Audit Job. You can send notifications
when targets have consistent configurations, inconsistent configurations, or both.

to choose a server.
4 To send email based on audit results, do the following:
A Under Audit Results Notifications, check Send Email to and enter the email
address of the accounts that should be notified about audit results. Separate
addresses with a space.
B For When results are, specify the type of audit results that should trigger an email
by checking Consistent, Inconsistent, or both.
C To include audit results in the email, check Append audit results to email.
D To limit the size of the email that is generated by appending audit results, check
Limit email body size to and then enter the maximum, in kilobytes, in the text box
to the right.
When a job completes, an email, which can potentially contain audit results, is sent
to the designated accounts.
5 To generate an SNMP trap based on audit results, check Send SNMP Trap to and
then enter the name or IP address of the server that should be notified when the job
completes with a status that you specify. Alternatively, you can click the browse
button and use the Select Server dialog to choose a server.
6 Specify the audit result status that determines whether an SNMP trap should be
generated by checking Consistent, Inconsistent, or both.
For example, if you select Inconsistent and an audit indicates that two server object
types are inconsistent, an SNMP trap is sent.
read using software that can receive and interpret SNMP trap.

Schedules
Schedules
recurring basis.
Execute job now.
2 Using the Schedules list, add a new schedule by clicking Add , or modify an
existing schedule by selecting it and clicking Update . The Add New Schedule
window opens.
To delete an existing schedule, select it in the list and click Delete .
Schedule
4 When you finish entering information on the Add New Schedule window, click
OK. The new schedule displays in a list on the Schedules panel.
Schedule

Schedules
NOTE
yyyy/mm/dd format.
(00:00 to 23:59).

to 23:59).

Schedules

job completes.
The Scheduled Job Notifications tab also lets you define email messages and SNMP
traps that are generated based on the results of the Audit Job. You can send
notifications when target components have consistent configurations, inconsistent
1 Click the Default Notifications tab. To send email notifications, under Job Run
Notifications, do the following:
to choose a server.
4 To send email based on audit results, do the following:

Properties
A Under Audit Results Notifications, check Send Email to and enter the email
address of the accounts that should be notified about audit results. Separate
addresses with a space.
B For When results are, specify the type of audit results that should trigger an email
by checking Consistent, Inconsistent, or both.
C To include audit results in the email, check Append audit results to email.
D To limit the size of the email that is generated by appending audit results, check
Limit email body size to and then enter the maximum, in kilobytes, in the text box
to the right.
When a job completes, an email, which can potentially contain audit results, is sent
to the designated accounts.
5 To generate an SNMP trap based on audit results, check Send SNMP Trap to and
then enter the name or IP address of the server that should be notified when the job
completes with a status that you specify. Alternatively, you can click the browse
button and use the Select Server dialog to choose a server.
6 Specify the audit result status that determines whether an SNMP trap should be
generated by checking Consistent, Inconsistent, or both.
For example, if you select Inconsistent and an audit indicates that two server object
types are inconsistent, an SNMP trap is sent.
read using software that can receive and interpret SNMP trap.
Properties
The Properties panel shows a list of properties automatically assigned to an Audit
The default list of properties assigned to an Audit Job is determined by the Job built-
in property class in the Property Dictionary. If necessary, you can use the Property
Dictionary to create new properties. For more information, see Using the Property
Dictionary on page 118.

Permissions
Permissions
The Permissions panel is an access control list granting roles access to this Audit Job.
NOTE
If you grant AuditJob.Execute to a role so that the role can execute this job, you must also
grant that role AuditJob.Read. You cannot execute a job without being able to read the job.
Modifying Audit Jobs

Use this procedure to modify an existing Audit Job.
To modify the definition of an existing Audit Job, open the Jobs folder and
General
Masters
Server Objects
Targets
Schedule
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 displays 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.

page 98.


Audit results compare the master (which can be a server, snapshot, or component) to
other hosts, including hosts in other snapshots.
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

Viewing audit results by server
Viewing differences between text files
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 View, the 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.
If you expand the Server View, the 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.
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 499.)

Export some or all of the results of the audit. (See Exporting the results of an audit
or snapshot on page 472.)
NOTE
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 Appendix C, Security
settings for Windows 2008, 2003, and 2000 for a complete list of Security Settings with
policy names that differ between operating systems.
To ensure that servers have consistent patch configurations, BMC BladeLogic

recommends you use the systems built-in patch analysis capabilities (see Chapters 19
through 23). 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.
When 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 itself might also be missing the same service pack.

Use this procedure to 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.
1 In the Jobs folder, select an Audit Job, right-click, and select Show Results from the
pop-up menu.
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. Objects with inconsistencies are shown in bold.
The pane on the right of the tab shows summary results for the audit as follows:

Column Description
Name The name of the audit job and the master
server.
Compliant The total number of servers that are
consistent with the master.
Non-compliant The total number of servers that are
inconsistent with the master.
Failed The total number of objects for which the
attempt to evaluate consistency failed on at
least one target.
Not Attempted The total number of objects for which
consistent evaluation was not attempted on
at least one target.
Changes The total number of objects that have
differing characteristics between the master
and at least one target.
Extra The total number of objects that are not
present on the master but are present on at
least one target.
Missing The 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. Note that if you are performing a server-object based audit,
components are named according to the name of the Audit Job.
The pane on the right of the tab shows summary results for the component as
follows:
Column Description
Name The name of the component or Audit Job on
which the audit is based.
# of Consistent Targets The total number of servers for which this
object is consistent with the master.
# of Inconsistent Targets The total number of servers for which this
object is inconsistent with the master.
# of Failed Targets The total number of servers for which the
attempt to evaluate consistency for this object
failed.
# of Not Attempted Targets The 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 pane lists
all the targets for the job and indicates whether they are consistent.

Use this procedure to 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
which files in that directory are inconsistent with the master server.
pop-up menu.
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 Server View node. Objects with inconsistencies are shown in bold.
The pane on the right of the tab shows summary results for the audit as follows:
Column Description
Name The name of the job and the master server.
Compliant The number of objects on all targets that are not compliant
with the master.
Non-compliant The total number of objects that are inconsistent between the
master and at least one target.
Failed The total number of objects for which the attempt to evaluate
consistency failed on at least one target.
Not Attempted The total number of objects for which consistent evaluation
was not attempted on at least one target.
Changes The total number of objects that have differing characteristics
between the master and at least one target.
Extra The total number of objects that are not present on the master
but are present on at least one target.
Missing The 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 tree on the left of the tab lists all of the target
servers. Targets that are consistent for all objects show in a plain black font. Targets
for which there is at least one inconsistency show in a bold black font.

The right panel shows a listing of all the target servers, with columns showing the
following server-level summaries:
Column Description
Name The name of the job and the master.
Changes The total number of objects present on both the master and this
target but for which there are some differences in characteristic
values.
Extra The total number of objects present on this target but not on the
master.
Missing The total number of objects present on the master but missing on
this target.
4 To view a server-level summary of the audit result, expand the tree under a master
and select a target server. The tree on the left of the tab lists all objects participating
in the audit. Objects that are consistent for the server show in a plain black font,
while objects for which there is at least one inconsistency show in a bold black font.
The right panel shows a listing of all objects, with columns showing the following
server-level summaries:
Column Description
Name The name of the object.
Changes If the value is non-zero, the object is present on both the master
and target but there are some difference in characteristic values.
Extra If the value is non-zero, the object is present on this target but not
on the master.
Missing If the value is non-zero, the object is present on the master but
missing on this target.
5 To view the details of 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. Servers and server objects listed in a bold font are inconsistent.
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 detailed information about the differences between an item, select the
item. The detail pane at the bottom shows discrepancies between the selected item
and the master server. Bold red denotes characteristics that differ between the
selected item and the master server.
7 Depending on the type of server objects you are auditing, you may be able to do
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 on
ACLs, seeViewing security information for files and registry keys on
page 235.
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.

Use this procedure to display the differences between a text file on the master and a
target.
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.
pop-up menu. In the content editor, expand an Audit Job, expand a particular run
of the Audit Job, and click the Server View node.
2 Using the Server View, navigate to a node that consists of a file where there are
differences.
When there are differences between master and target, the file name displays in
red in the audit results pane.
3 In the audit results pane, right-click the file and select Compare from the pop-up
menu.

Understanding audit results for configuration files
The Audit Compare window opens. The left pane shows the contents of the file on
the master and the right shows the content of the same file on the target.
Differences between the files are highlighted. The colors used for highlighting are
determined by setting the General => Appearance => Colors and Fonts preference.
For more information, see Customizing preferences on page 73.
A line in the target server indicates where a line was deleted. The master server
shows what was deleted.
A highlighted area in the master and the target shows where something has
been changed.
A highlighted line in the target shows where something has been added.
4 Using the buttons on the Audit Compare window, display the first, last, next, or
previous difference detected between files.
Understanding 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.
Grouping non-compliant servers

Use this procedure to group servers with configurations that do not comply with an
audit. By grouping servers in this way, 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.
1 Display the results of an audit using the Object View, as described in Viewing
audit results by object on page 493.
2 Under the Object View, select a server object included in the audit.

The table on the right side of the tab shows servers with configurations that are not
consistent with the selected server object.
3 Select the servers you want to group. Then, right-click and select Group servers
from the pop-up menu. The Add Servers to Group dialog opens. It shows the
servers you selected in the bottom pane.
4 In the top half of the dialog, 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. (You may need to ensure the focus is in this pane by first clicking on the
Servers icon.)
5 Click OK. The servers shown in the bottom half of the dialog are grouped in the
specified server group.

Use this procedure to synchronize the configuration of audited servers to match the
configuration of the master. 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.
Depending on how you initiate this 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 BladeLogic 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 a single Batch Job so the entire synchronization
can be launched as one job.
1 Display the results of an audit using a Server View, as described in Viewing audit
results by server on page 495.
2 Under the Server View, do one of the following:
Synchronize all target servers by right-clicking the master server and selecting
Sync all targets with master from the pop-up menu.

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 displays.
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 Details
Package Options
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 displays.
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 373.
One of the following occurs:
If you are synchronizing multiple servers and multiple BLPackages or software

packages are being deployed, a New Batch Job wizard displays. The Batch Job is
defined to run all the Deploy Jobs needed to synchronize the target servers. For
more information on modifying or running a Batch Job, see Creating Batch
Jobs on page 579.

Sync Details
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
displays. For more information on modifying or running a Deploy Job, see
Deploying a software package on page 525.
Sync Details
The Sync Details panel asks you to give the job a name and to specify where to store
the BLPackages and jobs the wizard generates.
1 For Sync name, enter a name for the synchronization job. If the job generates a
Batch Job, this name is assigned to the Batch Job.
2 For Save package in, click Browse and navigate to the depot group where you
want to store the BLPackages generated by this procedure.
3 For 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.
Package Options
The Package Options panel lets you make decisions about how to create a BLPackage.



their dependencies.

Use this procedure to create a BLPackage containing the differencesor delta
between 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.
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.
1 Display the results of an audit using a Server View, as described in Viewing audit
results by server on page 495.
2 Under the Server View, do one of the following:
Package all differences for one server by right-clicking the server and selecting
Package Delta.
Package differences for one or more specific audit results by selecting them in
the right pane, right-clicking, and selecting Package Delta.
A wizard for packaging audit results displays.
NOTE
If you are packaging hotfixes, be aware of the following:
When selecting specific hotfixes, you can only select Package Delta when the contents
pane 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 contents
pane 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 Type
Package Type
Package Options
Package Type
The Package Type panel asks you to identify the package.
1 For Package name, enter a name for the BLPackage you are creating.
2 For Save in, click Browse and navigate to the depot group where you want to
save the BLPackage.
Package Options
The Package Options panel lets you make decisions about how to create a BLPackage.


their dependencies.

Package Options

Chapter
13
13 File Deploy Jobs
File Deploy Jobs let you deployor pushmultiple 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) and then use a BLPackage Deploy Job to deploy them (see
Deploying a BLPackage). 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.
For information on creating and running a File Deploy Job, see Deploying files and
directories. For information on modifying an existing File Deploy Job, see
Modifying File Deploy Jobs on page 519.
File Deploy Jobs are stored in the Jobs folder. For information on managing and
organizing jobs, see Chapter 10, Managing jobs.

Deploying files and directories
Deploying files and directories

Use this procedure to create a File Deploy Job.
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 BladeLogic 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 on Windows
user mapping, see Create automation principals on page 149.
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 on configuration files and
mapping users, see the BMC BladeLogic Server Automation Administration Guide.
See Modifying File Deploy Jobs on page 519 for information on modifying an
existing File Deploy Job.
1 To create a new File Deploy Job, do one of the following:
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:
General
Targets
Options

General
Advanced Options
Schedules
Properties
Permissions
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.
clicking Browse . The Select Folder dialog opens. Choose a job folder and click
OK.
3 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 to select a file or directory.
Click Add and use the Add Source File dialog 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.
4 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.
5 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.

Targets
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.
managed servers.
Targets
The Targets panel lets you choose the servers to which files and directories should be
deployed. When first defining and saving a File Deploy Job, you do not have to
specify target servers. You can specify target servers at a later time.

Options

Options
The Options panel lets you provide options that control a file deployment.
The Options panel asks you to provide the following categories of information:
Sync Push
Indirect Push Using Repeaters
Backup Options
Global Deploy Options
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.
1 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.

Options
2 If you selected Sync Push in the previous step, check one or more of the following
options to define criteria that determine which files get copied. You can also use
these options to specify some additional characteristics of a File Deploy Job.
File SizeCopies a source file if its size differs from the size of the target file.
MD5 checksumCopies 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 modifiedCopies a source file if its time and date of last modification
differs from the time and date when the target file was last modified.
PermissionsSynchronizes 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.
OwnershipsSynchronizes 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.
PruneRecursively 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). Once 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 675.

Options
1 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.
2 Use any of the following options to define how the copy should be performed
during an indirect push:
Clean up staging after pushCheck 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 repeatersCheck 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 509. Selecting a synchronized push can
minimize the amount of data carried over the network.
Parallel pushesSpecify 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.
1 Check Backup Options to define backup provisions.
Clearing Backup Options indicates you want to make no backup provisions. By

default, Backup Options is cleared.
2 Select Save with suffix and then, in the Suffix field, enter a suffix such as bak.
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.

Options
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.
3 Select Backup. In the Directory field, enter the directory where a backup of the
target file or directory can be stored. Then, in the Name field, enter a name that
identifies this 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:
/log/June-20-2001/eastwin2k1/15:36:56
directory name host name time stamp
Global Deploy Options

The Global Deploy Options section allows you to define any of the following:
Block-by-block updates of large files
It is not efficient to copy large files that contain only a small number of changes.
BMC BladeLogic allows you to 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.
Minimum amount of disk space
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.

Advanced Options
1 To define global deployment options, do any of the following:
To enable block-by-block updates of large files, do both of the following:
For Min. file 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.
For Update block 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.
To specify a minimum amount of disk space for a destination directory, enter a

value (in kb) for Minimum disk free.
NOTE
Entering a value of 0 for any option in the Global Deploy Options section instructs the system
to ignore that option.
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.

1 To define pre- and post-commands, do any of the following:
For 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 pre-command 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.
For Post-command, enter the command that you want to execute after the job
ends. Post-commands are executed in the target directory. To import the text of
the command, click Browse and navigate to the file containing that text.
If necessary, click Zoom to open a dialog that gives you a larger text box to
edit pre- and post-commands. When you finish editing the command, click OK.
occurrence.

Schedules
to choose a server.
Schedules
recurring basis.
Execute job now.
information:

Schedules
Schedule
Schedule
NOTE
yyyy/mm/dd format.
(00:00 to 23:59).


Schedules
to 23:59).
Execute on approval and Approval type settings

Remedy ITSM approval prior to execution, you must select the approval type.
appears when you:


notifications.

Properties
to choose a server.
Properties
The Properties panel shows a list of properties automatically assigned to a File
Deploy Job. You can modify the value of any properties in this list that are defined as
The default list of properties assigned to a File Deploy Job is determined by the Job

Permissions
Permissions
The Permissions panel is an access control list granting roles access to this File Deploy
NOTE
If you grant DeployJob.Execute to a role so that the role can execute this job, you must also
grant that role DeployJob.Read. You cannot execute a job without being able to read the job.
Modifying File Deploy Jobs

Use this procedure to modify an existing File Deploy Job.
To modify the definition of an existing File Deploy Job, open the Jobs folder and
General
Targets
Options
Advanced Options
Schedules
These tabs correspond to panels in the New File Deploy Job wizard. Use them to
page 98.


Chapter
14
Software and BLPackage Deploy
14
Jobs
BMC BladeLogic provides two types of jobs for deploying packages: Software Deploy
Jobs and BLPackage Deploy Jobs. (BMC BladeLogic documentation uses the generic
term Deploy Job when describing functionality that applies to both types of jobs.)
Software Deploy Jobs let you deploy software packages to one or more target servers
or components. BLPackage Deploy Jobs let you deploy a BLPackage to one or more
target servers or components. Both software packages and BLPackages are executable
packages that can be deployed unattended. For information on creating the packages
you want to deploy, see Chapter 9, Creating packages and other depot objects.
If you want to uninstall software packages, you can create an uninstall job (see
Uninstalling software on page 557). An uninstall job is nothing more than 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.
If you only want to deploy files or directories, you can use a File Deploy Job rather
than a BLPackage Deploy Job (see Chapter 13, File Deploy Jobs). 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 when a failure occurs, and
manually undo the job.
All Deploy Jobs are stored in the Jobs folder. For information on managing and
organizing jobs, see Chapter 10, Managing jobs.

Phases of a Deploy 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 dry run of a deployment without actually deploying
the package. The dry 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 dry run ensures that the file exists. A dry run also
checks environmental requirements. For example, it determines whether you have
the appropriate access level and whether 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
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.

Commit phase
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 actually resided 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 sub-directory 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 if you need to roll back the Deploy Job and restore

Deploy Job states
the server to its original state. For software packages, a Deploy Job gives you 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 BladeLogic provides a
mechanism for storing most transaction information in an alternate location for a
particular target server. For details on this procedure, see Configuring the location
of the transactions directory on page 564.
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 one 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 has failed for a variety of unusual circumstances, such as a server
crash. A job in a Failed state can be re-executed or reset.

Basic and advanced BLPackage Deploy Jobs
Basic and advanced BLPackage Deploy Jobs

When you begin defining a BLPackage Deploy Job, you must choose a basic or
advanced approach. (All Software Deploy Jobs use the basic approach.) The basic
approach defines the job so it is automatically reset should it fail. 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 (see Using the
results of a Deploy Job on page 559).
Deploying a software package

Use this procedure to create a Software Deploy Job, which deploys Windows or
UNIX software packages to one or more target servers or components. For
information on modifying an existing Software Deploy Job, see Modifying Deploy
Jobs on page 556.
Before you can deploy a software package you must store the package in the Depot.
For information on adding Windows patches and service packs to the Depot, see
Adding a hotfix to the Depot on page 365. For information on adding all other
types of software packages to the Depot, see Adding software to the Depot on
page 353.
WARNING
To deploy software, BMC BladeLogic 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 on Windows user
mapping, see Create automation principals on page 149
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 on configuration files and mapping users, see the BMC

Deploying a software package
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.
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
opens.

executable listed in the window to software stored in the Depot. If necessary, you
3 Provide information for the Deploy Job, as described in the following sections:
General
Software
Targets
Targets
Phases and Schedules
Job Options
Phase Options
Properties
Permissions
To monitor the results of a Deploy Job, see Using the results of a Deploy Job on
page 559. This process lets you retry, undo, or reset an entire Deploy Job or phases
of the job on specific servers.

Deploying a BLPackage
Deploying a BLPackage
Use this procedure to create a BLPackage Deploy Job, which deploys a BLPackage to
one or more target servers or components. For information on modifying an existing
BLPackage Deploy Job, see Modifying Deploy Jobs on page 556.
Before you can deploy a BLPackage, you must store the package in the Depot. For
information on bundling the assets of a BLPackage and storing it in the Depot, see
Adding a BLPackage to the Depot on page 375.
Before you deploy a BLPackage, you should review a list of caveats, described in
Caveats for deploying BLPackages on page 528).
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:
General
Package
Targets
Targets
Job Options
Phase Options
Properties
Permissions
To monitor the results of a BLPackage Deploy Job, see Using the results of a
Deploy Job on page 559. This process lets you retry, undo, or reset an entire
BLPackage Deploy Job or phases of the job on specific servers.

Caveats for deploying BLPackages
Caveats for deploying BLPackages

When deploying a BLPackage, be aware of the following:
To deploy a BLPackage, BMC BladeLogic 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 on Windows user mapping, see Create automation principals on
page 149.
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
on configuration files and mapping users, see the BMC BladeLogic Server
When deploying to an agent that is running an older release of BMC BladeLogic,

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 login 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 556.
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.

General
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 the BMC BladeLogic
Installation Guide for details on the specific commands needed to enable asset
deployment.
General
The General panel lets you provide information that identifies a Deploy Job.
OK.
managed servers.

Package
Package
The Package panel lets you identify the BLPackage you want to deploy. If that
BLPackage includes its own local properties, the Package panel lists them. You can
edit them if necessary.
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 BladeLogic 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 532.
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.

Package
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.
5 For Package, choose the package to be deployed by clicking Browse . The Select
Depot Object dialog opens. Select a package from a location in the Depot and click
OK.
6 If the BLPackage includes local properties, do one of the following to provide a

value for the property:
To set a value that always applies for this property when deploying the package
to a server, do the following:
A. In the Assignment Type column, select Value from the list.
B. In the Name/Value column, enter a value. If necessary you can click Reset
property to default value to enter the default value for this property.
To set a specific value that applies when deploying this package to a

component:
A. In the Assignment Type column, select Component Property Name from the list.
B. 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.
If you need to insert a parameter, you can enter the parameter name
manually, bracketed with double question marks (such as ??WINDIR??), or
click Select Property . For more information, see Inserting a parameter on
page 142.
For an example describing how to use component property names, see

Using properties to deploy multiple versions of an application to the same
server on page 532.
To automatically map a property in the BLPackage to a component property,

select Auto Map Component Property Name from the list in the Assignment Type
column. For this mapping to succeed the property names must be identical, and
the properties must be of the same type.
7 In the Required column, set the value to True if a value for this property should be
required.

Package
When defining a BLPackage, you can specify whether a value for a property is
required. If it is not required at the package level, you can specify whether it is
required for this Deploy Job.
If any property in the list requires a value, you must provide one before you can
complete this panel of the Deploy Job wizard.
8 Under Select Deploy Job Type, choose whether you want a Basic or Advanced
Deploy Job.
Using properties to deploy multiple versions of an

application to the same server
Some organizations install multiple versions of the same application on a single
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 will apply 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 BladeLogic. 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. Each step describes a BMC
BladeLogic procedure. Most steps include a reference to more detailed information
about that procedure.
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
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 on creating component templates, see Creating a component

template on page 251.

Package
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 on local properties for component templates and property instances,
see Local properties on page 291.
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 opens.
On that dialog, click Add New , which opens the New Component Template
Part dialog. On that dialog, 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 on page 264.
F Save the component template.
2 Run a Component Discovery Job on the server where 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 on Component Discovery Jobs, see Creating Component Discovery

Jobs on page 294.
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.

Software
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 375.
4 Create a Deploy Job to deploy the app_configuration BLPackage you just

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

Targets
1 To change the order in which software packages are deployed, select a package in
the Install Software list. Click Move Up or Move Down to change the position
of the selected package.
2 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, check
the software parts you want to install. To check all parts, click Select All Parts . To
clear all parts, select Deselect All Parts .
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.
1 In the Available Targets list, select servers, server groups, smart server groups,
components, component groups, or smart component groups.
occurrence.
into your own trap collection system. The MIB can be found at installDirectory/
Share/BladeLogic.mib.

a server.

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. 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.
With the Phases and Schedules panel,

Direct Push
you can choose to stage a deployment LAN
staging
by delivering a package directly to a directory
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 Indirect Push
LAN
to a large number of hosts, which can
saturate a network with data. By WAN
staging indirectly, you can segment
your network and help spread the load repeater
over multiple hosts and sub-nets. If staging
you are staging through a thin pipe, for directory
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\stage. 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 (see Configuring servers to use repeaters during deployments on page 675).
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 BladeLogic 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 extremely largeoften measured in
gigabytes. When deploying such large files, BMC BladeLogic 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.
The Phases and Schedules panel asks you to provide the following categories of
information:
Phase selection
Phase scheduling/execution

Phase selection
The Phase Selection options let you choose the phases of a Deploy Job you want to
run. You can also choose how you want to stage the deployment. Staging refers to
how packages are delivered to targets without actually applying them to those
servers. (Note that 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. During the Commit phase, the
repeaters push packages to multiple target servers simultaneously.
1 Under Phase Selection, check any of the following:
SimulatePerform 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).
NOTE
Although you can select the Simulate option when deploying software packages,
Software Deploy Jobs do not currently perform any meaningful simulation.
CommitApply the package to a target.
2 If you checked Commit in the previous step, you can choose how you want to
stage the deployment by selecting one of the following:
Stage directDeliver the package to a target.
Stage indirectDeliver 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 job as a whole. If you

are defining an advanced BLPackage Deploy Job, you can schedule the job as a whole
or schedule individual phases. Many organizations like to schedule individual phases
so they can stage a job during business hours and then commit the job during a
maintenance window.
If you are defining a basic Deploy Job, select one of the next three options. If you are
defining an advanced Deploy Job, select any of the following options:
Select Execute job now to instruct the job to execute immediately when you finish
defining the job.
Select Do not execute if you do not want to schedule this job.
After you define a Deploy Job, you can always select the job and execute it
interactively (see Performing actions on a job on page 560).
To schedule an entire job that runs sequentially, select Execute selected phases
sequentially. Then, 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 contains two tabs, Schedule and Scheduled Job Notifications. Use them to
define a schedule for the job and click OK.
To schedule individual phases of the job, select Execute selected phases as specified
below. Then, do the following:
A 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
contains two tabs, Schedule and Scheduled Job Notifications. Use them to
define a schedule for the phase and click OK.

B 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
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 contains two tabs, Schedule and Scheduled Job Notifications. Use
them to define a schedule for the phase and click OK.
C 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 you want to schedule the Commit phase, select Start commit at. Then, to
schedule the phase, enter a date and time using a format of mm/dd/yyyy
hh:mm, or click Browse, which displays the Add New Schedule Dialog. The
dialog contains two tabs, Schedule and Scheduled Job Notifications. Use
them to define a schedule for the phase and click OK.
appears when you:


Schedule
NOTE
yyyy/mm/dd format.
(00:00 to 23:59).

to 23:59).


notifications.
to choose a server.

Job Options
Job Options
The Job Options panel lets you customize the behavior of a Deploy 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 BladeLogic 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.

Job Options
1 To set the logging level for the job, select one of the following from Logging Level:
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.
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.

Job Options
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 389). This will
automatically select 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 below for information on 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 should fail 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.

Job Options
NOTE
When using this option, be aware of the following:
BMC BladeLogic recommends that you not use this option unless you are certain how
long 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 how long 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 will not be 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 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.
6 Under Reboot Options, select one of the following from the drop-down list:
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).

Job Options
Use item defined reboot setting and reboot at end of jobCauses 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 jobPrevents 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 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.
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 handle item-level 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 step a.
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 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.

Job Options
For a complete description of the interactions between reboot settings, see

Interactions between reboot settings on page 548.
Interactions between reboot settings

The interaction between reboot settings can be complex. 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.
Note that the table below 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.
Use Reconfigure
Is Reboot Reboot Option reconfiguration Reboot Option
Required for Selected in reboot for reboot Selected in
Item in Package? Deploy Job at end of job? Deploy Job Description
Yes or No Use item defined (Not applicable) Use item defined The job reboots
reboot setting reconfigure for each item that
setting requires a reboot.
If any items
require a
reconfiguration
reboot, those
reconfiguration
reboots occur.
Yes or No Use item defined (Not applicable) Ignore item The job reboots
reboot setting defined for each item that
reconfigure requires a reboot.
setting All reboots are
normal reboots.
Yes or No Ignore item (Not applicable) Use item defined No reboots
defined reboot reconfigure occur.
setting setting
Yes or Not Ignore item (Not applicable) Ignore item No reboots occur
defined reboot defined
setting reconfigure
setting

Job Options
Use Reconfigure
Yes or No Use item defined No Use item defined The job reboots
reboot setting reconfigure for each item that
and reboot at setting requires a reboot.
end of job 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
reboot setting defined for each item that
and reboot at reconfigure requires a reboot.
end of job setting Any
reconfiguration
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
reboot setting reconfigure all item-level
and reboot at setting reboots,
end of job including any
reconfiguration
reboots. The final
reboot at the end
of the job is a
reconfiguration
reboot.
Yes or No Use item defined Yes Ignore item The job performs
reboot setting defined all item-level
and reboot at reconfigure reboots but none
end of job setting of those reboots
are
reconfiguration
reboots. The final
reboot at the end
of the job is a
reconfiguration
reboot.

Job Options
Use Reconfigure
Yes or No Ignore item No Use item defined The job ignores
defined reboot reconfigure all item-level
setting and setting reboots and
reboot at end of performs a
job normal reboot at
the end of the
job.
Yes or No Ignore item No Ignore item The job ignores
defined reboot defined all item-level
setting and reconfigure reboots and
reboot at end of setting performs a
job normal reboot at
the end of the
job.
Yes or No Ignore item Yes Use item defined The job ignores
defined reboot reconfigure all item-level
setting and setting reboots and
reboot at end of performs a
job reconfiguration
reboot at the end
of the job.
Yes or No Ignore item Yes Ignore item The job ignores
defined reboot defined all item-level
setting and reconfigure reboots and
reboot at end of setting performs a
job reconfiguration
reboot at the end
of the job.
Yes Consolidate any Yes or No Use item defined The job delays all
After item reconfigure item-level
deployment setting reboots until a
reboots until end final reboot at
of job the end of the
job. If any item-
level reboots are
reconfiguration
reboots, the final
reboot is a
reconfiguration
reboot.
Yes Consolidate any No Ignore item The job delays all
After item defined item-level
deployment reconfigure reboots until a
reboots until end setting final, normal
of job reboot at the end
of the job.

Phase Options
Use Reconfigure
Yes Consolidate any Yes Ignore item The job delays all
After item defined item-level
deployment reconfigure reboots until a
reboots until end setting final
of job reconfiguration
reboot at the end
of the job.
No Consolidate any Yes or No Use item defined No reboots
After item reconfigure occur.
deployment setting
reboots until end
of job
No Consolidate any Yes or No Ignore item No reboots
After item defined occur.
deployment reconfigure
reboots until end setting
of 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.
The Phase Options panel also lets you assign pre- and post-commands for the Deploy
Job and the undoing of the Deploy Job.
The Phase Options panel asks you to provide the following categories of information:
Simulate and stage options

Commit Options
Pre/Post Commands
Simulate and stage options

Simulate and Stage Options let you determine whether there is sufficient disk space
on the target for staging, simulation, or both.
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 there is sufficient disk
space on a target server.

Phase Options
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
whether there is sufficient disk space for the Stage phase of the job.
SimulateA check is made to determine if there is sufficient disk space for the
simulation phase of the Deploy Job.
Simulate and StageA check is made to determine if there is sufficient disk

space for both the simulation and staging phases of the Deploy Job.
Commit Options
Commit Options let you customize the behavior of a Deploy Job during its Commit
phase.
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 403).
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 very 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 every day, you may only want to store job run
data for one or two days. See the BMC BladeLogic Server Automation Administration Guide for
more information on data retention.
Rollback files reside under agentInstallDirectory/Transactions. For UNIX, by

default this location is /opt/bmc/BladeLogic/version/NSH/Transactions. For Windows,
the default is C:\Program Files\BMC Software\BladeLogic\version\RSCD\
Transactions.

Phase Options
BMC BladeLogic provides a mechanism for storing rollback information in an

alternate location. For details on this procedure, see Configuring the location of
the transactions directory on page 564.
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 filesInstructs 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 will repeatedly attempt 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 componentsRegisters COM objects.
When a deployment encounters a file with a file extension of DLL, EXE, or OCX,
the job determines whether the file is a COM object. If it is and the file being
copied replaces an existing COM object, the deployment unregisters the existing
object, copies in the new object, and registers the new object. If the file being
copied is a new object, the deployment copies the file and registers it.
Pre/Post Commands
The Pre/Post Commands dialog 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.

Properties
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.
1 Click Pre/Post Commands. The Pre/Post Commands dialog opens.
2 To define pre- and post-commands, click one of the following:
Deploy tabDefine pre- and post-commands for a package deployment.

Undo tabDefine pre- and post-commands for undoing a package deployment.
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 pre-command 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. Post-commands are executed in the target directory. To
import the text of the command, click Browse and navigate to the file containing
that text.
If necessary, click Zoom to open a dialog that gives you a larger text box to edit
pre- and post-commands. When you finish editing the command, click OK.
4 Click OK to close the Pre/Post Commands dialog.
Properties
The Properties panel shows a list of properties automatically assigned to a Deploy

Permissions
The default list of properties assigned to a Deploy Job is determined by the Job built-
in property class in the Property Dictionary. If necessary, you can use the Property
One common use for job properties is to assign time-out properties. There are two
properties unique to Deploy Jobs that you can use to assign time-out values for the
simulate and staging phases of a job. For more information on these properties, see
Setting time-outs for simulate and staging phases on page 555.
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.
Setting 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. 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 are taking too long to complete. Without these time-
outs, a Deploy Job may wait indefinitely to complete these 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.
Permissions
The Permissions panel is an access control list granting roles access to this Deploy Job.
Access, including the sharing of objects between roles, is controlled through ACLs.
object on page 186.

Modifying Deploy Jobs
NOTE
If you grant DeployJob.Execute to a role so that the role can execute this job, you must also
grant that role DeployJob.Read. You cannot execute a job without being able to read the job.

Use this procedure to modify an existing Deploy Job.
To modify the definition of an existing Deploy Job, open the Jobs folder and
General
Package - (BLPackage Deploy Jobs)
Software - (Software Deploy Jobs)
Targets
Job Options
Phase Options
These tabs correspond to panels in the New Deploy Job wizard. Use them to
page 98.
Limitations for Windows security settings

When you deploy or browse local Windows security settings, many factors influence
the behavior of BMC BladeLogic, including 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.

Uninstalling software
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.
Use this procedure to create a job that uninstalls a software package. 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 would be the normal behavior of a Software Deploy Job.
For information on modifying an existing uninstall job, see Modifying Deploy Jobs
on page 556.
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 on adding Windows patches and service packs to the Depot, seeAdding
a hotfix to the Depot on page 365. For information on adding all other types of
software packages to the Depot, see Adding software to the Depot on page 353.
You can control the phases of an uninstall job just as you would a Deploy job (see
Using the results of a Deploy Job on page 559). 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 on configuration files and mapping users, see the BMC BladeLogic
You cannot uninstall AIX patches. When BMC BladeLogic 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.
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
from the pop-up menu. The New Uninstall Job wizard opens. If software must
first be added to the Depot, the Select Matching Software dialog opens.

executable listed in the window to software stored in the Depot. If necessary, you
3 Provide information for the uninstall job, as described in the following sections:
General
Software
Targets
Targets
Job Options
Phase Options
Properties
Permissions

Software
To monitor the results of an uninstall job, see Using the results of a Deploy Job
on page 559. This process lets you retry, undo, or reset an entire uninstall job or
phases of the job on specific servers.
Software
The Software panel lets you identify the software package you want to uninstall. You
can also change the order in which packages are uninstalled. For some types of
software, you can select individual parts of the package you want to uninstall.
1 To change the order in which software packages are deployed, select a package in
the Uninstall Software list. Click Move Up or Move Down to change the
position of the selected package.
2 If you want to select parts of a software package to be uninstalled, select a software

package in the Uninstall Software list. Then, in the Select Software Parts list, check
the software parts you want to uninstall. To check all parts, click Select All Parts .
To clear all parts, select Deselect All Parts .
Using the results of a Deploy Job

The complete results of a Deploy Job, including the jobs history, can be accessed
from the Jobs folder. Deploy Job results that pertain to a specific server also appear in
the Activity tab for all servers in the Servers folder. The job results show a listing for
each run of the job, including the date and time the job ran.
When examining results for a Deploy Job, the content editor displays a tab with two
main sections. The left section shows the history of the job. The right section displays
two tabs for a selected job run: Log Messages and Deploy Status.
The Log Messages tab show messages generated for the job run.
The Deploy Status tab provides a table that shows targets servers and components
and the status of their job phases. You can click the headers in each table column to
sort Deploy Job results. Clicking the header for the row listing server or component
names sorts results alphabetically name. Clicking on the Simulate, Stage, or Commit
header, sorts results according to the contents of that column. Results are sorted into
the following job statuses:

Performing actions on a job
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 522 and Deploy Job states on page 524 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 server or phase
Undoing a Deploy Job
Rebooting servers

Use any of the following procedures to take action on a Deploy Job. See Performing
actions on a server or phase on page 561 to take action on a particular run of a job.
In the Jobs folder, right-click a Deploy Job and do any of the following:
Select Open from the pop-up menu. A tab for the Deploy Job opens in the content
editor. Use the sub-tabs 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 561.
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. Once 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. This icon appears when the
phases of an advanced Deploy Job are icon indicating job is paused
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.
In the case of a failed advanced Deploy Job, you can resume the job from the point
where it failed on any targets. How the job proceeds from the point of failure depends
on whether you are controlling the flow of a job by server or phase. If you are
controlling by server, the job will proceed on all failed servers, moving to the next
phase for each server when the job completes its current phase. If you are controlling
by phase, the job will proceed on all failed servers. When they complete the current
phase, the job moves on 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 job that is in a paused state, right-click a Deploy Job and select
Execute from the pop-up menu.

Use any of the following procedures when a job is in an incomplete state and you
want to take actions so the job succeeds or fails. See Performing actions on a job on
page 560 to take action on a job as a whole.
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 this 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 displays. When you are showing history information, the Show
Summary button displays.
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 Click the Log Messages (run level) tab to show messages generated for the entire job
run that is currently selected.

Use this procedure to undo packages that have been 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 BladeLogic does not support undo when you are deploying AIX or Red Hat patches.
1 Display job results by selecting a job, right-clicking, and selecting Show Results
2 Select the most recent run of a Deploy Job.
To undo all committed packages, select the most recent job run and select Undo

Rebooting servers
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 shows the BLPackage or the software packages that are
being rolled back and lists the servers where you are undoing the Deploy Job.
4 Click OK to confirm the undo. A dialog 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 now
displays a column called Rollback, which shows the status of the undo. Selecting a
cell under the Rollback column displays messages for the undo on that server.
Rebooting servers
Use this procedure to 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 389) and the Job
Options panel of the Deploy Job allows reboots (see Job Options on page 543).
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 Job Options on
page 543.
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 prompts you to confirm the
reboot.

Controlling server behavior for Deploy Jobs
Controlling server behavior for Deploy Jobs

BMC BladeLogic 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

Configuring the location of the transactions directory
Using NFS to mount a location while running single-user mode
Designating servers that cannot be targeted by Deploy Jobs

Use this procedure to 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.
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
Configuring the location of the transactions directory

Use this procedure to 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 BladeLogic 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.
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
Use this procedure to 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 do this 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 Add
Software on page 354.
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.
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.


Chapter
15
15 Network Shell Script Jobs
Network Shell Script Jobs let you deploy and execute a Network Shell (NSH) script
that you have previously saved in the Depot. For information on creating and
running a Network Shell Script Job, see Creating Network Shell Script Jobs on
page 567. For information on modifying an existing Network Shell Script Job, see
Modifying Network Shell Script Jobs on page 576.
Network Shell Script Jobs are stored in the Jobs folder. For information on managing
and organizing jobs, see Chapter 10, Managing jobs.
Creating Network Shell Script Jobs

Use this procedure to create a Network Shell Script Job, which runs a Network Shell
script on one or more servers.
To create a Network Shell Script Job you must first add a script to the Depot. For
information on adding Network Shell scripts to the Depot, see Adding a Network
Shell script on page 404.
If the 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 (see Setting values for system
object properties on page 140 or Changing property values for one or more system
objects on page 141). Only a local script requires a staging directory.
See Modifying Network Shell Script Jobs on page 576 for information on modifying
an existing Network Shell Script Job.
1 To create a new Network Shell Script Job, do one of the following:
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.

General
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:
General
Targets
Parameters
Schedules
Properties
Permissions
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.
clicking the browse button. The Select Folder dialog opens. Choose a job folder and
click OK.
3 For 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.
NOTE
If the type of script is 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 (see Setting Property Values or Changing
Property Values for One or More System Objects).

Targets
managed servers.
6 Click Execute Asynchronously to 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.
Targets
The Targets panel lets you choose the servers where you can run scripts. When first
defining and saving a Network Shell Script Job, you do not have to specify target
servers. You can specify target servers at a later time.

Parameters
Parameters
The Parameters panel lets you review and modify values for parameters that are used
when the script runs. Any values you enter 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:
1 To specify whether the job should use a flag for this parameter, click in the Flag
runtime usage column. A drop-down list displays. 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.

2 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 (see Adding a Network Shell script on page 404).
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. For more information on using this tool, see
3 To specify whether the job should use a value for this parameter, click in the Value
runtime usage column. A drop-down list displays. 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.
occurrence.

Schedules
to choose a server.
Schedules
recurring basis.

Schedules
Execute job now.
information:
Schedule
Schedule
NOTE

Schedules
yyyy/mm/dd format.
(00:00 to 23:59).

to 23:59).

notifications.

Schedules
to choose a server.

Remedy ITSM approval prior to execution, you must select the approval type and
enter the approval parameters when you configure the schedule.
appears when you:


Properties
Properties
The Properties panel shows a list of properties automatically assigned to a Network
Shell Script Job. You can modify the value of any properties in this list that are
The default list of properties assigned to a Network Shell Script Job is determined by
the Job built-in property class in the Property Dictionary. If necessary, you can use the
One common use for job properties is to assign time-out properties. Another is to flag
a job as one that should be tracked using BMC BladeLogic Decision Support for
Server Automation.
Permissions
The Permissions panel is an access control list granting roles access to this Network
Shell Script Job. Access to all objects, including the sharing of objects between roles, is
NOTE
If you grant NSHScriptJob.Execute to a role so that the role can execute this job, you must also
grant that role NSHScriptJob.Read. You cannot execute a job without being able to read the
job.
Modifying Network Shell Script Jobs

Use this procedure to modify an existing Network Shell Script Job.
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 the following tabs:

General
Targets
Parameters
Schedules
These tabs correspond to panels in the New Network Shell Script Job wizard.
Use them to modify the job definition.
page 98.


Chapter
16
16 Batch Jobs
A Batch Job is a concatenated series of jobs. Batch Jobs are useful when administrators
must perform multiple discrete jobs. For example, a Batch Job can execute the jobs
necessary to provision a server with applications and application infrastructure. Or, a
Batch Job can deploy a series of BLPackages to update a distributed application that
consists of components running on database, application, and web servers.
You can include any type of job in a Batch Job. You can even include other Batch Jobs,
in effect nesting Batch Jobs.
For more information on creating Batch Jobs, see Creating Batch Jobs on page 579.
For information on modifying an existing Batch Job, see Modifying Batch Jobs on
page 589.
Batch Jobs are stored in the Jobs folder. For information on managing and organizing
jobs, see Chapter 10, Managing jobs.
Creating Batch Jobs

Use this procedure to create or modify a Batch Job, which is a group of concatenated
jobs of any type, including other Batch Jobs.
See Modifying Batch Jobs on page 589 for information on modifying an existing
Batch Job.

Creating Batch Jobs
To create a new Batch Job, do the following:
1 Select a job folder in the Jobs folder, right-click, and select New => Batch Job from
the pop-up menu. The New Batch Job window and the Select Jobs to Add to Batch
Job dialog 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. 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 detailed information about modifying a
specific job type, refer to the following sections:

Modifying Deregister Configuration Object Jobs
Modifying Distribute Configuration Objects Jobs
Modifying Upgrade Model Objects Jobs
WARNING
When you modify settings for an individual job and save the Batch Job, the settings for that
individual job are also saved.

Batch Job Options
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 opens. Use the dialog 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:
A. 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.
B. Using the tabs on the right, provide information for the Batch Job, as
described in the following sections:
Batch Job Options

Permissions
Properties
Schedules
C. Click OK to save the Batch Job.
Batch Job Options

The Batch Job Options panel lets you do the following:
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.

Batch Job Options
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. There is one exception, the
target server setting, described in step 7 on page 583.
1 For Name, enter an identifying name for the Batch Job. For Description, you can
2 For Save in, specify a location in the Jobs folder where the Batch Job should be
stored by clicking Browse . The Select Folder dialog opens. Choose a job folder
and click OK.
Note that the Version field provides the version number of the individual job that
is currently selected. You cannot edit the Version field.
3 Check Continue executing batch when individual jobs return non-zero exit code if you
want the Batch Job to 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 sequentiallyEach 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 parallelAll the individual jobs in the Batch Job run against all
targets simultaneously.
Execute by serverAll 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.

Batch Job Options
6 Under Servers/Server Groups, do 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 in step 4. When you select
this option, the procedure is complete.
If all the jobs should execute on the servers that you specify in this procedure,
select Use the following servers for all jobs. If you select this option, all jobs
execute on the servers specified in the following steps, including all jobs that are
part of any nested Batch Jobs.
7 To specify servers where the Batch Job should execute, click Add Servers . The
Select Servers/Groups window opens.

11 Click OK to close the Select Servers/Groups window.

Permissions
Permissions
The Permissions panel is an access control list granting roles access to this Batch Job.
NOTE
If you grant BatchJob.Execute to a role so that the role can execute this job, you must also grant
that role BatchJob.Read. You cannot execute a job without being able to read the job.
Properties
The Properties panel shows a list of properties automatically assigned to a Batch Job.
You can modify the value of any properties in this list that are defined as editable. For
more information on assigning property values, see Setting values for system object
The default list of properties assigned to a Batch Job is determined by the Job built-in
property class in the Property Dictionary. If necessary, you can use the Property
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.
occurrence.

Schedules
to choose a server.
Schedules
recurring basis.

Schedules
Execute job now.
information:
Schedule
Schedule
NOTE

Schedules
yyyy/mm/dd format.
(00:00 to 23:59).

to 23:59).

notifications.

Schedules
to choose a server.

appears when you:


Modifying Batch Jobs

Use this procedure to modify an existing Batch Job.
To modify the definition of an existing Batch Job, open the Jobs folder and
Batch Job Options

Schedules
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 detailed information on modifying a
specific job type, refer to the following sections:

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 opens. Use the dialog 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.
To modify the definition of an existing Batch Job, select the top entry in the
tree on the left. The entry is the name of the Batch Job. The following tabs
appear in the right pane:
Batch Job Options

Schedules
You cannot add, delete, or reposition jobs included in a nested Batch Job unless
you modify the definition of that nested Batch Job.
properties, permissions, or audit trail information that apply to this Batch Job.
For more information, see Properties, Permissions, and Audit Trail tab group
on page 98.

Chapter
17
17 Managing virtual environments
BMC BladeLogic enables IT Operators to perform basic ad-hoc actions on Virtual
Machines in their environment (such as starting and stopping Virtual Machines), as
well as more complex management tasks such as deploying applications to a Virtual
Machine and controlling virtualization sprawl.
This chapter discusses the following topics:
Working with Virtual Machines

Managing a VMware environment
Managing a Solaris Zones environment
Managing an IBM Frame environment
Managing a Microsoft Hyper-V environment
Managing virtualization sprawl
Working with Virtual Machines

BMC BladeLogic helps IT Operators effectively manage virtual systems in a variety of
virtual environments.
This section provides an overview of the types of management tasks you can perform
in each of these environments (see Table 5 on page 592), and describes the
administration tasks which are common to all supported virtualization platforms.
NOTE
The BMC BladeLogic administrator must install and configure the virtual environment. For
more information, see BMC BladeLogic Server Automation Installation Guide.

Support for virtual environments
Support for virtual environments

Table 5 provides an overview of the types of BMC BladeLogic console management
tasks you can perform in each of the supported virtual environments.
Table 5 Support for virtual environments

Virtual environment What you can do
VMware 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)
Discover Virtual Machines with new Virtual Infrastructure
Discovery Job
Solaris Live browse a virtual node inventory (Non-global Zone,
Projects and Resource Pools)
Snapshot on all nodes of Non-global Zone, Projects and
Resource Pools
Audit on all nodes of Non-global Zone, Projects and Resource
Pools
Compliance on all nodes of Non-global Zone, Projects and
Resource Pools
Discover Local Zones with new Virtual Infrastructure Discovery
Job
IBM 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
Hyper-V Live browse for virtual node inventory (host, and Virtual
Machine)
Snapshot of Virtual Machine or host
Audit of Virtual Machine or host

Browsing a Virtual Machine
Browsing a Virtual Machine

To browse a Virtual Machine:
1 In the Servers folder, navigate to a virtual host 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 child node server object type applicable to the virtual environment (see
Table 5 on page 592) to display the nodes.
Contents of the Live node in virtual environments

Depending on the virtual environment, the Live node contains the following
specialized child nodes.
Table 6 Contents of the Live node by virtual environment (part 1 of 2)

Virtual
Environment Child Node Server Objects
VMware VMware Virtual Inventory: Shows the dynamic tree under a vCenter (this is the
Center 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.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.
For additional details, see Browsing VMware Virtual Machines on

page 596.

Contents of the Live node in virtual environments
Table 6 Contents of the Live node by virtual environment (part 2 of 2)

Virtual
Environment Child Node Server Objects
IBM Frame Managed System Configuration: Shows information about 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.
For additional details, see Browsing IBM Frame Virtual Machines

on page 611.
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.
For additional details, see Browsing Solaris Zones on page 609.

Microsoft Microsoft SCVMM Clusters: Shows all the clusters in the Microsoft SCVMM. This
Hyper-V includes configuration information about the clusters created in
the Microsoft SCVMM.
Hosts: Shows all the hosts configured under SCVMM, and their
Properties.
Inventory: Shows all the Host Groups and Library Servers

configured under SCVMM.
Virtual Machines: Lists all the Virtual Machines in the Microsoft

SCVMM, in alphabetical order, and the status of each.
For additional details, see Browsing Hyper-V Virtual Machines on

page 613.

Running Snapshot Jobs and Audit Jobs on hosts
Running Snapshot Jobs and Audit Jobs on hosts

You can run Snapshot Jobs and Audit Jobs on a variety of virtual infrastructure server
nodes, including Clusters and Hosts. For example, you could use a vCenter servers
Inventory node to check to see if any Virtual Machines have been added to, or
removed from, a given data center.
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 452 to create
the Snapshot Job.
2 In addition to whatever other Snapshot Job options you choose, make sure to
include the following selection:
Panel Selection
Snapshot Job - General For Select Snapshot Job Type, select
Snapshot server objects.
3 When the Snapshot Job run completes, browse to the Snapshot Results node in the
Servers folder. Expand the Snapshot Job run, then expand the results node for this
Job run.
4 Right-click the results node for the Snapshot Job run, and select Audit.
The New Audit Job wizard opens. Fill out the wizard panels as described in
Creating Audit Jobs on page 475.
In addition to whatever other Audit Job options you choose, make sure to include
the following selection:
Panel Selection
General For Select Audit Job Type, choose Select
server objects.
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 on
page 492.


You manage a VMware environment by adding a vCenter server to BMC BladeLogic.
You can then browse the contents of the vCenter server, and perform a variety of
management tasks, such as:
Discovering Virtual Machines in a VMware environment

Browsing VMware Virtual Machines
Managing VMware Virtual Machines
Viewing vCenter server properties
Adding a new Virtual Machine
Remediating a Virtual Machine
NOTE
All management tasks for VMware hosts and Virtual Machines are performed through
vCenter.
Discovering Virtual Machines in a VMware environment

You can create a Virtual Infrastructure Discovery Job to discover and automatically
register Virtual Machines and hosts in a vCenter.
Creating and executing this Job ensures that all Virtual Machines in the environment
are known to BMC BladeLogic, and are available for you to manage.
For details on creating the Job, see Creating the Virtual Infrastructure Discovery Job
on page 616.

Use this procedure to browse the contents of a VMware virtual environment.
1 In the Servers folder, navigate to a VMware vCenter server.
4 Expand the VMware Virtual Center server object type to display the nodes.

Table 13 describes the structure of the VMware Virtual Center server object type.
Table 7 Structure of the VMware Virtual Center object type (part 1 of 2)

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

Table 7 Structure of the VMware Virtual Center object type (part 2 of 2)

View Description
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.

Use this procedure to perform management tasks on the VMware Virtual Machine.
1 In the Servers folder, navigate to a VMware vCenter server and expand the Live
node.
2 Expand the VMware Virtual Center server object type and then expand the Virtual
Machines node.
The Virtual Machines node shows all Virtual Machines configured within the
VMware vCenter server.
3 Right-click a Virtual Machine. From the pop-up menu, select any of the
management tasks described in Table 14.

Table 8 Management tasks for VMware Virtual Machines

Task Description
Snapshot See Running Snapshot Jobs and Audit Jobs on hosts on
Audit page 595.
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.
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 599.
Delete Delete a Virtual Machine.
Saving a virtual servers state

Use this procedure to 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.
1 In the Servers folder, navigate to a vCenter server and expand the Live node.
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
5 If the snapshot should include the Virtual Machine's memory, select Yes for the
snapmemory option.

6 Click OK.

When you add a vCenter server to BMC BladeLogic, you can easily determine the
location of Virtual Machines and ESX hosts in the vCenter hierarchy by making use of
the following properties:
Server Object Available Properties

Virtual machine Parent Host
Parent Datacenter
Parent Cluster (if part of a cluster)
ESX host Parent Datacenter
Use the following procedure to view the server properties of a Virtual Machine or
ESX host on a vCenter server.
2 Expand the VMware Virtual Center 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
ESX host Parent Datacenter


You can create a new virtual guest based on a VMware vCenter template or on
parameters that you define by creating a Virtual Guest Package in the Depot
workspace. You can then use the Virtual Guest Job to deploy a new VMware Virtual
Machine on the VMware vCenter server (which must be a BMC BladeLogic managed
server).
Manually creating and deploying Virtual Machines takes a great deal of time and
effort and is also potentially error prone because there are so many steps that must be
repeated during the installation of each Virtual Machine. Using the Virtual Guest
Package and Virtual Guest Job provides a repeatable process for creating a new
Virtual Machine according to a specific configuration that you define or from a
VMware template.
As a virtual infrastructure administrator, you may have requests for new Virtual
Machines. Depending on the request, you can create the new Virtual Machine and
add it to the vCenter server in any of the following ways:
Base the new machine on the characteristics of an existing Virtual Machine. See
Adding a Virtual Machine based on an existing Virtual Machine on page 601.
Create a Virtual Guest Package (VGP) that describes the new Virtual Machine you
want to add. 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 Adding a new Virtual Machine based on a
Virtual Guest Package (VGP) on page 604.
Once you have built the new Virtual Machine, you can apply compliance checks to it
to ensure that it was built according to policy.
Adding a Virtual Machine based on an existing Virtual

Machine
To add a Virtual Machine that is based on the characteristics of an existing Virtual
Machine, you create a BLPackage that is based on an existing Virtual Machine, edit
the BLPackage to describe the new Virtual Machine, then deploy the BLPackage to
the vCenter server.
Machines node.
3 Browse to an individual Virtual Machine, for example VirtualMachineX.

4 Right-click VirtualMachineX 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 Machine 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 375.)
5 Now you need to edit the BLPackage to describe the new Virtual Machine 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
displays.
C Edit the BLPackage to describe the new Virtual Machine. For example, you can
specify the operating system, Virtual Ethernet Adapter Type, and many other
machine characteristics.

In addition to whatever other BLPackage options you choose, make sure to

include the following selections:
Node Selection
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 => Set the value to one of the following:
ResourcePool
If you do not want to put this new machine into any resource
pool, set the value to:
Root Pool
(Note that this is case sensitive.)
If you want to put this new machine into a resource pool, for
example RP2, set the value to:
Root Pool/RP2
(Note that this is case sensitive.)

Server Properties You must specify the location of the new Virtual Machine in the
vCenter 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
in the VMware Infrastructure client before setting them here.
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 Deploying a BLPackage on

page 527.
In addition to whatever other Deploy Job options you choose, sake sure you
select a vCenter server as the target on the Targets panel.

Targets must match the environment where you first created the BLPackage that
defines the new Virtual Machine. In this procedure, you started by basing a
BLPackage on a Virtual Machine that resided on a vCenter servertherefore
your target must be a vCenter server.
On the other hand, if you had started by basing a BLPackage on a Virtual

Machine that resided on an ESX server, then you would need to choose and ESX
server as the target.
7 When the Deploy Job run completes, return to the Servers folder, navigate to the
vCenter server and expand the Live node. Expand the VMware Virtual Center
server object type and then expand the Virtual Machines node. You should see the
new Virtual Machine you just added.
You can also take a look a the VMware Infrastructure client to make sure the new
Virtual Machine is present.
Adding a new Virtual Machine based on a Virtual Guest

Package (VGP)
You can build a repeatable process for deploying new Virtual Machines by using a
Virtual Guest Package (VGP). The VGP describes the new Virtual Machine you want
to add. 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.
Creating the Virtual Guest Package
Use this procedure to create and add a Virtual Guest Package to the Depot. A Virtual
Guest Package bundles configuration changes so they can be deployed to virtual
hosts using a Virtual Guest Job. A Virtual Guest Package 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
BladeLogic supports on all operating systems.
NOTE
If you are creating a Virtual Guest Package 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 Virtual Guest
Packages. 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 Virtual Guest Package.

1 From the Depot folder, right-click the depot folder where you want to add the
Virtual Guest Package. From the pop-up menu, select New => Virtual Guest
Package.
The Virtual Guest Package wizard displays.
2 On the Virtual Guest Package dialog, enter the following:
Field Description
Name Enter a name for the package.
Description Enter a brief description of the package.
Member of Browse to the folder in the Depot where you want the Virtual
Guest Package to be created.
VM Guest Package type Choose VMware Virtual Machine to configure the package
and create a new virtual machine, or select VMware Virtual
Machine Template to base it on an existing template.
VMware VC Template Browse to the location of a template on which this Virtual
Guest Package will be based.
3 Click Next.
4 On the Permissions panel, enter the permissions for the Virtual Guest Package.
The Permissions panel is an access control list granting roles access to this Virtual
Guest Package. Access to all objects, including the sharing of objects between roles,
is controlled through ACLs. The VirtualGuestPackageJob ACL, by default, has all
of the permissions associated with the VirtualGuestPackage authorization
category.
For more information on ACLs, see Defining permissions for a system object on
page 186.
A dialog displays, indicating that the package is being saved to the Depot.
After the Virtual Guest Package is saved, you may want to use the Virtual Guest
Package editor to modify the Virtual Guest Package.
Editing the Virtual Guest Package
You can view a Virtual Guest Package and review or change the predefined
parameters to edit the configuration of the new Virtual Machine that will be created
from the package. Depending on the Virtual Guest Type, you will see different
configuration panels in the package editor.

1 Select the package, right-click and choose Open.
2 In the content editor, navigate to any of the following tabs and review or edit the
settings:
Tab Description
VM Config Type Settings Guest OS configuration parameters
If the package is based on a template, this panel is read-only,

with the exception of the VM Name.
VM Processor/ Memory/ Number of virtual Processors, Memory size and Disk
Disk Settings Configuration settings for the guest
If the package is based on a template, this panel is read-only,

with the exception of Datastore.
VM Network Connections Network connections and Networking parameters like
Network Port groups and Adaptor Type
If the package is based on a template, this panel is read-only.

VM Basic Config Basic configuration for the guest OS, such as Computer
Name, Admin password, WorkGroup and Domain
registration-related information
VM Computer Settings Guest OS computer settings information like User,
Organization, Licensing information and Time Zone locale
settings
Guest Network IP and DNS configuration for the guest
Local Properties BMC BladeLogic Property dictionary settings
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 VMware vCenter server. If the Windows agent is not properly configured with
the correct configuration objects, then the Job does not execute.
For information on installing and configuring the Windows agent in a VMware

environment, see BMC BladeLogic Server Automation Installation Guide.
Creating a Virtual Guest Job
Use this procedure to create a Virtual Guest Job, which deploys a virtual guest
machine to a target vCenter server.
WARNING
To deploy Virtual Machines, BMC BladeLogic recommends that you have administrator
privileges on the vCenter server to which you are deploying the new Virtual Machine.

1 Open the Jobs folder and navigate to a Job folder.
2 Right-click the Job folder and select New => Virtual Guest Job from the pop-up
menu. The Virtual Guest Job wizard opens.
3 On the General panel, provide a name, description and set the Number of Targets
to Process in Parallel. Click Next.
4 On the Virtual Guest Package Selection panel, do the following:
A Choose the virtual guest package to use for the Job.
B Browse to the vCenter host that will be the target for the new virtual guest.
C Expand the vCenter host server, and expand the Inventory node.
D Select the target as Host server/Resource Pool/Cluster for the new Virtual
Machine.
E Click OK.
F Click Next.
NOTE
You can select only one Virtual Host from the VMware vCenter as the target for the Virtual
Guest Job.
5 On the Config Wizard panel, 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. Click Next.
6 On the Setting Wizard panel, select the virtual processor, memory, and disk
settings appropriate for the new virtual guest. If the package is based on a
template, this panel is read-only, with the exception of the Datastore. Click Next.
7 On the Network Connections Wizard panel, specify the Network connections and
Networking parameters like Network Port groups and Adaptor Type. If the
package is based on a template, this panel is read-only. Click Next.
8 On the Basic Config panel, specify the Guest OS basic configuration information
like Computer Name, Admin password, WorkGroup and Domain registration-
related information. Click Next.
9 On the Computer Settings panel, specify the Guest OS computer settings

information such as User, Organization, Licensing information, and Time Zone
locale settings. Click Next.

10 On the Network Settings panel, set the IP and DNS configuration for the guest.
Click Next.
11 On the Local Properties tab, create BMC BladeLogic Property dictionary settings if
required for the Virtual Guest Package configuration. Click Next.
12 On the Schedule panel, choose Execute Job Now or click the Add icon to define a
schedule for the Job.
13 Optionally, click Next to display the following panels and specify options.
On the Notifications panel, optionally specify and email or trap notifications for
the Job.
On the ACL Wizard panel, review the permissions for the Job. The
VirtualGuestPackageJob ACL, by default, has all of the permissions associated
with the VirtualGuestPackage authorization category.
On the Server ACL panel, set the server access permissions for the virtual guest.
On the Server Properties panel, review the properties associated with the virtual
host server.
14 Click Finish.

You can create and use remediation Jobs to rectify problems identified when you run
an Audit or Compliance Job that has Virtual Machines as targets. 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 Virtual Guest
Package with the proper configuration settings that remediates the problem on the
Virtual Machine.
For additional information on remediating problem systems, see Creating a

remediation package on page 342.
Managing a Solaris Zones environment

You manage a Solaris Zones environment by adding a Solaris Zones host server to
BMC BladeLogic. You can then browse the contents of the Solaris Zones server, and
perform a variety of management tasks:

Browsing Solaris Zones
NOTE
BMC BladeLogic supports Solaris Zones environments, but does not support Solaris Logical
Domains (LDoms).
Browsing Solaris Zones

Use this procedure to browse the contents of a Solaris Zones environment.
1 In the Servers folder, navigate to a Solaris Zones server.
4 Expand the Global Zones server object type to display the nodes.
Table 13 describes the structure of the Global Zones server object type.
Table 9 Structure of the Global Zones object type

View Description
Non-global Zones This view displays all Non-global Zones. For each Non-global Zone, the
content editor displays:
Zone Hardware: Displays information on CPU, devices, memory

statistics, and network configuration.
Zone Options: Displays Zone attributes, inherited packages, and
Zone resource controls.
Zone Storage: Displays information on 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.
Resource Pools Displays resource pool information such as processor set data (pset
name, system ID, maximum and minimum CPU settings) and pool
default.

Managing Solaris Zones
Managing Solaris Zones

Use this procedure to perform management tasks on the Solaris Zones.
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 Non-global Zones configured within the Global Zone.
3 Right-click a Non-global Zone. From the pop-up menu, select any of the
Table 10 Management tasks for Non-global Zones

Task Description
Audit page 595.
Start Starts a Non-global Zone.

Install Installs a Zone that is in the configured state.
Halt Stops a Zone and returns it to the ready state.
Reboot Halts and then boots a Zone.
Boot Places the Zone in the running state
Managing an IBM Frame environment

You configure an AIX system to act as a proxy server to manage devices which do not
have installed RSCD agents, such as an IBM Frame. Once the proxy AIX system is
configured, you can add an IBM Frame object in the BMC BladeLogic console and
mange it as you would other top-level server objects such a VMware vCenter server.
For information on configuring the proxy server and adding the IBM frame object in
BMC BladeLogic, see BMC BladeLogic Server Automation Installation Guide.

Browsing IBM Frame Virtual Machines
Browsing IBM Frame Virtual Machines

Use this procedure to browse the contents of an IBM frame.
1 In the Servers folder, navigate to the IBM Frame server.
4 Expand the Managed System server object type to display the nodes.
Table 13 describes the structure of the Managed System server object type.
Table 11 Structure of the Managed System object type (part 1 of 2)

View Description
Configuration Shows information about the following characteristics of the frame:
Connections: Displays information on 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 on 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.
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, it will display its hardware configuration, which

includes CPU, MEMORY, RESOURCE RESERVATION and those
displayed below.
Pools Lists information about the frame's IO pools, shared processor pools,
and Shared Memory pool

Managing IBM LPARs on the frame
Table 11 Structure of the Managed System object type (part 2 of 2)

View Description
VIO Servers: Lists all the VIO servers in the frame, with an indication of each VIO
servers state. You can browse each VIO server to view information
about:
Options: Displays information such as LPAR name and ID, server

state, system name, and OS version.
Profiles: Displays information about the VIO servers 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.
Adapter mapping: Displays information about the type of adapters

configured for the VIO server, such as Net Server and SCSI Server
adapter mappings.
Hardware: Displays various hardware information for the LPAR,

such as CPU, memory, and physical IO.
Other: Displays information such as workgroup ID and power

control information.
Server Properties: Displays information about the server, such as

partition name, OS version, and IP address.
Managing IBM LPARs on the frame

Use this procedure to perform management tasks on the LPARs that are part of the
IBM frame.
1 In the Servers folder, navigate to an IBM frame server and expand the Live node.
2 Expand the Managed Systems server object type and then expand the LPARs node.
The LPARs node shows all the logical partitions in the frame.
3 Right-click an LPAR. From the pop-up menu, select any of the management tasks
described in Table 14.

Table 12 Management tasks for IBM LPARs

Task Description
Audit page 595.
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.

You manage a Microsoft Hyper-V environment by adding a Microsoft System Center
Virtual Machine Manager (SCVMM) server to BMC BladeLogic. You can then browse
the contents of the SCVMM server, and perform a variety of management tasks.
Browsing Hyper-V Virtual Machines

Use this procedure to browse the contents of a Hyper-V virtual environment.
1 In the Servers folder, navigate to a SCVMM server.
4 Expand the Microsoft SCVMM server object type to display the nodes.

Managing Microsoft Virtual Machines
Table 13 describes the structure of the Microsoft SCVMM server object type.
Table 13 Structure of the Microsoft SCVMM object type

View Description
Clusters Shows all the clusters configured under the Microsoft SCVMM, and
their configuration information. Under each cluster, the view lists all the
hosts associated with that cluster and their status
Hosts Shows status and server property information about each host in the
Microsoft SCVMM. The Hosts view includes 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 SCVMM.
Under each Host, the view lists the Host Server Configuration, all the
Virtual Machines of that Host with their status and the Server
Properties, such as Host Group, Entity ID and Entity Type.
Inventory Lists all the Host Groups, and Library Servers. The Library Server view
contains Library Server Host, Guest OS Profiles and Hardware Profiles.
The Library Server Host view contains Virtual Hard Disks, Templates
and VMs configured under it.
Virtual Machines Lists all the Virtual Machines in the Microsoft SCVMM, in alphabetical
order, and the status for each. The Virtual Machine view is a quick way
to browse the Virtual Machines in the environment without having to
navigate to each host.
For each Virtual Machine, you can view:
The hardware configuration, which includes number of CPUs, CPU

type, CPU priority, and so on
Virtual Machine options, such as operating system type, VM path,

start and stop actions, and so on
Ownership Options
Server Properties, such as entity ID, entity type, entity container,

and host group
Managing Microsoft Virtual Machines

Use this procedure to perform management tasks on the Microsoft Virtual Machine.
1 In the Servers folder, navigate to a SCVMM server and expand the Live node.
2 Expand the Microsoft SCVMM server object type and then expand the Virtual
Machines node.

SCVMM server.
3 Right-click a Virtual Machine. From the pop-up menu, select any of the
Table 14 Management tasks for Hyper-V Virtual Machines

Task Description
Audit page 595.
Start Starts the Virtual Machine.

Poweroff Perform an immediate stop of the Virtual Machine, without
running any power-down scripts.
Suspend Pause the Virtual Machine.
SaveState Save the Virtual Machine's state to hard disk.
DiscardSaveState Discard the saved state from hard disk.
Shutdown Run any power-down scripts and then stop a Virtual
Machine.
Snapshotvm Create a snapshot for the Virtual Machine.

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 BladeLogic, you
can discover the virtual infrastructure inventory, and 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).
Identifying virtual sprawl

Creating the server lifecycle properties mapping file

For VMware and Solaris virtual environments, you can run a Virtual Infrastructure
Discovery Job to query the environment for existing Virtual Machines and zones. If
the discovered Virtual Machines or zones are not already enrolled in the inventory,
you can choose to auto-enroll them by selecting an option in the Job configuration.

Running the Virtual Infrastructure Discovery Job enables you to see what the
VMware 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.
Creating the Virtual Infrastructure Discovery Job
Before you begin
Note the following regarding the Virtual Infrastructure Discovery Job:
The Virtual Infrastructure Discovery Job is supported for VMware and Solaris
platforms only.
Export of Virtual Infrastructure Discovery Jobs through BLCLI is not supported.
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
Use this procedure to create a Virtual Infrastructure Discovery Job, which can
perform the following tasks:
Environment Task
VMware and Solaris Discover and register Virtual Machines or local zones that are
available on the selected targets.
Imports four properties for Virtual Machines and local zones (Entity
ID, Entity Manager, Entity Container and Entity Type)
Updates all the properties of all discovered Virtual Machines and
local zones (if you set the UPDATE_ALL_VMS job property to true).
VMware Discover unregistered Virtual Machines on the datastores of the
environments only selected targets.
The Job 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.
Using the auto-remediate option, register the discovered Virtual
Machines in the vCenter and also in BMC BladeLogic.
Import lifecycle properties - imports three lifecyle properties for
Virtual Machines (OWNER, EXPIRY_DATE, LOCATION)

1 Open the Jobs folder and navigate to a Job folder.
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
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 On the General panel, set the following options and click Next:
Option Description
Name Enter a name for the Job.
Description Enter a brief description of the Job.
Save in Browse to the folder in which you want to save the Job.
Number of Targets to Set the Number of Targets to Process in Parallel.
Process in Parallel
Auto-register Select this option to automatically register any discovered Virtual
discovered ESX Machines that are not currently being managed by BMC
Hosts/Virtual Systems BladeLogic. This option connects to the targets selected in the Job
(the vCenter servers or Global Zones) and:
retrieves all the virtual systems or Local Zones

compares the discovered systems to the list of BMC BladeLogic
enrolled servers
registers the systems in BMC BladeLogic if they are not
registered
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 This option is for VMware platforms only.
Virtual Systems
Select this option to discover any Virtual Machines that are not
registered in the vCenter or BMC BladeLogic.
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

BladeLogic) matches the name of the CONNECTION_URL
property specified when the vCenter server was added to BMC
BladeLogic.

Option Description
Import Lifecycle Imports the server lifecycle properties for a virtual system from a
Properties 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.
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 are imported only if either of the
Auto-register discovered ESX Hosts/Virtual Systems or Auto
Remediate Unregistered Virtual Systems options is selected.
4 On the Targets panel, choose the targets for virtual guest discovery, or select All
Servers. Click Next.
If you selected the Auto Remediate Unregistered Virtual Systems option, the
Destination Selection Panel is displayed.
5 Select the remediation target for any unregistered Virtual Machines by doing the
following:
A Browse to a vCenter host.
B Expand the VMware Virtual Center node.
C Expand the Inventory node.
D 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.
E Click Next.
6 If you selected the Import Lifecycle Properties option, the Select Lifecycle Properties
Mapping panel is displayed.
NOTE
You must have created a server lifecycle properties mapping file and stored in the Depot. See
Creating the server lifecycle properties mapping file on page 620.
Do the following:

A Browse to the location of the mapping file in the Depot folder.
B Select the mapping file.
C Click OK.
D Click Next.
7 On the Notifications panel, optionally specify and email or trap notifications for
the Job. Click Next.
8 On the Schedule panel, choose Execute Job Now or click the Add icon to define a
schedule for the Job. Click Next.
9 On the Server Properties panel, review the properties associated with the virtual
host server. You can choose to update the properties of all discovered and
registered Virtual Machines by setting the UPDATE_ALL_VMS Job property to
True. Click Next.
TIP
If you want the Virtual Infrastructure Discovery Job to update all the discovered and
registered servers with the entity properties, you must
set the UPDATE_ALL_VMS job property to true, as the Default Value reverts to false
after each Job execution
ensure that the Auto-register discovered ESX Hosts/Virtual Systems option was
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.
10 On the Permission panel, review the permissions for the Job. The
VSMDiscoveryJob ACL, by default, has all of the permissions required. Click Next.
NOTE
You cannot include a Virtual Infrastructure Discovery Job as part of a Batch Job.
Reviewing the results of the Job

In the Job Results pane, expand the Unregistered Servers View.

This view displays any unregistered Virtual Machine discovered by the Virtual
Infrastructure Discovery Job. Review the systems and register those which you want
to manage.

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.
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 option 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 1 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.
The file must be an XML file with the format shown in Figure 1.

Figure 1 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"
<property name="expiry date" defaultValue="2009-08-21 14:07:20" isMap="false"
</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.
The lifecycle property values can either be:
imported from the default values specified in the mapping file. The example
shown for hostname_1 in Figure 1 shows how the default values would appear in a
mapping file.
retrieved from the manager by mapping custom properties on the virtual entity
manager to each of the supported properties. The example shown for hostname_2
in Figure 1 shows how you would retrieve properties from the virtual entity
manager using the isMap attribute.
If the isMap attribute for a property in the mapping file is set to false then the default
value specified for the property is used, as shown for hostname_1 in Figure 1.
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.

NOTE
Although lifecycle properties are not retrieved from the virtual entity manager in a Solaris
Zones 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 local zones.
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
BladeLogic will also be updated.

Chapter
18
18 Administrative tools
BMC BladeLogic provides the following capabilities that administrators can use to
improve their efficiency:
Administering custom commands

Adding a custom configuration object
Identifying configuration files
Creating extended objects
Creating a Distribute Configuration Objects Job
Creating an Upgrade Model Objects Job
Creating a Deregister Configuration Object Job
The Infrastructure Management window
Getting information about Application Servers
Setting up communications with remote servers
Configuring servers to use repeaters during deployments
Creating rules to determine Application Servers to use for job execution
Administering custom commands

BMC BladeLogic allows you to define custom commands that 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.

Creating or modifying a custom command
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. Custom commands allow you to perform many functions from
within the BMC BladeLogic console that might otherwise require you to launch a
command line interface like Network Shell or other external applications.
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 BladeLogic 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 displays 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:

Deleting a custom command

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. (See Executing custom commands on page 240.)

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.
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 displays. 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 BladeLogic 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,
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. (You selected the command type in step step 3.)
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.
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 displays.
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
11 Define an ACL for the custom command. For more information on defining an
12 Depending on whether you are creating or modifying a custom command, click

Finish or OK.

Use this procedure to delete an existing custom command.
1 Select Configuration => Custom Commands View. The Custom Commands view
displays.
2 Select the commands you want to delete and click Delete Custom Command .A
dialog prompts you to confirm the deletion.
Using the Configuration Object Dictionary

The Configuration Object Dictionary provides a central location where you can view,
create, and manage the configuration objects that BMC BladeLogic manages. The
Configuration Object Dictionary shows all built-in server objects as well as all
configuration files, custom configuration objects, and extended objects.

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.
Using the Configuration Object Dictionary, you can perform any of the following
procedures:
Deleting a custom configuration object
NOTE
BMC BladeLogic 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 on setting
this limit, see the BMC BladeLogic Server Automation Administration Guide.

A standard installation of BMC BladeLogic provides a wide range of server and
configuration objects for many operating systems. Use this procedure to add custom
configuration objects to the Configuration Object Dictionary.
To perform this procedure, all material needed to implement a custom configuration

object must be contained within a ZIP file. Once you have obtained the ZIP file for a
custom configuration object, you can use this procedure to add it to the Configuration
Object Dictionary. Then, you must distribute the implementation files for the
configuration object to servers where you want to use the object (see Creating a
Distribute Configuration Objects Job on page 642). For more information on jobs you
can use to manage custom configuration objects, see Using jobs to manage custom
configuration objects on page 641.

1 Obtain a ZIP file containing the materials needed to implement a custom

2 Select Configuration => Config Object Dictionary View. The Configuration Object
Dictionary opens.
3 Click the Add Configuration Object icon . The New Configuration Object wizard
opens.
4 Select Server Object, if it is not already selected, and click Next. The Server Object
Definition panel of the wizard displays.
5 Click the browse button and navigate to the ZIP file you obtained in step step 1.
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
7 Define an ACL for the server object. For more information on defining an ACL, see
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 a Distribute Configuration Objects Job on page 642.

By default BMC BladeLogic automatically recognizes standard configuration files for
all supported operating systems. For BMC BladeLogic to read a configuration file
correctly, it must adhere to configuration file standards for the relevant operating
system. BMC BladeLogic can also treat most types of XML files as configuration files.
BMC BladeLogic uses a system of grammar files to parse configuration files.

Typically the BMC BladeLogic 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.

Once configuration file records are created, you can browse, snapshot, audit, 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.
Use the following procedure to identify additional configuration files that should
appear under the Configuration object of a server in the Servers folder. When
performing this procedure, you must choose the grammar file used to parse
information that is displayed as a configuration file. BMC BladeLogic 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 on page 632.
The following procedure also explains how to add local configuration objects to a
component template. The procedure is essentially the same as adding a configuration
object to the Configuration Object Dictionary. For more information on how to use
local configuration objects, see Local configuration objects on page 293.
NOTE
BMC BladeLogic does not support configuration files that include binary data.
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 displays.
To modify an existing configuration file, select the file and click Edit
Configuration Object .
The Edit Configuration Object: Configuration File window displays. It provides

the same options as the Configuration File panel of the Configuration Object
wizard.

When using the Configuration Object Dictionary, you can filter the list of
configuration objects displayed using the drop-down lists at the top of the
window to select the category of configuration objects, the relevant operating
system, or both. These filters are not available when creating local configuration
objects.
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.
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 (see Inserting a parameter on page 142).
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 BladeLogic supports a variety of grammar files. For more information, see
Grammar files on page 632.
If you are copying or editing an existing configuration file, click OK. The
procedure is complete.
If you are creating a local configuration file for a component template, click
Finish. The procedure is complete.
If you are creating new configuration files, click Next. The Permissions panel
displays.
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 on defining an
10 Click Finish to close the wizard and save the new configuration files.
Grammar files
BMC BladeLogic 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 BladeLogic so you can then browse,
snapshot, audit, and deploy that information.
Although BMC BladeLogic provides many grammar files, there are three basic types:
HTTPDParses httpd.conf files.
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 BladeLogic supports by default.
These grammar files reside in OM_installDirectory/scripts. For additional information
on how an individual grammar file is used to parse configuration files, refer to
information provided in each grammar file.
Grammar Type Associated

Name Grammar File Description
/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 resolv.gm Parses files with a varying number of space- or tab-
file 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 aix_security.gm Parses all /etc/security files in AIX that have a
/etc/security/* header on one line followed by name/value pairs
file 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 Solaris.
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 ypconf.gm Parses a complex format specific to /etc/yp.conf
/etc/yp.conf file files on Linux.
Machine Config machine.config.x Parses machine.config XML files used for IIS and
XML file ml.gm .NET 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 nvp.gm Parses records with a name and multiple values,
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.
nsswitch.conf on nsswitch.gm Parses formats using an initial key followed by a
UNIX colon with a varying number of space-delimited
values after the colon.
Oracle config files ora.gm Parses tnsnames.ora and listener.ora files in Oracle.
running-managed- running-managed- Parses Tomcat running-managed-servers.xml files.
servers.xml servers.xml
single unique single_val.gm Parses files where each line contains one value that
value per line does not contain a space, equal sign (=), or pound
sign (#).
Solaris system.gm Uses a complicated grammar to parse Solaris
/etc/system file /etc/system files.
Solaris inetd.conf inetd.gm Parses Solaris files with lines consisting of a varying
file number of tab-delimited entries; all entries make
up the unique key.


split line into line.gm Parses generic records separated by spaces; all
fields 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- Parses Tomcat server.xml files.
server.xml.gm
tomcat-users.xml tomcat- Parses Tomcat users.xml files.
users.xml.gm
UNIX syslog.gm Parses /etc/syslog.conf files on UNIX.
/etc/syslog.conf
file
users and exports users.gm Parses files using the format of the BMC BladeLogic
file users and exports configuration files. For a
discussion of those files, see the BMC BladeLogic
Administration Guide. 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 web.config.xml.g Parses web.config XML files used for IIS and .NET
file m 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 generic.gm Parses files by treating a complete line as a single
record 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.


BMC BladeLogic 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 BladeLogic console to browse, snapshot, and
audit the contents of that 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).
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
BladeLogic supports (see Grammar files on page 632), 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, or audit), 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.
Use this procedure to create an extended object in the Configuration Object

Dictionary so that all users in your role can access. The extended object becomes
available under the Extended Object node (which is under the Live node) of any
server in the Server 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.
The following procedure also explains how to add local extended objects to a
component template. The procedure is essentially the same as adding an extended
object to the Configuration Object Dictionary. For more information on how to use
local extended objects, see Local configuration objects on page 293.
Once 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.
The BMC BladeLogic knowledge base (available on the Support section of the BMC
BladeLogic corporate web site) provides scripts and instructions that you can use to
create common extended objects.

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 displays.
To modify an existing extended object, select that object and click Edit
The Edit Configuration Object: Extended Object window displays. 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 optionally
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 BladeLogic 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 step 7 below).
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 639). 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 (see Inserting a
parameter on page 142).
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 BladeLogic
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 step 6.
For more information on grammar files, see Grammar files on page 632.
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
displays.
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 on defining an ACL,
see Defining permissions for a system object on page 186.
12 Click Finish to close the wizard and save the new extended object.
Defining custom icons

Use this procedure to create a set of custom icons that you can associate with
extended objects. A custom icon can help you quickly identify an extended object
when browsing extended objects in the Servers folder.
When selecting a custom icon, the image must be in a GIF format, and its resolution
must be 16 by 16 pixels.
1 Start the New Configuration Object wizard and then open the Extended Object
Definition panel, as described in Creating extended objects on page 636.
2 For Icon, click Browse . The Icon Library dialog opens.
To add a new custom icon, click Add Custom Icon . The New Custom Icon
dialog opens.
To modify an existing custom icon, select the icon and click Modify Custom Icon
. The Modify Custom Icon dialog opens. It provides the same options as the
New Custom Icon dialog.

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 opens.
6 Use the Select Icon Location dialog 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, click OK.
8 Click Close to close the Icon Library dialog. If you are adding a new icon, it appears
in the list of icons available on the Extended Object Definition panel.

Use this procedure to delete a custom configuration object from the Configuration
Object Dictionary.
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 a Deregister Configuration Object Job on page 656) 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.
When you perform this procedure, you cannot delete the most recent version of a
custom configuration object without also deleting all earlier versions of the same
object.
1 Deregister the custom configuration object from any servers to which it has been
distributed. See Creating a Deregister Configuration Object Job on page 656.
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.

Using jobs to manage custom configuration objects
If you are deleting the latest version of a custom configuration object, a message
informs you that you must first delete all previous 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 displays the dependent objects. See Deleting a folder, group,
smart group, or system object on page 96 for a description of the actions you can
take using the Found Dependencies dialog.
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.
Using jobs to manage custom configuration objects

BMC BladeLogic provides several jobs for managing custom configuration 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 a Distribute Configuration Objects Job on page 642.
Upgrade Model Objects JobUpgrades policy-based objectsthat is, component

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 an Upgrade Model Objects Job on page 649.
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 a
Deregister Configuration Object Job on page 656.

Creating a Distribute Configuration Objects Job
Creating 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. Before you can perform this procedure, you must add the new custom
configuration object to the Configuration Object Dictionary (see Using the
Configuration Object Dictionary on page 627)
For information on modifying an existing Distribute Configuration Objects Job, see

Modifying Distribute Configuration Objects Jobs on page 648.
Open the Jobs folder and navigate to a sub-folder 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

General
Selected Configuration Objects
Targets
Schedules
Properties
Permissions
General
The General panel lets you provide basic information that identifies a Distribute
Configuration Objects Job.

click OK.
access simultaneously. See the BMC BladeLogic Server Automation Administration
Guide for more information on configuring Application Servers.
managed servers.

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.

Targets
3 In the Available Configuration Objects list, select one or more custom configuration
objects.
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.
Targets
The Targets panel lets you choose the servers to which you want to distribute custom
configuration objects.
1 In the Available Targets list, select the servers or server groups to which you want
to distribute custom configuration objects.
occurrence.

Schedules
to choose a server.
Schedules
recurring basis.
Execute job now.
information:

Schedules
Schedule
Schedule
NOTE
yyyy/mm/dd format.
(00:00 to 23:59).


Schedules
to 23:59).

notifications.
to choose a server.

Properties
Properties
The Properties panel shows a list of properties automatically assigned to this
Distribute Configuration Objects Job. You can modify the value of any properties in
The default list of properties assigned to a Distribute Configuration Objects Job is

Permissions
The Permissions panel is an access control list granting roles access to this Distribute
Configuration Objects Job. Access to all objects in BMC BladeLogic, including the
NOTE
If you grant DistributeConfigurationObjects.Execute to a role so that the role can execute this
job, you must also grant that role DistributeConfigurationObjects.Read. You cannot execute a
job without being able to read the job.

Use this procedure to modify an existing Distribute Configuration Objects Job.
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 from the pop-up menu. The content editor displays the following
tabs:

General
Targets
Schedules
These tabs correspond to panels in the New Distribute Configuration Objects

Job wizard. Use them to modify the job definition.

page 98.

When you add a new version of a custom configuration object to your BMC
BladeLogic system, policy-based objectsthat is, component templates, BLPackages,
and server object-based Snapshot and Audit Jobsare not automatically upgraded to
reference the new version. BMC BladeLogic lets you decide whether you want to
upgrade the policy-based object. If you do, 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 information on modifying an existing Upgrade Model Objects Job, See

Modifying Upgrade Model Objects Jobs on page 655.
1 Open the Jobs folder and navigate to a sub-folder 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:
General
Selected Objects
Schedules
Properties
Permissions

General
General
The General panel lets you provide basic information that identifies a Upgrade Model
Objects Job.
OK.
managed servers.
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.

1 From Available Objects, select one or more component templates, BLPackages, and
server-object based Snapshot Jobs and Audit Jobs.
occurrence.
to choose a server.

Schedules
Schedules
recurring basis.
Execute job now.
information:
Schedule
Schedule

Schedules
NOTE
yyyy/mm/dd format.
(00:00 to 23:59).

to 23:59).

Properties

notifications.
to choose a server.
Properties
The Properties panel shows a list of properties automatically assigned to Upgrade
Model Objects Job. You can modify the value of any properties in this list that are

Permissions
The default list of properties assigned to an Upgrade Model Objects Job is determined
by the Job built-in property class in the Property Dictionary. If necessary, you can use
the Property Dictionary to create new properties. For more information, see Using
the Property Dictionary on page 118).
Permissions
The Permissions panel is an access control list granting roles access to this Upgrade
Model Objects Job. Access to all objects in BMC BladeLogic, including the sharing of
NOTE
If you grant UpgradeModelObjects.Execute to a role so that the role can execute this job, you
must also grant that role UpgradeModelObjects.Read. You cannot execute a job without being
able to read the job.

Use this procedure to modify an existing Upgrade Model Objects Job.
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 the following tabs:
General
Selected Objects
Schedules
These tabs correspond to panels in the Upgrade Model Objects Job wizard. Use
them to modify the job definition.

page 98.

Creating a Deregister Configuration Object Job
Creating a Deregister Configuration Object

Job
To delete a custom configuration object from the Configuration Object Dictionary, the
following conditions must be true:
The custom configuration object cannot exist on any servers.
The latest version of any policy-based objects (that is, component templates,
BLPackages, and server object-based Snapshot and Audit Jobs) cannot refer to the
custom configuration object.
You must manually modify the policy-based objects that include references to the
custom configuration object you want to deregister. In other words, you must open
the definition for each policy-based object and delete the custom configuration objects
you want to deregister.
To remove custom configuration objects from servers, use this procedure to run a
Deregister Configuration Object Job. This job removes all implementation files
associated with a custom configuration object.
For information on modifying an existing Deregister Configuration Object Job, see

Modifying Deregister Configuration Object Jobs on page 663.
Open the Jobs folder and navigate to a sub-folder 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

General
Targets
Schedules
Properties

General
Permissions
General
The General panel lets you provide basic information that identifies a Deregister
Configuration Object Job.
click OK.
managed servers.


The Selected Configuration Objects panel lets you choose the custom configuration
objects you want to deregister from 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 Remove any version of selected configuration objects present on servers 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.
3 In the Available Configuration Objects list, select one or more custom configuration
objects.
Targets
The Targets panel lets you choose the servers where you want to deregister custom
configuration objects.
1 In the Available Targets list, select the servers or server groups where you want to
deregister custom configuration objects.
occurrence.

Schedules
to choose a server.
Schedules
recurring basis.

Schedules
Execute job now.
information:
Schedule
Schedule
NOTE

Schedules
yyyy/mm/dd format.
(00:00 to 23:59).

to 23:59).

notifications.

Properties
to choose a server.
Properties
The Properties panel shows a list of properties automatically assigned to this
Deregister Configuration Object Job. You can modify the value of any properties in
The default list of properties assigned to an Deregister Configuration Object Job is


Permissions
Permissions
The Permissions panel is an access control list granting roles access to this Deregister
Configuration Object Job. Access to all objects in BMC BladeLogic, including the
NOTE
If you grant DeregisterConfigurationObjects.Execute to a role so that the role can execute this
job, you must also grant that role DeregisterConfigurationObjects.Read. You cannot execute a
job without being able to read the job.

Use this procedure to modify an existing Deregister Configuration Object Job.
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 from the pop-up menu. The content editor displays the following
tabs:
General
Targets
Schedules
These tabs correspond to panels in the Deregister Configuration Object Job

wizard. Use them to modify the job definition.

page 98.

The Infrastructure Management window provides a way to view and manage
Application Servers and other servers that support BMC BladeLogic 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 665.
Application Server Lets you configure, control, and manage multiple Application
Launchers Servers on the same host. (Your role must be granted
authorization to view and manage Application Servers on this
node.) For information, see the BMC BladeLogic Server
Pxe Servers Displays information about the PXE servers used for
provisioning Windows and Linux servers in a BMC
BladeLogic environment. For information, see Getting
information about PXE servers on page 666.
Database Config Info Displays database connection information. For information,
see Getting information about the database on page 667.
Proxy Servers Lets you create and manage SOCKS proxy servers used to
communicate with remote target servers. See Managing
SOCKS proxy servers on page 673.
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 667.
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. See BMC
Repeater Servers Lets you create and manage repeater servers used for indirect
staging to target servers during deployment. See Managing
repeater servers on page 680.
Repeater Routing Rules Lets you create and manage rules for determining the
repeater used for indirect staging to target servers. See
on page 675.
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 to use for job execution on
page 683.

Getting information about Application Servers
Getting information about Application

Servers
You can 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. For more information on granting authorizations, see
Managing authorizations on page 147.
1 Select Configuration => Infrastructure Management.
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 Expand the Application Servers node.
on the host (using the same
database) The left pane lists each Application Servers Display Name
and Authorization Port.
General information about Click the Application Servers name in the left pane.
an 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
Application Server provides and type of services vary according to the Application
Servers type.)
Status information about an Expand the hierarchy of the Application Server. Click the
Application Server service service name.
A menu of actions you can Right-click the Application Server.
perform on the Application
Server

Reporting Application Server information
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.
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 BladeLogic infrastructure, use the
Infrastructure Management window.
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.

Getting information about the database
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 666.
Getting information about the database

To get information about the database to which the Application Server is connected,
use the Infrastructure Management window.
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 666.
Setting up communications with remote

servers
If you want to manage remote serversservers on a different network from your
BMC BladeLogic system or outside your networks firewall, for exampleyou can set
up your Application Server to communicate with those servers through your SOCKS
proxy servers.
NOTE
A set-up requirement is that the SOCKS V5 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 those servers resolve host names.

Creating SOCKS proxy server objects
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 Create the proxy server objects and add them to the BMC BladeLogic
infrastructure. See Creating SOCKS proxy server objects on page 668.
3 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
4 Add the remote servers you want to manage. See Adding remote servers on
page 671.
Creating SOCKS proxy server objects

In order to route communications through a SOCKS proxy server, you first create a
proxy server object in the BMC BladeLogic 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.
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 The name of the proxy server. This name can be any name.
The BMC BladeLogic system uses it for identification and
display within the system.
Description (Optional) Descriptive text about the proxy server.
Host The name of the host machine for the proxy server.
Port The port for the SOCKS proxy.

Creating rules for routing to remote servers

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 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 itself is operational. For information, see Managing SOCKS
proxy servers on page 673.

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
BladeLogic system. Information you enter in the wizard should be in keeping with your
teams strategy for routing to remote servers.
NOTE
To create, modify or delete routing rules, your role must be granted the RoutingPolicy.Modify
and the BL_Administration.Read authorizations.
2 In the Infrastructure Management window, right-click the Network Routing Rules

node and select Network Routing Wizard. The General panel opens.

3 For 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 BladeLogic system and once created, cannot easily be modified.
For Description, you can optionally enter descriptive text about the property.
4 Click Next. The Rules panel opens.
5 Click Add Rule . The New Rule wizard opens.
6 For 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.
For Description, you can optionally enter descriptive text about the rule
7 Click Next. The Targets panel opens.
8 Under Select proxies for this 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.
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 674.) To create the rule without specifying
proxy servers, go to the next step.
9 When you have finished selecting proxy servers for the rule, click Finish. The Rules
panel opens and displays the rule you created.
To create another rule based on the same server property, click Add Rule and
repeat step 5 through step 7.

Adding remote servers
To modify a rule, click Edit Selected Condition .
10 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.
11 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 on using the New Rule wizard, see Creating
complex routing rules on page 685.
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.
NOTE
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.

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.
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
Importing servers on page 223.

1 In the BMC BladeLogic 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 that can be resolved by either the
Application Server or the SOCKS proxy server. Or enter an IP address.
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.
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 to step 9 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. For information, see Defining a smart group
on page 92.
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.

Managing SOCKS proxy servers
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.)
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. For information, see Updating a single servers
Managing SOCKS proxy servers

The BMC BladeLogic 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 BladeLogic
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 on creating proxy server objects, see Creating SOCKS proxy server
objects on page 668.
Viewing and editing proxy server properties

Use this procedure to display a proxy servers properties and change them.
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

Deleting proxy server objects
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

Use this procedure to delete proxy server objects from the BMC BladeLogic system.
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 actual proxy
server to see if it is running.
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.
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).
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.

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. 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, follow this master

procedure:
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 on configuring advanced file servers and advanced repeater servers, see BMC

Creating repeater server objects
1 In the Infrastructure Management window, create repeater server objects in the

BMC BladeLogic infrastructure. See Creating repeater server objects on
page 676.
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 677.
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 679.
NOTE
To access, create and manage repeater server objects, your role must be granted these
authorizations in RBAC:
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 BladeLogic infrastructure.
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 BladeLogic 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.

Creating rules to determine the repeater used for target servers

Host (Required) The name of the host machine for 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 BladeLogic Advanced Repeater is installed on this
server, this option is visible. To configure the server as an
advanced repeater server, see BMC BladeLogic Server
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
RoutingPolicy.Modify and the BL_Administration.Read authorizations.
2 In the Infrastructure Management window, right-click the Repeater Routing Rules

node and select Repeater Routing Wizard.
3 For 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.

Creating rules to determine the repeater used for target servers
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
BladeLogic 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.
For Description, you can optionally enter descriptive text about the property.
4 Click Next. The Rules panel opens.
5 Click Add Rule . The New Rule wizard opens.
6 On the General panel, for 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.
For Description, you can optionally enter descriptive text about the rule.
7 Click Next. The Targets panel opens.
8 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.
arrow.
When you first define a rule, you do not have to specify a repeater server; you can
specify it at a later time. (For information, see Assigning a repeater server to a
repeater routing rule on page 681.) To create the rule without specifying repeater
servers, go to the next step.
9 Click Finish. The Rules panel opens and displays the rule you created. For
example, the result for a rule named New York (which uses the server property
Location) would have this condition: ??TARGET.Location?? = New York.
To create another rule based on the same server property, click Add Rule and
repeat step 5 through step 7.
To modify a rule, click Edit Selected Condition .

Assigning repeaters to target servers
10 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
on using the New Rule wizard, see Creating complex routing rules on page 685.
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.
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 676 and Creating rules to determine the
repeater used for target servers on page 677.
1 In the BMC BladeLogic console, open the Servers folder.
2 Right-click the server and select Set Property. The Set Server Property dialog opens.
3 Under Name, select the server property you added with the Repeater Routing
Wizard, for example, Location.

Managing repeater servers
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 BladeLogic 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.
Managing repeater servers

After you create repeater server objects, you can manage those objects through the
Infrastructure Management window of the BMC BladeLogic console. You can view
and edit a repeater servers properties, delete the repeater server object, or check to
see if the repeater server is functioning and if its staging directory exists.
For information on creating repeater server objects, see Creating repeater server
objects on page 676.
Viewing and editing repeater server properties

Use this procedure 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.
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.

Deleting repeater server objects
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. See BMC BladeLogic Server Automation Administration
Guide for information.
Deleting repeater server objects

Use this procedure to delete repeater server objects from BMC BladeLogic.
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.
1 Select Configuration => Administration => Infrastructure Management.
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.
arrow.
5 Click OK.

Enabling/disabling repeater rule evaluation
Enabling/disabling repeater rule evaluation

By default, BMC BladeLogic evaluates a target servers repeater routing policy to
determine the repeater to use for indirect staging of 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.
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.
Servers node.

Creating rules to determine Application Servers to use for job execution
3 Right-click the repeater server and choose from the following options:
Option Description
Update Repeater Server This option contacts the repeater server to determine current
Status 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 This option updates the status of the server.
Properties This option 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 This option clears the cache on an advanced repeater server.
Cache
Verify Advanced Repeater This option verifies that the cache on an advanced repeater
Cache server is operational.
Repair Advanced Repeater This option repairs a corrupted cache on an advanced
Cache repeater server.
Creating rules to determine Application

Servers to use 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
RoutingPolicy.Modify and the BL_Administration.Read authorizations.
2 In the left pane of the Infrastructure Management window, right-click the Job
Execution Rules node and select New Rule. The New Rule wizard opens.
3 In the Rules Management panel, click Add Rule .
4 On the General panel, for Name, enter a name for the job execution rule. For
Description, you can optionally provide descriptive text for the rule. Then click
Next. The Rule Definition panel opens.

Enabling/disabling job routing rule evaluation
5 To create a property condition for the rule, do the following:
A Click Add Property Condition . The Add Property Condition window opens.
B In the first text box on the left, enter a property name or click Select Property
to choose a property from a list.
If you click the Select Property icon, you can view hierarchical properties by
clicking the right arrow that appears next to some properties. This displays a
subordinate list of properties.

contains, equals, does not equal, or starts with.
D Use the next field to the right to specify a property value or range of values.
E Click OK. The Rule Definition panel shows the condition. To edit the condition,
select it and click Edit Selected Condition . To add further conditions, click Add
Property Condition again.
A typical job execution rule condition might be:
(??JOB.NAME?? starts with QA) OR (??JOB.NAME?? starts with DEV)
The order of the conditions determines the order in which the system uses them
to determine Application Servers for the job execution. To re-position a
condition, select the condition and use the Move Up , Move Down , Move to
Top , and Move to Bottom icons.
6 On the Rule Definition panel, click Next to display the Targets panel.
7 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.
8 Click Finish to close the New Rule wizard.
Enabling/disabling job routing rule evaluation

By default, BMC BladeLogic 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.
1 Start the Application Server Administration console.
2 To enable or disable job execution rule evaluation, use the following command:

Creating complex routing rules
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).

Initially, to create rules for interaction with target servers, you use a Routing Wizard.
This wizard sets the default network routing policy and lets you create simple
routing rules based on a single (new) server property. For example, you would use
the Repeater Routing Wizard to create rules for determining the repeater used for
indirect staging to a target server. To add more of these simple rules, you would run
the Routing Wizard again.
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.
2 In the left pane of the Infrastructure Management window, right-click the node for
the routing rules you want to manage; for example, Repeater Routing Rules. Then
select Rules Management from the pop-up menu.
3 In the Rules Management panel, click Add Rule . The New Rule wizard opens
and shows the General panel.

4 On the General panel, for Name, enter a name for the routing rule. For Description,
you can optionally provide descriptive text for the rule. Then click Next. The Rule
Definition panel opens.
5 To create a property condition for the rule, do the following:
A Click Add Property Condition . The Add Property Condition window opens.
B In the first text box on the left, enter a property name or click Select Property
to choose a property from a list.
If you click the Select Property icon, you can view hierarchical properties by
clicking the right arrow that appears next to some properties. This displays a
subordinate list of properties. To return to the parent list, click the left arrow
next to the property at the top of the list.

contains, equals, does not equal, or starts with.
D Use the next field to the right to specify a property value or a range of values.
How you specify a value depends on the type of property and the comparison
operator you have selected.
E 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 following shows a routing rule definition.

Managing routing rules
The order of the conditions determines the order in which the system uses the
conditions to identify target servers. 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.
7 Select servers for the rule. The number of servers you can select depends on the
type of routing rule you are creating:
SOCK proxy routing rules 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.
Repeater routing rule Under Select repeater for this rule, select the repeater to
use for indirect staging to target servers. Click the right arrow, which moves
your selections to the list on the right.
8 Click Finish to close the New Rule wizard.
Managing routing rules

In the Infrastructure Management window, after you use a Routing Wizard to set the
routing policy and create rules for routing, you can use the Rules Management panel
to manage those rules.
You can use the Rules Management panel for:
Viewing and editing routing rules

Changing the order of rule evaluation
Deleting routing rules
For information on setting the routing policy and creating rules with the Network
Routing Wizard, see Creating rules for routing to remote servers on page 669.
For information on setting the routing policy and creating rules with the Repeater
Routing Wizard, see Creating rules to determine the repeater used for target


Use this procedure to view or edit routing rules.
the routing rules you want to edit; for example, Repeater Routing Rules. Then
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
opens to the General tab.
4 In the Modify Rule dialog, click a tab to view or edit its information.
5 Click OK.
Routing rule evaluation

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 on displaying this list and managing
rules, see Managing routing rules on page 687.)
Routing rules of a policy are evaluated in the following ways:
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.
You can view and change the order of routing rules. See Changing the order of
rule evaluation.

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.

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.
the routing rules you want to reorder; for example, Repeater Routing Rules. Then
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

Use this procedure to delete routing rules
the routing rules you want to delete; for example, Repeater Routing Rules. Then

Troubleshooting tools
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.
Troubleshooting tools
BMC BladeLogic 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 BladeLogic environment and package that data
into a zip file.
Diagnostic Services Lets you run predefined tests to evaluate the status of the
BMC BladeLogic environment while it is running and to identify problems.
For information on using these tools, see the BMC BladeLogic Server Automation
Administration Guide.

Chapter
19
Patch management for Microsoft
19
Windows
This chapter describes the patch management process for servers operating on a
Microsoft Windows platform which is based upon standard functionality for BMC
BladeLogic Server Automation described elsewhere within the BMC BladeLogic Server
Auotmation User Guide.
A simplified version of the patching process is as follows:
Published Microsoft Windows patches released by a patch vendor (for example,

Windows 2008 patches released by Microsoft or Acrobat reader patches released
by Adobe Systems) are downloaded and stored on a server. The location in which
these patches are stored, known as a repository, can be created in one of two ways:
Online: The repository is created by direct download from the vendor site.
Offline: In an air-gapped environment, where the servers do not have Internet

access, the repository is created by first downloading to a server outside of the
environment and then transferring that data, via removable storage, to the
repository which is housed on a server within the environment.
The repository is used for analysis, packaging and deployment. For more
information, see Viewing published patches on page 696.
Analyze the target servers to determine the payload that needs to be deployed to
those servers. For more information, see Creating a patching job on page 715.
Roll out patches to servers that need to be patched. BMC BladeLogic creates
BLPackages that contain the missing payload and Deploy Jobs that will remediate
the target servers. (Note that rollout can be automatically performed at the end of
patch analysis or separately, at a later time.)

Defining permissions for the patch catalog
Re-analyze your servers to ensure that each one is at the required patch level.
TIP
Best practice: Set up a small, test group of servers and run the patch process on that group
before branching out to all Microsoft Windows servers in our organization.

In order to create or update a catalog, the patch administrator must be assigned a role
that contains the necessary permissions. To facilitate division of responsibilities,
permissions can be assigned to one role or split between several roles. A patch
administrator for Microsoft Windows should have the following permissions:
Define permissions for Gives the user the ability to

PatchCatalog.* Manage the patch catalog
PatchCatalog.ModifyACL Modify ACLs
PatchCatalog.CreateACL Create ACLs
PatchCatalog.Create Create a new patch catalog
PatchCatalog.Delete Delete a patch catalog
PatchCatalog.Read Open an existing patch catalog
PatchCatalog.Update Add new objects to a patch catalog
PatchCatalog.Modify Modify an existing patch catalog
PatchCatalog.ModifySchedule Schedule a patch catalog update job
PatchCatalog.Cancel Cancel a patch catalog update job
PatchCatalog.ModifyProperties Modify catalog update job properties
PatchSmartGroup.* Patch smart group management
PatchSmartGroup.ModifyACL Modify ACLs
PatchSmartGroup.CreateACL Create ACLs
PatchSmartGroup.Create Create a new patch smart group
PatchSmartGroup.Delete Delete a patch smart group
PatchSmartGroup.Read Open an existing patch smart group
PatchSmartGroup.Write Add new objects to a patch smart group
PatchSmartGroup.Modify Modify an existing patch smart group
WindowsSoftware.*
Server.* (Offline) Access to the server on which the patch
ServerGroup.* repository is located
DepotFile.* If the patch administrator creates a catalog in
offline mode, depot file permissions are needed
to select the metadata files during catalog
creation.
692 Book Title

Defining global configuration parameters
Role and ACL Policy definitions are made using role-based access control. For more
information, see Managing authorizations on page 147.

Global configuration parameters provide basic information that will be automatically
supplied as the default during catalog creation and update as well as during patching
and remediation job creation. These parameters are grouped into two categories: non-
platform specific and platform-specific.
To define global configuration parameters
1 On the Configuration menu, select Patch Global Configuration View and click the
All Operating Systems tab.
2 Enter the following details:
Proxy Setting Options Description

Proxy Server Type Select the type of proxy server used:
SQUID
NLTM
NLTM-V2
None: Select when no proxy server is used.
User Name Enter the user name required to log onto the Proxy Server. If
defined, then the Internet connection will be through the
Proxy Server.
Password Defines the password associated with the defined User Name
required to log onto the Proxy Server.
Domain Defines the domain name of the Proxy Server.
Host Defines the IP Address or Host Name of the Proxy Server.
Port Defines the port number used for communication with the
Proxy Server.
3 Click the Windows tab.

Parameters Description
Catalog Object Processor Defines a default batch size used for parallel processing
Batch Size during a catalog update job. If no value is entered, the default
value is set at 300.
Note: Setting a lower default value speeds up catalog update

but consumes more resources on the BMC BladeLogic
Console; while conversely, setting a higher default value
slows down catalog update but consumes less resources.
Once set, the default value should not be changed unless
Analysis Server Results Batch Defines a default batch size used for parallel processing
Size during a patching job. 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 BladeLogic Console;
while conversely, setting a higher default value slows down
analysis but consumes less resources. Once set, the default
value should not be changed unless specifically required.
Action on Failure During deployment on a target server, if a particular patch
fails to deploy, what should BMC BladeLogic do:
Ignore: Ignore the failure. The Deploy Job continues and

the results show the job as succeeding.
Abort: If defined, end the job and start a rollback.
Continue: Ignore the failure. The Deploy Job continues
and the results show the job as failing.
HTTP/HTTPS/FTP If BMC BladeLogic fails to connect to a vendor site on the
Connection Retry first try, specify the number of attempts made before
reporting failure.
HTTP/HTTPS/FTP Specify the length of time, expressed in milliseconds, that
Connection Timeout BMC BladeLogic will wait before making another attempt to
connect to the vendor site.
Patching to Remediation job Defines a job timeout ratio, patching (x) to remediation (y),
timeout applied to remediation jobs created by the patching job (if
auto-remediation was selected as a job option). The ratio is
defined using the format x:y; BMC BladeLogic recommends
that x > y. In most cases, the user should not change the
default value which is set at zero for both sides of the ratio.
Remediation to Download Defines a timeout ratio, remediation (x) to download (y),
job timeout applied to download jobs created by the remediation job (if
download was included). The ratio is defined using the
format x:y; BMC BladeLogic recommends that x > y. In most
cases, the user should not change the default value which is
set at zero for both sides of the ratio.
694 Book Title

Patching to Remediation job Defines a job part timeout ratio, patching (x) to remediation
part timeout (y), applied to remediation jobs created by the patching job (if
Remediation to Download Defines a job part timeout ratio, remediation (x) to download
job part timeout (y), applied to download jobs created by the remediation job
(if download was included). The ratio is defined using the
Patch deploy success return The Deploy Job sends commands to the operating system
codes which in turn sends responses back to BMC BladeLogic
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 BladeLogic.
Unknown codes entered in this field are defined to BMC
BladeLogic as success return codes.
Patch deploy failure return The Deploy Job sends commands to the operating system
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 BladeLogic. Unknown
codes entered in this field are defined to BMC BladeLogic as
failure return codes.
Patch deploy warning return The Deploy Job sends commands to the operating system
codes which in turn sends warnings back to BMC BladeLogic. In
most cases, standard warnings are used; occasionally, the
operating system uses a return code not known to BMC
BladeLogic. Unknown codes entered in this field are defined
to BMC BladeLogic as warning return codes.
Patch deploy reboot return The Deploy Job sends commands to the operating system
codes which in turn sends back a request for reboot to BMC
BladeLogic. In most cases, standard commands are used;
occasionally, the operating system uses a return code not
known to BMC BladeLogic. Unknown codes entered in this
field are defined to BMC BladeLogic as reboot return codes.
Patch undeploy success During rollback of a patch, the operating system returns an
return codes 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 BladeLogic. Unknown
undeploy success return codes.

Viewing published patches
Patch undeploy failure return During rollback of a patch, the operating system returns an
codes exit code if the action failed. In most cases, standard
undeploy failure return codes.
Patch undeploy warning During rollback of a patch, the operating system may return
return codes a warning. In most cases, standard commands are used;
field are defined to BMC BladeLogic as undeploy warning
return codes.
Patch undeploy reboot return During rollback of a patch, the operating system may send
codes back a request for reboot to BMC BladeLogic. In most cases,
standard commands are used; occasionally, the operating
BladeLogic as reboot return codes
4 Click Save.

The process of deciding which patches available from the vendors need to be applied
to your Microsoft Windows servers is known as patch sourcing and starts with
creation of a patch repository.
A patch repository is a physical location which contains both metadata, downloaded

from the Shavlik Technologies website, and payloads, downloaded from a vendor
website, and housed on a network server. The amount of data contained in the
repository depends on organizational needs ranging from what is missing on a
target server up to all available hotfixes and bulletins.
NOTE
Patch Administrators can use one catalog or several; however, each patching job is associated
with only one catalog.
The patch catalog is how you maintain and work with that repository through the
BMC BladeLogic Console. Patches are added to the catalog as depot objects according
to filters defined for the catalog.
696 Book Title

Defining an online patch catalog
Because a patch catalog can contain a large number of patches, BMC BladeLogic uses
dynamic folders, known as smart groups, to organize the patches in a meaningful
way. During catalog creation, two default smart groups, Hotfixes and Bulletins, are
created (for more information, see Defining a smart group on page 92).
There are two basic types of catalogs:
Online: The repository can be updated directly from the vendor site. For more
information, see Defining an online patch catalog on page 697.
Offline: Download occurs outside of an air-gapped environment, on a server with

Internet access, and transferred to a repository within the environment via
removable storage. For more information, see Defining an offline patch catalog
on page 701.

In an online catalog, metadata is downloaded from the Shavlik Technologies website
and stored in the patch repository. Payload can be downloaded at the same time or
later, depending upon the patch administrators requirements. Download can occur:
as part of patch catalog creation

as part of a scheduled update
during remediation (as a part of auto-remediation or post analysis as a separate
action)
as a standalone action (for more information, see Downloading patches to the
catalog on page 713)
The essential steps required to create an online catalog are as follows:
Define a number of parameters including the location of the patch repository, how
the agent receives the metadata and payload, and so forth.
Define the filters used to screen metadata and payload according to product and
language criteria.
Run the catalog update.

Catalog definition uses a wizard which takes the user through as series of five steps.
To better understand each of these steps, the process has been broken down into a
series of sub-tasks where the end of each task leads directly to the start of the next
sub-task.
Defining catalog parameters

Adding filters
Scheduling updates to the catalog
Defining catalog update job properties
Defining ACL permissions and/or ACL policies

In the following procedure, you establish that the catalog operates in Online Mode
and define several parameters such as file locations (for example, the location where
the metadata and payload are stored on the network), how the target servers receive
data from the repository, permissions assigned by default to objects added to the
catalog, and so forth.
To define catalog parameters
1 Right-click a folder in the Depot and choose New => Patch Catalog => Windows
Patch Catalog.
2 Enter a name and description and then click Next.
Member Of is a read-only field indicating Depot, the location where the new
catalog is placed.
3 In the Catalog Mode section, select Source from Vendor (Online Mode).
4 In Repository Options, enter the following:
Box Description
Windows Helper Server (Mandatory) Browse to or enter the NSH path to a user-
Location defined temporary directory on a Microsoft Windows server.
The temporary directory is used by BMC BladeLogic to
decrypt files downloaded from the vendor site and extract
metadata.
Payload Source Location (Not applicable in Online Mode) The source is assumed to be
(NSH Path) the URL for Shavlik Technologies which is supplied
automatically.
Repository Location (NSH Browse to or enter the NSH path to the location where the
Path) patch repository will be located. This location should have
ample free space since files contained in the repository can
run into gigabytes of data.
698 Book Title

Box Description
Patch Signature File Not applicable for an online catalog where the signature file,
(nfnetchk) either hfnetchk6b.cab or hfnetchk6b.xml, is downloaded
automatically from the Shavlik Technologies website.
Package Info File (pd5) Not applicable in an online catalog where the Package
Information file, either pd5.cab or pd5.xml, is downloaded
automatically from the Shavlik Technologies website.
5 In Depot Object Options, enter the following: :
Box Description
Network URL type for (default) Copy to agent at staging: The BMC BladeLogic
payload deployment* Application Server copies patch payloads to a staging
directory on the target server during the deploy jobs
staging phase. To use this option, the Network URL
option must identify an NSH-accessible directory where
patch payloads are stored.
Agent mounts source for direct use at deployment (no
local copy): A Deploy Job instructs the agent on a target
server to mount the device specified in the URL and
deploy patch payloads directly to the agent. Selecting
this option means the Deploy Job does not copy patch
payloads to a staging area on the agent, so the job does
not create any local copies of the patches on target
servers. To use this option, the Network URL option
must identify an SMB/CIFS path (such as
smb://username:password@hostname/sharename) to
the location where patch payloads are stored. (See also
Network URL for payload deployment.)
Network URL for payload Enter an NSH-accessible path to a location where the payload
deployment* will be available during deployment. A value is entered here
when Agent mounts source for direct use at deployment (no
local copy) is selected in the Network URL type for payload
deployment box.
RBAC Policy Browse to and select a pre-defined ACL Policy. Permissions
defined by the ACL Policy will be assigned to all Depot
Objects created in the catalog.
NOTE
For more information on Network URLs, see URL syntax for network data transmission on
page 362.

6 To download the payload (executables) at the same time as the metadata, select the
Download patches from Microsoft check box.
TIP
You can also download the payload by right-clicking on the catalog and selecting Download.
For more information, see Maintaining an existing catalog on page 712.
Adding filters
Filters are used to limit the amount of information brought into the catalog from the
vendor site. You define a combination of a product and a language (such as Microsoft
Windows 2008 - English). There is no upward limit to the number of filter
combinations you can make but there must be at least one. Only those hotfixes and
bulletins that match the combinations you define will be added to the catalog.
Filters can be defined either when the catalog is created or later, when editing the
catalog (for more information, see Viewing the catalog on the BMC BladeLogic
Console on page 711).
To select a filter
1 Select Add Filter.
2 In the Product box, select a Microsoft product from the list provided.
3 In the Language box, select the appropriate language for the product.
4 Click OK to save the filter.
TIP
Create multiple filters, using any or all of the filter options, to define specifically what content
you want to download into the repository.

You can refresh the patch catalog by scheduling an update job which will use existing
definitions for the patch catalog to retrieve new content from the Shavlik
Technologies website.
Schedules: Scheduling defines how often BMC BladeLogic updates the patch
catalog.
Notifications: BMC BladeLogic can send a notification, either by email or by
SNMP trap, whenever a job completes. The notification will indicate the jobs final
status.
700 Book Title

Defining an offline patch catalog
An update job is run in the background on a predefined time schedule. In a secure

network, where access to the vendor site via the Internet is not possible, that source
location must first be updated prior to the catalog update defined here.
Schedules can be defined either when the catalog is created or later, when editing the
catalog.

A list of standard job properties is displayed. Most are read-only though a few are
available for edit.
Property Description
RESULTS_RETENTION_TIME Expressed in number of days, defines the length of
time that BMC BladeLogic retains a job run and
result information.
MAX_PARALLEL_PER_VM_HOST Defines the maximum number of parallel work
items processed per Virtual Machine host.
AUTO_GENERATED Defines whether the object was auto-generated.
JOB_TIMEOUT Expressed in number of minutes, defines the length
of time a job should run before being automatically
cancelled.
JOB_PART_TIMEOUT Expressed in number of minutes, defines the length
of time that the job part/work item should run
before being automatically cancelled.
To edit a job property, click in the Value column for that parameter and enter
information.

Browse to and select ACL permissions and ACL policies that will grant roles access
for the catalog itself. Note that permissions defined here are not inherited by depot
objects added to the catalog.

In an air-gapped environment, where Internet access is not available to the BMC
BladeLogic, metadata and payload information are first downloaded, using a BMC-
provided utility, to a server with Internet access that is outside of the environment
and not directly available to the BMC BladeLogic Application Server.

The utility downloads information from the Shavlik Technologies website, together
with the patch signature and information files, and places that information on the
server you specify. Once downloaded, the files are transferred to removable storage
and from there, copied into the patch repository, an NSH-accessible location inside
the air-gapped environment.
Once metadata and payload information is transferred to the patch repository within
the air-gapped environment, a patch catalog is created in the BMC BladeLogic
Console. The patch catalog is the representation of the repository within BMC
BladeLogic. The essential steps required to create an offline catalog are as follows:
Define filters for repository content in the configuration file.

Download metadata and payload information using the Patch Downloader utility
provided by BMC BladeLogic.
Add the patch signature file (hfnetchk6b.cab or hfnetchk6b.xml) and the information
file (pd5.cab or pd5.xml) as depot objects to the catalog.
Create a patch catalog and define catalog parameters including the location of the
repository, the location of the patch signature and information files.
During catalog creation, select the same filters used during download to the
repository.
Update the patch catalog.
Downloading patches using the BMC-supplied downloader

The Patch Downloader utility provided by BMC BladeLogic uses configuration
information, which includes a local directory on the server where you are running the
download utility, as well as filters used during download of metadata and payload
from the Shavlik Technologies website. The utility downloads the following files:
Patch Signature File: hfnetchk6.xml

Information File: pd5.xml
The steps to follow are defined in the following procedures:
To prepare the Configuration file on page 703

To download patches using defined filters on page 705
The following additional commands are also available:
For a command that will print out available help files, see To print the
downloader help file on page 705.
For a command that will print out version information of the Patch Downloader
utility, see To print version information for the downloader on page 705.
For a command that will list supported products and languages, see To list
supported products and languages on page 706.
702 Book Title

Before you begin
The patch downloader is available from the BMC Software Electronic Product
Distribution (EPD) site. The downloader is bundled together with a sample
configuration file and is provided in a compressed file format. To install, unzip the
file and place in a directory on the server.
There are no requirements regarding the name used for the configuration file, only
that it be an .XML file and use the format provided in the sample configuration file
(sample-windows-downloader-config.xml).
To prepare the Configuration file
1 Create and open a configuration file.
2 (Optional) Add proxy information using the following syntax:
<protocol></protocol>
<port></port>
<host></host>
<username></username>
<password></password>
<domain-name></domain-name>
<proxy-type></proxy-type>
Parameter Description
<protocol></protocol> Specify the proxy configuration for a protocol. Valid values
are:
http
https
ftp
<port></port> Specify the port used for communication with the proxy
server.
<host></host> Enter the proxy servers host name or IP address.
<username></username> Enter the user name required for authentication prior to
communication with the proxy server.
<password></password> Enter the password associated with the user name identified
in the parameter, <username>.
domain-name></domain- Enter the proxy server domain name which will be used for
name> authentication.
<proxy-type></proxy-type> Define the type of proxy server. Valid values are:
ntlm
ntlm-v2
squid

3 Define a location where files can be stored temporarily during the download
process using the following syntax:
<temporary-location>c:\tmp</temporary-location>
4 Indicate whether the download utility should check the certificate of the patch
payload before download using the following syntax.:
<validate-payload-certificate>true|false</validate-payload-
certificate>
Valid entries are either true or false.
5 Define the local location of the patch repository, where metadata and payload will
be stored, using the following syntax:
<payload-repository-location></payload-repository-location>
6 Indicate the number of attempts the download utility should make if the first
attempt at downloading a payload fails. Use the following syntax:
<download-request-retries></download-request-retries>
7 Indicate the length of time, expressed in milliseconds, that the utility should wait
for a response before considering the attempt has having failed. Use the following
syntax:
<download-request-timeout></download-request-timeout>
This parameter is useful in situations when the http response is slow.
8 Indicate the number of downloads that can be performed in parallel. Use the
following syntax:
<downloader-parallel-threads></downloader-parallel-threads>
9 Modify filters contained in the <subscription> command, which defines patches

that are to be included in the download:
NOTE
The same filters entered here must also be entered during catalog creation; for more
information, see Creating the patch catalog on the BMC BladeLogic Console on page 707.
704 Book Title

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>
TIP
To view a list of supported products and languages, see the procedure To list supported
products and languages on page 706.
10 Save the file.
To download patches using defined filters
On the command line, enter the following command:
windows_downloader.bat -configFile downloaderConfigurationFilePath
downloaderConfiguration Enter the location of the Configuration File used by the patch
FilePath downloader.
NOTE
The BMC-supplied downloader for Microsoft Windows is only supported when run on a
Microsoft Windows server.
To print the downloader help file
windows_downloader.bat -help
To print version information for the downloader
windows_downloader.bat -version

To list supported products and languages
windows_downloader.bat -listProducts
Configuration file
The sample-windows-downloader-config.xml file is shown below including sample
data:
<windows-downloader-config>
<config>
<proxy-settings>
<proxy>
<protocol>http</protocol>
<port>8080</port>
<host>IPAddress</host>
<username>patch</username>
<password>patch</password>
<proxy-type>ntlm</proxy-type>
</proxy>
</proxy-settings>
<validate-payload-certificate>true</validate-payload-
certificate>
<payload-repository-location>d:\repo\windows</payload-
repository-location>
<download-request-retries>10</download-request-retries>
<download-request-timeout>180000</download-request-timeout>
<downloader-parallel-threads>10</downloader-parallel-threads>
</config>
<subscription>
<products>
<include-product>
<product-category>Microsoft Windows Server 2003</product-
category>
<product-category-language>English</product-category-language>
</include-product>
</products>
</subscription>
</windows-downloader-config>
706 Book Title

Creating the patch catalog on the BMC BladeLogic Console

The patch catalog is how you maintain and work with the patch repository through
the BMC BladeLogic Console. The first step is to create the catalog inside BMC
BladeLogic. Catalog definition uses a wizard which takes the user through as series of
three steps. To better understand each of these steps, the process has been broken
down into a series of sub-tasks where the end of each task leads directly to the start of
the next sub-task. These tasks can be performed either through the wizard or later
through the BMC BladeLogic Console:

Adding filters
In the following procedure, enter parameter definitions to establish that the catalog
operates in Offline Mode as well as file locations (for example, the location where the
metadata and payload are stored on the network), how the agent receives data from
the repository, permissions assigned by default to objects added to the catalog, and so
forth.
1 Right-click a folder within the Depot and choose New => Patch Catalog => Windows
Patch Catalog.
catalog is placed.
3 In the Catalog Mode section, select Source from Disk Repository (Offline Mode).

4 In the Repository Options Panel, enter the following:
Box Description
Windows Helper Server Path (Mandatory) Browse to or enter the NSH path to a user-
defined temporary directory on a Microsoft Windows server.
The temporary directory is used by BMC BladeLogic to
decrypt files downloaded from the vendor site and extract
metadata.
Payload Source Location Enter or browse to the location where existing metadata
(NSH Path) and/or payload files are stored. Files stored in this location
will be copied to the catalog automatically.
Payload Repository Location Browse to or enter the NSH path to the location where the
(NSH Path)* patch repository will be located. This location should have
ample free space since the repository will contain a great
many files, usually running into gigabytes of data.
Patch Signature File Location Browse to the depot location of the signature file, either
hfnetchk6b.cab or hfnetchk6b.xml, originally downloaded
from Shavlik Technologies.
Package Info File Location Browse to the depot location on the server of the Information
File, either pd5.cab or pd5.xml, originally downloaded from
Shavlik Technologies.
Box Description
must identify an NSH-accessible network location where
patch payloads are stored. (See also Network URL for
payload deployment.)
708 Book Title

Box Description
deployment box.
NOTE
For more information on URL syntax, see URL syntax for network data transmission on
page 362.
6 To download the payload (executables) at the same time as the metadata, select the
Download patches from Vendor check box.
TIP
You can also download the payload by right-clicking on the catalog and selecting Update
Catalog or by selecting the Download. For more information, see Maintaining an existing
catalog on page 712.
Adding filters
Recreate the same filters defined in the configuration file used by the Patch
Download utility. Only those hotfixes and bulletins that match the combinations you
define will be downloaded.
To select a filter
2 In the Product box, select a Microsoft product from the list provided.
3 In the Language box, select the language used by the products interface and help
files.

TIP

definitions for the patch catalog to retrieve new content from the Shavlik
Technologies website.
catalog.
status.

catalog.
Defining catalog update job parameters

available for edit.
result information.
cancelled.
710 Book Title

Viewing the catalog on the BMC BladeLogic Console
information.


Once created, you can open the Microsoft Windows catalog; a tab for that catalog
appears on the right side of the workspace. At the bottom, of the pane are additional
tabs:
General: Includes the name of the catalog, description and location that were
defined during creation of the catalog. For more information, see Defining an
online patch catalog on page 697.
Windows Catalog: Definitions for catalog type, repository locations, and so forth,
also defined during creation of the catalog. For more information, see Defining an
Schedules: For more information, see Scheduling updates to the catalog on
page 710.
Catalog Job Properties: View and edit catalog job properties such as how long job
run information is stored, the number of work items that can be processed in
parallel, the length of time a job can run before being automatically canceled, and
so forth. For more information, see Defining catalog update job properties on
page 701.
Results: Results of all jobs run using the patch catalog are shown here. For more
information, see Viewing patch catalog update job results on page 713.

Grouping catalog contents

Smart groups are a dynamic means of organizing content within the patch catalog
according to user-defined criteria. This criteria is used to filter content both during
initial creation and later, as new hotfixes and bulletins are added to the catalog. A
newly created patch catalog automatically has three, out-of-the-box, smart groups
predefined:
Bulletins
Hotfixes
Irrelevant Patches
All patches added to your catalog appear in one of these groups. Others can be
created as needed; for example, a smart group could contain all Critical patches.
You can view the contents of a smart group in the left pane or right-click and select
Open to view properties of a particular hotfix or bulletin as well as associated
hotfixes/bulletins.
For more information on smart groups, see Managing BMC BladeLogic resources
on page 84.
Maintaining an existing catalog

For an online catalog, the following procedures help you maintain the catalog.
Choose from one of the following:
Updating an existing catalog

Downloading patches to the catalog
Removing irrelevant patches from an existing catalog

A catalog update downloads and refreshes metadata files downloaded from the
vendor website as well as updating metadata for existing depot objects in the catalog.
Provided the catalog is defined to permit download of payloads during an update
job, payload is also downloaded for newly added patches. Patches that do not match
the filtering criteria are marked as irrelevant.
712 Book Title

A catalog update downloads metadata from the vendor site and updates metadata
for the depot objects in the patch catalog.
TIP
When 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 since
those patches may be referenced in a patching job or by a BLPackage. To clean up the catalog
and remove these patches, right-click the catalog and select Remove Irrelevant Patches.
To update the existing catalog
On the BMC BladeLogic Console, right-click the Microsoft Windows patch catalog
and select Update Catalog.
The catalog refresh job begins using the filter criteria you defined for the catalog.
The Tasks in Progress view shows the current status of the job.
NOTE
For information on how to define criteria for the catalog, see Adding filters on page 700.
Viewing patch catalog update job results
After the patch catalog is updated, you can:
Select a job run. A table is displayed on the right side which lists how many
patches were added, updated, marked as Irrelevant, and downloaded, and failed
to download.
Right-click the job and select Show Log to see log entries made by the application
while the job was running.

If you choose not to download payload at the same time as metadata, you can
download an individual patch or you can use the following procedure to select a
group of patches and initiate download of the payload for those patches where
metadata is already present in the patch catalog.
TIP
Use this procedure when the amount of data to download is significant and would impact
performance. You can elect to schedule the download during off-peak hours or during a
maintenance window.

To download selected patches to the catalog
1 Right-click the patch catalog and choose Download.
2 Enter a name and description and then, click Next.
catalog is placed.
3 In Patch Download Selection, select patches from the list provided (these are patches
where the metadata is already present in the patch catalog).
Patches displayed in this list reflect the smart groups defined in the patch catalog.
NOTE
If you entered this wizard by selecting Download All Missing Patches from Analysis Results,
then this step is eliminated since all patches where metadata exists but there is no payload are
automatically selected.
4 Indicate what notifications you want to be sent out on job completion.
5 Click Next.
6 Choose when you want to run the job:
To run the job immediately, select the Execute Job Now check box.
Click New Schedule to open the Add New Schedule screen. Define the time
interval, time zone, and notification options used every time the job is run.
7 Click Finish.
Viewing download job results
After the patches are downloaded, you can right click the Download Job and select
Show Results. 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.

The clean up process presents a list of patches and their dependencies in the catalog
which are obsolete and require removal.
714 Book Title

Creating a patching job
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 on screen. When dependencies for a particular patch are

discovered, BMC BladeLogic requests instructions. Click OK to remove
dependencies as well or Ignore to keep the dependent patches in the catalog.
3 Click Close.

A patching job performs patch analysis on a group of target servers based on one
patch catalog; you have the option of using the entire catalog or selecting one or more
smart groups from within the catalog. A patching job includes:
Analysis: The patching job checks the configuration of target servers and
determines which patches are needed.
(Optional) Auto-Remediation: The patching job downloads the required payload,
packages the payload as a BLPackage and creates a Deploy Job. Auto-remediation
is often used to patch a newly provisioned server.
To create a patching job
1 In the Jobs folder, navigate to the folder where you want to create a patching job,
right-click and select New => Patching Job => Windows Patching Job.
TIP
You can also right-click a specific server and select Patch Analysis.
2 Define the name and description for the patch analysis job.
The location from which you started the patching job is displayed automatically.
3 In Specify a Catalog, browse to and select a patch catalog.
4 Enter the number of targets to be processed in parallel. Select either:
Unlimited: the job runs on as many target servers as possible.

Limited: Enter the number of target servers on which the job will run in parallel.

5 Determine the User and Role that will execute the job. Choose either:
Set Execution Override: The patching job will always execute as the user,
BLAdmin, and the role, BLAdmins.
Clear Execution Override: The user and role which scheduled the job will be the
one used to execute the job.
6 Click Next.
7 Define patches to include/exclude either by selection from the following options

or by creating a specific Include/Exclude list:
Option Description
Analyze security patches Select to analyze patches that address security
(recommended) vulnerabilities. Analysis is performed against all patches in
the catalog. Patches that are missing from the catalog at the
time when analysis is performed are shown as missing in the
job log.
Analyze security tools Select to analyze patches that help prevent or clean up
malicious software.
Analyze non-security patches Select to analyze performance-related fixes, fixes for known
bugs, and hardware drivers.
Filter out service packs from Select this option if you want to exclude service packs from
result the analysis results.
TIP
If you are uncertain, select from Analyze Security Patches check box only.
Analysis is performed according to your definition; patches that do not match your
criteria are filtered out of the analysis results and are not displayed.
8 (Optional) In Remediation Options, identify when BMC BladeLogic should

remediate servers where patches are missing:
Option Description
Auto Remediate Select when remediation should occur immediately, once
analysis completes. All options displayed are available only
when Auto Remediate is selected.
Packaging Options
Package name prefix Text that is added to all BlPackages and Deploy Jobs created
by the patching job; by default the patching job name is
entered automatically in this box.
716 Book Title

Viewing results of a patching job
Option Description
Save package(s) in Enter or browse to a depot location where the remediation
package created at the end of analysis is stored. By default,
the location where the patching job is stored in the depot is
supplied.
Deploy Job Options
Save batch/deploy job(s) in Enter or browse to the job folder where the remediation and
Deploy Jobs created by the patching job will be stored. By
default, the location of the patching job in the depot is dis-
played.
ACL Policy for Pack- Browse to and select the ACL Policy which will be assigned
age(s)/Deploy Job(s) to each BLPackage, Deploy Job, and Batch Job created by the
patching job.
Deploy Job Options Select a set of pre-defined, parameter definitions that will be
applied to each Deploy Job created by the Patching Job.
9 Click Next.
10 Define the target server list and click Next.
11 Define the default job notifications you want to be sent out on job completion and
click Next.
interval, time zone, and notification options used, instead of the default
notifications defined in the previous step, whenever this job is run.
13 Click Finish.
TIP
Best Practice: Once remediation is complete, run patch analysis again. The second
analysis sometimes reveals other patches that are missing and should also be remedi-
ated.

At the end of a patching job, BMC BladeLogic displays results for the patching job on
the right side of the screen; the display varies depending upon whether auto-
remediation was included for the job.

Viewing analysis results

The results summary show which patches are needed to bring the target servers
defined for the patching job up to standard. For each patching job, results are
provided under the name of the job. Options available within the results view are
listed here and defined in a secondary table:
Run at <date><time> The date and time that the job was run. On the right side of
the pane, additional details are provided; specifically, the job
type and the final status of the job. Right-click on this line
and perform the following actions: Show Job, Delete,
Refresh, Execute Against Failed Targets, Show Log, and
Export Log.
Analysis Run at On the right side of the pane, statistics are displayed. How
<date><time> many missing Bulletins and Hotfixes were discovered during
analysis as well as how many target servers were scanned
and how many were not not scanned. Right-click on this line
and perform one of the following actions: Refresh, Show
Log, or Export Log.
Object View Object View lists every missing patch discovered during
analysis together with architecture, whether the patch is rec-
ommended by Shavlik Technologies website, whether its a
security patch, as well as a description of the patch. Right-
click on any patch within Object View and perform one of the
following actions: Add to Depot As => BLPackage, Deploy
Selected Patches, Download Selected Patches, or Open
Patch.
Server View Server View organizes target servers included in the job
according to two sub-categories, Failed Targets and Success-
ful Targets. Target servers included in the job are grouped
into ranges known as buckets and within these ranges, tar-
get servers are listed individually including the number of
Missing Bulletins, Missing Hotfixes, and final Status. Right-
click on this line or on Failed Targets and perform one of the
following actions: Refresh or Export.
Right-click Successful Targets and select from the following

options: Refresh, Remediate All Servers, or Download All
Missing Patches.
718 Book Title

Actions you can take from this view include:
Action Description
Show Job Opens a read-only view of the job definition including
parameter definitions, analysis options, targets, default noti-
fications, and schedules.
Delete Select to delete run results. Click Delete and the Delete box
opens with a list of selected results. Click OK to delete from
view or Cancel to end task.
Refresh Updates the display for the selected job to reflect the jobs
current status.
Execute Against Failed Tar- Select to run the job again against target servers that returned
gets either warnings, errors or failures. The application displays
the list of failed servers. Select the Create Execution Task
check box and click OK.
Show Log Results are shown on the right side of the workspace. Right-
click the job results and select Show Log. Messages gener-
ated by BMC BladeLogic while the job was running are dis-
played.
Export Log Exports the log as a CSV file to a location on the same com-
puter from which you initiated the Export Log command.
Add to Depot As => BLPack- Select one patch and create a BLPackage for that patch. You
age can select that BLPackage, defined as an object in the depot,
and create a deploy job for that package.
Deploy Selected Patches Define a remediation job that is specifically for the patches
you selected.
Download Selected Patches Select to download payload for a specific set of patches
where only the metadata is present in the patch catalog. .
Open Patch Opens the Depot Software Properties box with a two-page,
read-only description of the metadata for the selected patch.
Remediate All Servers Right-click either the Server view and select Remediate All
Server(s). Installs all missing patches on all target servers
listed in the patching job.
Download All Missing Select to download payload for all patches where only the
Patches metadata is present in the patch catalog.

Remediating servers
Viewing remediation results

An explanation of the remediation results view is shown below and a description of
the available options is shown in a second table. .
Results Description
<jobName> The name of the job is displayed.
Run at <date><time> 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. Right-click on this line
to show two options: Refresh and Show Log.
Action Description
current status.
Show Log Right-click and select Show Log to view information
supplied by BMC BladeLogic during job processing.
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. When you select
the auto-remediation checkbox 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.
To remediate a server
1 At the end of analysis, right-click the patching job and choose Show Results.
2 Under Server View, right-click the server and select Remediate All Server(s).
3 Enter the Name and Description of the Patch Remediation job.
4 If not displayed in the Save In box, enter or browse to the location where the Patch
Remediation job will be stored.
720 Book Title

Remediating servers
5 Determine the user and role that will execute the job. Choose either:
Set Execution Override: The Patch Remediation job will always execute as the
user, BLAdmin, and the role, BLAdmins.
6 Click Next.
7 In Packaging Options, enter the following information:
Option Description
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 or browse to 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.
8 In Deploy Job Options, enter the following information:
Option Description
Save batch/deploy job(s) in Enter or browse to a job folder where the Batch and Deploy
Jobs created by the remediation job will be stored.
ACL Policy for Browse to and select the ACL Policy which will assign pre-
Package(s)/Deploy Job(s) defined permissions to each BLPackage, Deploy Job and
Batch Job created by the remediation job.
applied to each Deploy Job created by the Remediation Job.
9 Click Next.
click Next.
To execute the remediation job immediately, select the Execute Job Now check
box.

interval, time zone, and notification options to be used, instead of the default
NOTE
As part of the Remediation Job, Deploy and Batch jobs are created but those jobs are not
executed immediately as well. Deploy Jobs are executed according to a separate schedule
which often occurs during maintenance windows.
12 Click Finish.

When remediation is run as a separate job, results are displayed on screen; to display
the results, in the Patching Jobs folder, right-click the job and select Show Results. An
explanation of the results view is shown below and a description of the available
options is shown in a second table. .
Results Description
jobName The name of the job is displayed.
Run at date time When you select the first line, basic information about the job
Action Description
current status.
722 Book Title

Deploying patches
Deploying patches
During remediation, a number of deployment jobs are generated and used to apply a
specific set of missing patches to a list of target servers. For each of those jobs, BMC
BladeLogic requires parameter definitions which can be set individually, for each job
(select Deploy Job Options during job definition) or by selecting an existing set of
Deploy Job Options which are used as a template applied to all Deploy Jobs created
during auto-remediation.
NOTE
For more information on Deploy Job parameters, see Phases of a Deploy Job on page 522
and Deploying a BLPackage on page 527.
WARNING
Although an undo option is available for deployed patches, BMC neither supports nor
recommends this action for the Microsoft Windows platform. The undo option, which
depends on platform-specific operating system commands, can compromise the target server.
Deploying patches for Microsoft Office

To successfully deploy patch payload for Microsoft Office, BMC BladeLogic needs to
access a network location containing installation media for Microsoft Office. Because
target servers can be running different versions of Microsoft Office, you may need to
specify a different location for each target server.
Before you begin

Prepare a location on the network where the installation media for Microsoft Office
can be accessed during deployment.
Set up a user name and password that can be used to access the installation media.
To configure servers for Microsoft Office patch deployment
1 In the Servers folder, right-click the target server and select Set Server Properties.
2 In the Name column, select MS_OFFICE_INSTALL_LOCATION and, for Value,

enter the full, UNC formatted, path to the location where the installation media can
be found.
3 In the Name column, select MS_OFFICE_INSTALL_USERNAME, and, for Value,

enter a user name for access to the installation media.

Patch reporting
4 In the Name column, select MS_OFFICE_INSTALL_PWD, and, for Value, enter the
password for the user name defined in the preceding step.
5 Click OK.
TIP
BMC BladeLogic recommends that missing service packs be deployed before beginning hotfix
deployment.
Patch reporting
Live Browse: Use Live Browse to look at installed patches on the server, one server
at a time.
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 and audit basics on page 450.
Reports: For information on patch management reports, see the BMC BladeLogic
Decision Support for Server Automation User Guide.
724 Book Title

Chapter
20
20 Patch management for Solaris
This chapter describes the patch management process for servers operating on either
the Solaris or Fujitsu Solaris platform. Both platforms are based upon standard
functionality for BMC BladeLogic Server Automation described elsewhere within the
BMC BladeLogic Server Automation User Guide.
A simplified version of the patching process for the Solaris platform is as follows.
NOTE
Fujitsu Solaris follows the offline procedure only. Differences between Solaris and
Fujitsu Solaris are clearly marked and apply specifically to repository creation and
preparation of the patchdiag.xref file.
Create a repository that contains the patches and clusters downloaded from the
vendor site. That repository can be created in one of two ways:
Online: (Solaris only) The repository is created by direct download, from the
SunSolve vendor site.

access, the repository is first created by downloading to a server outside of the
environment and then transferring that data, via removable storage, to a
Solaris: Download occurs via a BMC-supplied utility from the Sunsolve

website to a location on the server.
Fujitsu Solaris: Download occurs via a user-supplied utility from the Fujitsu
Solaris support site to a location on the server. Before analysis can begin, the
fjpatchrev.xref file, provided by Fujitsu Solaris, must be converted to a format
usable by BMC BladeLogic (patchdiag.xref).

Best Practice Tips
Analyze the target servers, using metadata extracted from the patchdiag.xref file, to
determine the payload that needs to be deployed to those servers.
the target servers. (Roll out can be automatically performed at the end of patch
analysis or separately, at a later time.)
Best Practice Tips

Set up a small, test group of servers and run the patch process on that group before
branching out to all Solaris servers in the organization.
Create a patch catalog that contains all patches required to bring the target servers
to a specific update level. Then, create a second catalog which contains only new
updates released by Solaris from that point forward.

permissions can be assigned to one role or split between several roles. A patch
administrator for Solaris should have the following permissions:

PatchCatalog.* Patch catalog management
PatchCatalog.Write Add new objects to a patch catalog


SolarisSoftware.*
DepotFile.* If the patch administrator creates a catalog in
offline mode, depot file permissions are needed
to select the metadata files during catalog
creation and to add the patchdiag.xref file to
the catalog.
Role and ACL Policy definitions are made using role-based access control (RBAC).
For more information, see Managing authorizations on page 147.

Global configuration parameters provide basic information that will be auto-
populated during catalog as well as patching and remediation job creation. These
parameters are grouped into two categories: non-platform specific and platform-
specific.
1 On the Configuration menu, select Patch Global Configuration View.
2 Click the All Operating Systems tab.


SQUID
NLTM
NLTM-V2
Proxy Server.
Proxy Server.
4 Click the Solaris tab.
5 Enter the User Name and Password supplied for access to the Sunsolve website.

is set at 100.



Single User Mode and Reboot Enter or browse to the location in the Depot of the file used to
Override file override single user mode and reboot settings for a particular
patch. For more information, see Overriding single user
mode and reboot settings for a patch on page 742.
reporting failure.

Patch undeploy success During rollback of a patch, the operating system returns an
return codes exit code if the action was successful. In most cases, standard
undeploy success return codes.
Patch undeploy failure return During rollback of a patch, the operating system returns an
codes exit code if the action failed. In most cases, standard
undeploy failure return codes.
Patch undeploy warning During rollback of a patch, the operating system may return
return codes a warning. In most cases, standard commands are used;
field are defined to BMC BladeLogic as undeploy warning
return codes.
Patch undeploy reboot return During rollback of a patch, the operating system may send
codes back a request for reboot to BMC BladeLogic. In most cases,
BladeLogic as reboot return codes
6 Click Save.


to your Solaris servers is known as patch sourcing and starts with creation of a patch
repository.
A patch repository is a physical location on a network server which stores the

payload, the executable itself. Payloads can be downloaded at the same time as the
patchdiag.xref file or later, depending upon parameter definition. The amount of data
contained in the repository depends on organizational needs ranging from what is
missing on a target server up to all available patches and/or clusters.
NOTE
Patch Administrators can use one catalog or several. However, each patching job is associated
with only one catalog.
BMC BladeLogic Console. Because a patch catalog can contain a large number of
patches, BMC BladeLogic uses smart groups to organize the patches in a meaningful
way (for more information, see Grouping catalog contents on page 747).
There are two basic types of catalogs:
Online: For the Solaris platform only, the repository can be updated directly from
the Sunsolve website. For more information, see Defining an online patch
Offline:
Solaris: Download occurs outside of an air-gapped environment, on a server

with Internet access, and is then transferred to a repository within the
environment via removable storage. For more information, see Defining an
offline patch catalog for Solaris on page 736.
Fujitsu Solaris: Download occurs using a user-supplied utility from the Fujitsu
Solaris support site to a location on a server. Before analysis can begin, the
fjpatchrev.xref file, provided by Fujitsu Solaris, must be converted to a format
usable by BMC BladeLogic (patchdiag.xref). For more information, see Defining
an offline catalog for Fujitsu Solaris on page 742.


In an online catalog, the patchdiag.xref file is downloaded from the SunSolve website
and stored in the patch repository. Payloads can be downloaded at the same time or
later, depending upon the patch administrators requirements. Download can occur:
as part of patch catalog creation

as part of a scheduled update
during remediation (as a part of auto-remediation or after analysis as a separate
action)
as a standalone action (for more information, see Downloading patches to the
catalog on page 749.)
Define a number of parameters including the source from which you will
download, the location of the patch repository, how the agent receives the payload,
and so forth.
language criteria.
Catalog definition uses a wizard which takes the user through a series of five steps.
sub-task.

Adding filters

In this step, you establish that the catalog operates in Online Mode and define several
parameters such as file locations (for example, the location where the metadata and
payload are stored on the network), how the agent receives data from the repository,
permissions assigned by default to objects added to the catalog, and so forth.

1 On the BMC BladeLogic Console, right-click a folder in the Depot and choose
New => Patch Catalog => Solaris Patch Catalog.
catalog is placed.
3 In the Catalog Mode section, select Source from Sunsolve (Online Mode).
4 In Sunsolve connectivity, enter the User Name and Password used to access the
site.
Box Description
Payload Source Location (Not applicable in Online Mode) The source is assumed to be
(NSH Path) the network URL for the SunSolve website which is supplied
automatically.
Source patchdaig.xref File (Not applicable in Online Mode) The location in the Depot
where the patchdiag.xref file is located.
Metadata Corrections File Enter or browse to the location in the Depot for the file used
to correct errors found in the patchdiag.xref file. For more
information and sample files, see Adding files to the
Override File override single user mode and reboot settings for a particular
patch. For more information, see Adding files to the

Box Description
Network URL type for (Default) Copy to agent at staging: The BMC BladeLogic
directory on the target server during the Deploy Jobs staging
phase. To use this option, the Network URL option must
identify an NSH-accessible directory where patch payloads
are stored.
RBAC Policy Browse to and select a pre-defined ACL policy. Permissions
defined by the ACL policy will be assigned to all depot
objects created in the catalog.
NOTE
page 362.
7 To download payloads (executables) at the same time as the metadata, select the
Download patches from Sunsolve check box.
TIP
You can also download payloads by right-clicking on the catalog and selecting Download.
For more information, see Maintaining an existing catalog on page 748.
Adding filters
vendor site. You define a combination of an operating system and architecture,
specific Patch IDs, or a specific or custom Solaris cluster. There is no upward limit to
the number of filter combinations you can make but there must be at least one. Only
those clusters and patches that match the combinations you define will be added to
the catalog.

To add a filter
2 Select one of the following options which will be used to filter the metadata and
payload downloaded into the repository:
Os-Architecture: Identify a particular operating system and architecture.

Patch Ids: Create a list of specific patch identifiers.
Cluster: Identify a specific, Sunsolve cluster. If the catalog works in offline
mode, you can enter a custom, Solaris cluster.
3 Depending upon 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.
TIP

definitions for the patch catalog to retrieve new content from the SunSolve website.
catalog.
status.

catalog.

Defining an offline patch catalog for Solaris

available for edit.
result information.
cancelled.
information.


For Solaris platforms, use a BMC-provided utility to download the payload and the
patchdiag.xref file to a server outside of the environment which is not directly
available to the BMC BladeLogic Application Server. The utility downloads
information from the SunSolve website and places that information on the server you
specify. Once downloaded the files are transferred to removable storage and from
there, copied into the patch repository, an NSH-accessible location inside the air-
gapped environment.


Download the patchdiag.xref file and payload information using the Patch
Downloader utility provided by BMC BladeLogic.
(Optional) If you need to correct the patchdiag.xref file, prepare an override file (for
more information, see Adding files to the catalog on page 740).
repository.
(Optional) If needed, prepare an XML file to override patch settings in the patchinfo
file to control single user mode and reboot status for a particular patch.
Add the patchdiag.xref, the XML file with sum and reboot settings, as well as the
override file as depot objects to the patch catalog.
Downloading to a Solaris server with Internet access

information, which includes the local path, filters used during download of the
patchdiag.xref file as well as payload files from the SunSolve website.
To prepare the Configuration file on page 738

To download patches for defined filters on page 739
(sample-solaris-downloader-config.xml).

To prepare the Configuration file
1 Locate and open the sample-solaris-downloader-config.xml file.
<port></port>
<host></host>
<port></port> Defines the port number used to communicate with the
proxy server.
<host></host> Defines the IP address or host name of the proxy server.
<username></username> Defines the user name required to log onto the SunSolve
website.
<password></password> Defines the password used to log onto the SunSolve website.
<domain-name></domain- Defines the domain name of the proxy server.
name>
<proxy-type></proxy-type> Select the type of proxy server used:
NLTM
NLTM-V2
Squid
<temporary-location></temporary-location>
4 Define the local location of the payload repository using the following syntax:
6 Indicate the length of time, expressed in minutes, that the utility should wait for a
response before considering the attempt to have failed. Use the following syntax:

7 Indicate number of downloads that can be performed in parallel. Use the following
syntax:
8 Modify filters contained in the <subscription> command, which defines patches

that are to be included in the download:
To create a filter that defines a cluster name, use the following syntax:
<cluster-name></cluster-name>
To create a filter that defines a specific combination of operating system and

architecture, use the following syntax:
<os></os>
<arch></arch>
To create a filter that limits the payload to a specific patch ID or list of patch IDs,
use the following syntax:
<patch-id></patch-id>
9 Save the file.
To download patches for defined filters
1 On the command line, enter the following command:
solaris_downloader.bat/sh solarish_downloader.sh -configFile

downloaderConfigurationFilePath -sunsolveUser sunsolveUserName -
sunsolvePass sunsolvePassword
sunsolveUserName Enter the user name required to log onto the SunSolve
website.
sunsolvePassword Enter the password required to log onto the SunSolve
website.
NOTE
The BMC-supplied downloader for Solaris is only supported when run on a Microsoft Win-
dows, Solaris or Linux server.

The configuration file contains the following settings:
<solaris-downloader-config>
<config>
<proxy-settings>
<port>8080</port>
<username>vpcuser</username>
<password>fr3sca!@#</password>
<domain-name>vpcdc</domain-name>
<proxy-type>ntlm-v2</proxy-type>
</proxy-settings>
<payload-repository-location>d:\tmp\solaris</payload-repository-
location>
<metadata-override-file-path />
</config>
<subscription>
<cluster-filter>
<cluster-name>Solaris 9 SPARC Sun Alert Patch Cluster</cluster-
name>
<cluster-path></cluster-path>
</cluster-filter>
<cluster-filter>
<cluster-name>Java ES Required OS Solaris 10 x86</cluster-name>
<cluster-path />
</cluster-filter>
<os-arch-filter>
<os>9</os>
<arch>x86</arch>
</os-arch-filter>
<os-arch-filter>
<os>9</os>
<arch>sparc</arch>
</os-arch-filter>
<patch-ids-filter>
<patch-id>100287-05</patch-id>
</patch-ids-filter>
</subscription>
</solaris-downloader-config>
Adding files to the catalog

Two files can be used to correct information provided during creation and/or update
of the patch catalog:
Overriding the patchdiag.xref file on page 741

Overriding single user mode and reboot settings for a patch on page 742

For clarity, these files are given a default name which is used throughout the chapter.
However, there is no requirement to use this name. Once prepared, the files must be
added manually to the Depot. For more information on how to add the file, see
Adding files to the Depot on page 409.
Overriding the patchdiag.xref file

As sometimes happens, you might identify errors in the patchdiag.xref file
downloaded from the SunSolve 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;SUNWservic
etagu: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 should be identical to the same entries contained in the
patchdiag.xref file (with corrected information inserted). Entries found in the override
file supersede the corresponding entries in the patchdiag.xref file during creation and
update of a patch catalog. Three 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.

Defining an offline catalog for Fujitsu Solaris
Overriding single user mode and reboot settings for a patch
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). 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>
patch-id>138195-01</patch-id>
reboot-info>rebootnone</reboot-info>
single-user>singleuser</single-user>
</patch>
<patch>
<reboot-info>reconfigimmediate</reboot-info>
<single-user>singleusernone</single-user>
</patch>
<patch>
<reboot-info>reconfigafter</reboot-info>
<single-user>singleuser</single-user>
</patch>
</solaris-sumreboot-info>
Defining an offline catalog for Fujitsu Solaris

The user is responsible for manually downloading patch payloads from the Fujitsu
Solaris support site to a location on a server with Internet access. Along with
payloads, the user must also download the fjpatchrev.xref file. Before analysis can
begin, that file must be converted into the patchdiag.xref file used by BMC BladeLogic
using the procedure described below. Once converted, the files are transferred via
removable storage to the server within the air-gapped environment.
From that point forward, the procedures are the same for both the Fujitsu Solaris and
Solaris platforms.

Before you begin
The script, fj2pdx.pl, is available from the BMC Software Electronic Product
Distribution (EPD) site. The script is located in the Downloaders subdirectory
(Support Files => Downloaders). This script is used to convert the fjpatchref.xref file
into a format that can be used by BMC BladeLogic.
To prepare the patchdiag.xref file
1 On the command line, enter the following command:
perl fj2pdx.pl -i /var/tmp/fjpatchref.xref -o

/var/tmp/patchdiag.xref
-i inputFilePath Enter the NSH path to the input file which is the
fjpatchref.xref file downloaded from the Fujitsu support site.
Generally, the input path is /var/tmp/fjpatchref.xref.
-o outputFilePath Enter the NSH path to location where the patchdiag.xref file,
created by the fj2pdx.pl script, is stored. Generally, the
output path is /var/tmp/patchdiag.xref.

the BMC BladeLogic Console. The first step is to create the catalog inside BMC
BladeLogic. Catalog definition uses a wizard which takes the user through a series of
five steps. To better understand each of these steps, the process has been broken
through the BMC BladeLogic Console.

Adding filters
Defining Catalog Update Job parameters

In the following procedure, enter parameter definitions to establish that the catalog
operates in Offline Mode as well as file locations (for example, the location where the
metadata and payload are stored on the network), how the agent receives data from
the repository, permissions assigned by default to objects added to the catalog, and so
forth.
1 Right-click a folder in the Depot and choose New => Patch Catalog => Solaris Patch
Catalog.
catalog is placed.
3 In Catalog Mode, select Source from Disk Repository (Offline Mode).
Box Description
Payload Source Location Enter or browse to a location where existing metadata
(NSH Path) and/or payload files are stored.
Source patchdiag.xref File (Read Only) Contains the depot location of the patchdiag.xref
file either downloaded from the SunSolve website or, for the
Fujitsu Solaris platform, created using the fj2pdx.pl script.
Metadata Corrections File (Solaris only) Enter the location to the override file used to
correct errors contained in the patchdiag.xref file which you
added to the Depot.
Override File override single user mode and reboot settings for a particular
patch. The default name for this file is sum_reboot.info. For
more information, see Adding files to the catalog on
page 740.

Box Description
Network URL type for (Default) Copy to agent at staging: The BMC BladeLogic
directory on the target server during the Deploy Jobs staging
phase. To use this option, the Network URL option must
identify an NSH-accessible directory where patch payloads
are stored.
RBAC Policy Browse to and select a pre-defined ACL policy. Permissions
defined by the ACL policy will be assigned to all depot
objects created in the catalog.
NOTE
page 362.
Adding filters
Use this procedure to recreate the same filters defined in the configuration file used
by the Patch Downloader utility by specifying one or more combinations of an
operating system and architecture, specific Patch IDs, or a specific or custom cluster.
Filters can be defined during catalog creation or later, when editing the catalog (for
more information, see Viewing the catalog on the BMC BladeLogic Console on
page 747).
To add a filter
2 Select one of the following options which will be used to filter the metadata and
payload downloaded into the repository:
Os-Architecture: Identify a particular operating system and architecture.

Patch Ids: Create a list of specific patch identifiers.
Cluster: Identify a specific Sunsolve cluster. If the catalog will be offline, you
can enter a custom Solaris cluster.
TIP
Create multiple filters, using any or all of the filter options, to match the criteria defined
during initial download.

definitions for the patch catalog to retrieve new content from the SunSolve website.
catalog.
status.

catalog.
Defining Catalog Update Job parameters
available for edit.
result information.
cancelled.
information.


Once created, you can open the Solaris catalog; a tab for that catalog appears on the
right side of the workspace. At the bottom, of the pane are additional tabs:
Solaris Catalog: (Used by Solaris and Fujitsu Solaris) Definitions for catalog type,
repository and file locations, and so forth, also defined during creation of the
catalog. For more information, see Defining an online patch catalog on page 732.
page 735.
so forth. For more information, see Defining Catalog Update Job parameters on
page 746.
information, see Viewing Patch Catalog Update Job results on page 749.

initial creation and later, as new patches and clusters are added to the catalog. A
newly created patch catalog automatically has three smart groups predefined:
Patches, Clusters and Irrelevant Patches. All patches added to your catalog appear in
one of these groups. Others can be created as needed; for example, a smart group
could contain all Critical patches or patches for a particular operating
system/architecture combination.
Open to view properties of a particular Patch or Cluster as well as associated
Clusters/Patches.
on page 84.




This option can be used to create a patch repository provided the patches are
downloaded in .zip, .jar, or .tar.Z format.

job, payload is also downloaded for newly added patches. Patches that do not match
the filtering criteria are marked as irrelevant.
TIP
those patches may be referenced in an analysis job or by a BLPackage. To remove irrelevant
patches from the catalog, right-click the catalog and select Remove Irrelevant Patches.
On the BMC BladeLogic Console, right-click the Solaris patch catalog and select
Update Catalog.
NOTE

Viewing Patch Catalog Update Job results
After the patch catalog is updated, you can:
Right-click the patch catalog and select Open. In Results, select the job. A table is
displayed on the right side which lists how many patches were added, updated,
marked as Irrelevant, and downloaded.
In Results, right-click the job and select Show Log to see log entries made by the
application while the job was running.

If you choose not to download payload at the same time as metadata, you can
download an individual patch or you can use the following procedure to select a
group of patches and initiate download of the payload for those patches where
metadata is already present in the patch catalog.
TIP
Use this procedure when the amount of data to download is significant and would impact
performance. You can elect to schedule the download during off-peak hours or during a
maintenance window.
To download selected patches to the catalog
1 Right-click the patch catalog and choose Download.
catalog is placed.
3 In Patch Download Selection, select patches from the list provided (these are patches
where the metadata is already present in the patch catalog).
NOTE
If you entered this wizard by selecting Download All Missing Patches from Analysis Results,
then this step is eliminated since all patches where metadata exists but there is no payload are
automatically selected.
4 Indicate what notifications you want to be sent out on job completion.
5 Click Next.

interval, time zone, and notification options used every time the job is run.
7 Click Finish.
Viewing Download Job results
After the patches are downloaded, you can right click the Download Job and select
Show Results. 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.


3 Click Close.


1 In the Jobs folder, navigate to the folder where you want to create a patching job,
right-click and select New => Patching Jobs => Solaris Patching Jobs.
2 Define the name and description for the patching job.
The location from which you started the patching job is displayed automatically in
the Save in box.

6 Click Next.
7 In Analysis Options, define patches to include/exclude either by selection from the

following options or by creating a specific Include/Exclude list:
Option Description
Group
Analyze all patches Select to analyze all patches contained in the patchdiag.xref
file.
Analyze Recommended Select to analyze patches that were recommended by the
patches vendor according to information contained in the
patchdiag.xref file.
Analyze Security patches Select to analyze patches that address security
vulnerabilities.
List
Analyze Without Analyze the patches from the Include List without analyzing
Dependencies associated dependencies.

8 Identify when BMC BladeLogic should remediate servers where patches are
missing:
Option Description
Auto Remediate Select when remediation should occur once analysis com-
pletes. All options displayed are available only when Auto
Remediate is selected.
Packaging Options
Package name prefix Text that is added to all BLPackages and Deploy Jobs created
the location where the patching job is stored in the Depot is
supplied.
Deploy Job Options
default, the location of the patching job in the Depot is dis-
played.
ACL Policy for Pack- Browse to and select the ACL policy which will be assigned
patching job.
applied to each Deploy Job created by the patching job.
9 Click Next.
click Next.

13 Click Finish.
TIP
ated.


The results summary show which patches are needed to bring the target servers
Run at <date><time> The date and time that the job was run. On the right side of
the pane, additional details are provided; specifically, the job
type and the final status of the job. Right-click on this line
and perform the following actions: Show Job, Delete,
Refresh, Execute Against Failed Targets, Show Log, and
Export Log.
Analysis Run at On the right side of the pane, statistics are displayed, includ-
<date><time> ing how many missing Clusters and Patches were discovered
during analysis as well as how many target servers were
scanned and not scanned. Right-click on this line and per-
form one of the following actions: Refresh, Show Log, or
Export Log.

ommended by SunSolve website, whether its a security
patch, as well as a description of the patch. Right-click on any
patch within Object View and perform one of the following
actions: Add to Depot As => BLPackage, Deploy Selected
Patches, Download Selected Patches, or Open Patch.
Missing Clusters, Missing Patches, and final Status. Right-

options: Refresh, Remediate All Servers, or Download All
Missing Patches.
Action Description
current status.
played.
age can select that BLPackage, defined as an object in the Depot,
and create a Deploy Job for that package.
Deploy Selected Patches Define a remediation job that is specifically for the patches
you selected.

Remediating servers
Action Description
Download Selected Patches Select to download payload for a specific set of patches
where only the metadata is present in the patch catalog.
Download All Missing Select to download payload for all patches where only the
Patches metadata is present in the patch catalog.
Viewing auto-remediation results

An explanation of the auto-remediation results view is shown below and a
description of the available options is shown in a second table.
Results Description
<jobName> The name of the job is displayed.
Run at <date><time> When you select the first line, basic information about the job
Action Description
current status.
Remediating servers

Remediating servers
6 Click Next.
Option Description
supplied.
Option Description
9 Click Next.

click Next.
box.
NOTE
12 Click Finish.

Results Description
Action Description
current status.

Deploying patches
Deploying patches
NOTE
Patch Reporting
at a time.


Chapter
21
Patch management for Red Hat
21
Enterprise Linux
This chapter describes the patch management process for servers operating on a Red
Hat Enterprise Linux platform. The procedures described are based upon standard
functionality for BMC BladeLogic Server Automation which is described elsewhere
within the BMC BladeLogic Server Automation User Guide.
RPMs, published on the Red Hat Network vendor website, are downloaded and
stored on a server. The location in which these patches are stored, known as a
repository, can be created in one of two ways:
Online: The repository is created by direct download from the Red Hat
Network vendor site.

access, the repository is created by first downloading to a server outside of the
environment and then transferring that data, via removable storage, to the
Analyze your target servers to determine the payload that needs to be deployed to
those servers.
the target servers. (Note that roll out can be automatically performed at the end of
patch analysis or separately at a later time.)

TIP
before branching out to all Red Hat Enterprise Linux servers in our organization.

permissions can be assigned to one patch administrator or split between team
members. A patch administrator for Red Hat Enterprise Linux should have the
following permissions:

LinuxSoftware.*

Role and ACL Policy definitions are made using the role-based access control utility
(RBAC). For more information, see Managing authorizations on page 147.

specific.

SQUID
NLTM
NLTM-V2
Proxy Server.
Proxy Server.
4 Click the RedHat tab.
5 Enter the User Name and Password for access to the Red Hat Network vendor site.


slows down catalog update but consumes less resources. In
most cases, the default value should not be changed.
is set at 100.

analysis but consumes less resources. In most cases, the
default value should not be changed.

Abort: If defined, end the job and start a rollback. Results
show the job as failing.
reporting failure.

7 Click Save.

Patch sourcing refers to the process of downloading all patches for a specified base
version of a channel which need to be applied to Red Hat Enterprise Linux servers.
The process begins with creation of a patch catalog.

A patch repository is a physical location on a network server which contains the

metadata, extracted from downloaded RPMs, errata, and payloads, as well as the
patch executables themselves. Because of platform requirements, RPMs must be
downloaded before analysis can begin. Typically, errata are fetched from the vendor
site; metadata is extracted from the RPM files and prepared for YUM-based analysis.
All of this information is stored in a patch repository which is housed on a network
server.
One patch repository, which could conceivably contain a wide variety of patches,
might be specific to one patch administrator or might be used by a group of patch
administrators. Because a patch catalog can contain a large number of patches, BMC
BladeLogic uses smart groups to organize the patches in a meaningful way on the
BMC BladeLogic Console (for more information, see Grouping catalog contents on
page 783).
BMC BladeLogic Console. RPMs and Errata are added to the catalog as depot objects
according to filters defined for the catalog.
There are two basic types of catalog:
Online: The repository can be updated directly from the vendor site. For more
information, see Defining an online patch catalog on page 764.
Offline: Download occurs outside of an air-gapped environment, on a server with
Internet access, and transferred to a repository within the environment via
removable storage. Fore more information, see Defining an offline patch catalog
on page 769.

An RPM payload is downloaded from the Red Hat Network website; metadata is
extracted from the downloaded content, and stored within the repository. Download
occurs at the time the catalog is set up or as part of a scheduled update but must occur
before analysis begins.
NOTE
Metadata for Errata is retrieved directly from the vendor site.

Define a number of parameters, including the source from which you will
download, the location of the patch repository, how the agent receives the payload,
and so forth.
language criteria.
NOTE
The server which houses the patch repository must have the createrepo and
pythonurlgrabber packages pre-installed before downloading patches into the repository.
Catalog definition uses a wizard which takes the user through as series of five steps.
sub-task.

Adding filters
Defining Catalog Update Job Parameters

In this step, you establish that the catalog operates in Online Mode and define several
parameters such as file locations (for example, the location where the metadata and
payload are stored on the network), how the target servers receive data from the
repository, permissions assigned by default to objects added to the catalog, and so
forth.
Before you begin
Creation of a patch catalog requires that the following packages be pre-installed on

the server that will host the patch repository:
Package Minimum version

createrepo 0.4.6
pythonurlgrabber 2.9.6

1 Right-click a folder in the Depot and choose New => Patch Catalog => RedHat Linux
Patch Catalog.
catalog is placed.
3 In the Catalog Mode section, select Source from Red Hat Network (Online Mode).
4 In Red Hat Network Credentials, enter the User Name and Password supplied by
the vendor and required for access to the site.
Box Description
Metadata and Payload Source (Not applicable in Online Mode) The source is assumed to be
Location (NSH Path) the network URL for the Red Hat Network which is supplied
automatically.
Metadata and Payload Browse to or enter the NSH path to the location where the
Repository Location (NSH patch repository will be located. This location should have
Path)* ample free space since the repository will contain a great
Note: You can copy pre-existing Errata and RPMs manually

into this directory. BMC BladeLogic will not download
duplicate files from the Red Hat Network site.

Box Description
deployment box.
NOTE
page 362
Adding filters
vendor site. You define a combination of Errata Type, Errata Advisory, or Update
level. There is no upward limit to the number of filter combinations you can make but
there must be at least one. Only those RPMs and Errata that match the combinations
you define will be downloaded.
NOTE
You cannot create multiple filters for the same combination of operating system and
architecture.

To select a filter
Red Hat Network is selected automatically.
2 Select a channel from the list provided.
Operating system (OS) and architecture are supplied automatically in read-only

boxes.
3 Select a sort option:
By Errata Type: Choose from Bug Fix Advisory, Product Enhancement Advisory
or Security Advisory.
By Errata Severity: Choose from Critical, Moderate, Important, or Low.
By Update Level
TIP

definitions for the patch catalog to retrieve new content from the RedHat Network
website.
catalog.
status.


catalog.
Defining Catalog Update Job Parameters

A list of standard job properties is displayed. Most are read-only though a few are available for edit.
result information.
cancelled.
information.


In a secure environment, servers have no connection to the Internet. To prepare for
analysis through BMC BladeLogic, RPMs, errata, and payloads must first be
downloaded outside of the air-gapped environment on a server with Internet access.
Once downloaded, the files are transferred to removable storage and from there,
copied into the patch repository, an NSH-accessible location inside the air-gapped
environment.


Download the RPMs, Errata and Update Levels using the Patch Downloader
utility provided by BMC BladeLogic or your own download utility.
repository.
Downloading to a server with Internet access

You can download metadata and payload using the Patch Downloader utility
supplied by BMC BladeLogic or you can use a download utility that you have on
hand. The Patch Downloader utility uses configuration information, which includes
the NSH path to a network location, as well as filters used during download of
metadata and payload from the Red Hat Network website.
NOTE
To prepare the configuration file on page 771

To run the Patch Downloader utility on page 774
The following additional procedures are also available:
For a command which will print out all available Red Hat Enterprise Linux
channels, see To list available channels on page 775.
For a command which will extract RPM packages from the ISOs, see To extract
packages from ISO on page 775.
For a command that will download patches by defined filters, see To download
patches for specific filters on page 775.
For a command that will print out available help files, see To print out help for the
Patch Downloader on page 775.
For a command that will print out version information for the Patch Downloader
utility, see To print out version information for the Patch Downloader on
page 776.

Before you begin


createrepo 0.4.6
(sample-redhat-downloader-config.xml).
To prepare the configuration file
<port></port>
<host></host>
proxy server.
<username></username> Defines the user name required to log onto the Red Hat
Network website.
<password></password> Defines the password used to log onto the Red Hat Network
website.
name>
NLTM
NLTM-V2
Squid

4 Define the location of the patch repository using the following syntax:
syntax:
8 Modify filters, contained in the <subscription> command, that define patches to be

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> Enter the operating system for the channel
label.
<arch></arch> Enter the architecture for the channel label.
<channel-label> Enter the channel label you want to download.
</channel-label>
<errata-severity> Configure filter for metadata download of
</errata-severity> 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 RPM or list of RPMs, use the
following syntax:
<errata-ids-filter>
<os></os>
<arch></arch>
<errata-ids>
<errata-id></errata-id>
</errata-ids>
</errata-ids-filter>
<os></os> Enter the operating system for the channel label.
</channel-label>
<errata-id> Enter a valid Errata ID for the channel label specified in the
</errata-id> filter.

To create a filter that downloads the ISO to the repository, use the following
syntax:
<update-level-filter>
<os></os>
<arch></arch>
<update-level></update-level>
</update-level-filter>
</channel-label>
<update-level> Enter a valid update level for the channel label specified in
</update-level> the filter.
9 Save the file.
To run the Patch Downloader utility
1 Enter the following command:
sh redhat_downloader.sh/redhat_downloader.bat -configFile
downloaderConfigurationFilePath -rhnUser rhnUserName -rhnPass
rhnPassword
NOTE
The BMC-supplied downloader for Red Hat Enterprise Linux is only supported when run on
a Microsoft Windows or Linux server.
Variable Description
rhnUserName Enter the user name required to log onto the Red Hat
Network website.
rhnPassword Enter the password required to log onto the Red Hat
Network website.

To list available channels
redhat_downloader.sh/redhat_downloader.bat -listChannels
To extract packages from ISO
redhat_downloader.sh/redhat_downloader.bat -extractPackagesFromISO -
repoLocation patchRepositoryFilePath -isoLocation isoFilePath -
osArch operatingSystemArchitecture
patchRepositoryFilePath Enter the local location of the patch repository
used by the patch downloader.
isoFilePath Enter the location of the ISO from which RPMs
will be extracted.
operatingSystemArchitecture Enter an operating system/architecture
combination; for example, RHES5x86.
To download patches for specific filters
redhat_downloader.sh/redhat_downloader.bat -configFile
downloaderConfigurationFilePath -rhnUser rhnUserName -rhnPass rhnPassword
rhnUserName Enter the user name required to log onto the Red Hat
Network website.
rhnPassword Enter the password required to log onto the Red Hat
Network website.
To print out help for the Patch Downloader
redhat_downloader.bat/redhat_downloader.sh -help

To print out version information for the Patch Downloader
redhat_downloader.bat/redhat_downloader.sh -version
Configuration file
The sample-redhat-downloader-config.xml file is shown below, including sample data

and parameter descriptions:
<redhat-downloader-config>
<config>
<proxy-settings>
<port>8080</port>
<domain-name />
</proxy-settings>
<payload-repository-location>
</config>

<subscription>
<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>
<os>RHES5</os>
<arch>x86</arch>
<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>RHES5</os>
<arch>x86</arch>
<update-level>5</update-level>
</update-level-filter>
</subscription>
</redhat-downloader-config>
Migrating Vendor Patch Content patch repositories

To use an existing patch repository, created without using the Patch Download utility
supplied by BMC BladeLogic, you will need to define the location where that data is
stored as well as the location where you want to create the repository used by BMC
BladeLogic. 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 BladeLogic 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.

To create a repository
redhat_downloader.sh -createRepo -srcLocation locationOperSysArch -

repoLocation repositoryPath
This command using the following variables:
Command Variable syntax for the command

-srcLocation The location of the metadata and payload you downloaded
from the vendor site, using the following format:
Loc1,os-arch;Loc2,os-arch
Where Loc1 (or Loc2) is a location on a server with

Internet access where the metadata and payload were stored,
and 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.
-repoLocation The local location where the repository, used by BMC
BladeLogic, will be stored.

the BMC BladeLogic. The first step is to create the catalog inside the BMC BladeLogic
Console. Catalog definition uses a wizard which takes the user through as series of
through the BMC BladeLogic Console:

Adding filters

In the following procedure, you establish that the catalog operates in Offline Mode
the metadata and payload are stored on the network), how the agent receives data
from the repository, permissions assigned by default to objects added to the catalog,
and so forth.
1 Right-click a folder in the Depot and choose New => Patch Catalog => RedHat Linux
Patch Catalog.
catalog is placed.
Box Description
Metadata and Payload Source Enter or browse to a location where existing metadata
Location (NSH Path) and/or payload files are stored. Files stored in this location
Metadata and Payload Browse to or enter the NSH path to the location where the
Repository Location (NSH patch repository will be located. This location should have
Path)* ample free space since the repository will contain a great

Box Description
deployment box.
NOTE
For more information on Network URL syntax, see URL syntax for network data
transmission on page 362
Adding filters
repository. Use this procedure to recreate the same filters defined in the configuration
file used by the Patch Downloader utility.
page 782.

To select a filter
Disk Repository is selected automatically.
2 Select a channel from the list provided.
Operating system (OS) and architecture are supplied automatically in read-only

boxes.
3 Select filter type:
Filter Type Options

By Errata Type Bug Fix Advisory
Product Enhancement Advisory
Security Advisory
Errata Severity: Choose Critical, Moderate, Important
and/or Low.
By Errata Advisory Enter an Errata Advisory number and click Add. A list of
added advisories is displayed under Included Items.
By Update Level Enter an Update Level identifier; only one can be included
for each filter.
TIP
definitions for the patch catalog to retrieve new content from the RedHat Network
website.
catalog.
status.


catalog.
available for edit.
result information.
cancelled.
information.

Once created, you can open the Red Hat Enterprise Linux catalog; a tab for that
catalog appears on the BMC BladeLogic Console with the following additional tabs
across the bottom:
Red Hat Enterprise Linux Catalog: Definitions for catalog type, repository and file
locations, and so forth. These values can also defined during creation of the
catalog. For more information, see Defining an online patch catalog on page 764.


page 768.
page 782.
Results: Results of all jobs run using the patch catalog are shown here.

initial creation and later, as new patches, errata, and RPMs are added to the catalog.
A newly created patch catalog automatically has two smart groups predefined:
Erratas and RPMs. All patches added to your catalog appear in one of these groups.
Others can be created as needed; for example, a smart group could contain all Critical
patches or patches for a particular operating system/architecture combination.
Open to view properties of a particular RPM as well as associated Patches.
on page 84.



job, a payload is also downloaded for newly added patches. Patches that do not
match the filtering criteria are marked as irrelevant.

TIP
those patches may be referenced in an analysis job or by a BLPackage. To clean up the catalog
Right-click the Red Hat Enterprise Linux patch catalog and select Update Catalog.
NOTE


3 Click Close.


1 In the Jobs folder, navigate to the folder in which you want to create the patching
job, right-click and select New => Patching Job => Red Hat Patching Job.
TIP
2 Define the name and description for the patching job.

6 Click Next.

7 Select the analysis option. Choose either:
Install Mode:
Update Mode:
8 Define patches to include/exclude by creating a list:
Exclude List: Define a list of RPMs and Errata to exclude either by selecting
from the following options or by creating a specific Exclude List:.
Include List: For an Include List, specify a list of Errata or RPMs that should be
included in analysis.
TIP
If you are uncertain, select from analysis options only.
9 (Optional) Identify when BMC BladeLogic should remediate servers where patches
are missing:
Option Description
Packaging Options
supplied.
Deploy Job Options
played.
patching job.

10 Click Next.
click Next.
14 Click Finish.
TIP
ated.


The results summary shows which patches are needed to bring the target servers
provided under the name of the job. Options are available within the results view and
Run at date time The date and time that the job was run. On the right side of
the pane, additional details are provided such as the job type
and the final status of the job. Right-click on this line and per-
form the following actions: Show Job, Delete, Refresh, Exe-
cute Against Failed Targets, Show Log, and Export Log.
Analysis Run at date time On the right side of the pane, statistics are displayed includ-
ing how many missing RPMs and patches were discovered
scanned and how many were not not scanned. Right-click on
this line and perform one of the following actions: Refresh,
Show Log, or Export Log.
ommended by RedHat Network website, whether it is a secu-
rity patch, as well as a description of the patch. Right-click on
any patch within Object View and perform one of the follow-
ing actions: Add to Depot As => BLPackage, Deploy
Selected Patches, or Open Patch.
Missing RPMs, Missing Patches, and final Status. Right-click
on this line or on Failed Targets and perform one of the fol-
lowing actions: Refresh or Export.

options: Refresh, Export or Remediate All Servers.
Action Description
current status.

Action Description
played.

Results Description
Action Description
current status.

Remediating servers
Remediating servers
6 Click Next.
Option Description
supplied.

Remediating servers
Option Description
9 Click Next.
click Next.
box.
NOTE
12 Click Finish.


Results Description
Action Description
current status.
Deploying patches
NOTE
WARNING
recommends this action for the Red Hat Enterprise Linux platform. The undo option, which

Patch reporting
Patch reporting
at a time.


Patch reporting

Chapter
22
Patch management for SUSE Linux
22
Enterprise
This chapter describes the patch management process for servers operating on a
SUSE Linux Enterprise platform. The procedures described are based upon standard
Create an offline repository that contains the RPMs downloaded from the vendor
site. In an air-gapped environment, where the servers do not have access to the
Internet, the repository is created by first downloading to a server outside of the
environment. The data is transferred via removable storage to the repository
which is housed on a server within the environment.
those servers.
TIP
before branching out to all SUSE Linux Enterprise servers in your organization.


members. A patch administrator for SUSE Linux Enterprise should have the

LinuxSoftware.*
Role and ACL Policy definitions are made using the role-based access control utility
(RBAC). For more information, see Managing authorizations on page 147.


specific.

SQUID
NLTM
NLTM-V2
Proxy Server.
Proxy Server.
4 Click the SUSE Linux tab.


slows down catalog update but consumes less resources. In
most cases, the default value should not be changed.
is set at 100.

analysis but consumes less resources. In most cases, the
default value should not be changed.

Abort: If defined, end the job and start a rollback. Results
show the job as failing.
reporting failure.

5 Click Save.

to your SUSE Linux Enterprise servers is known as patch sourcing and starts with
creation of a patch catalog.

metadata, extracted from downloaded RPMs and payload, as well as the patch
executables themselves. Because of platform requirements, RPMs must be
downloaded before analysis can begin. All of this information is stored in a patch
repository which is housed on a network server.

Defining a patch catalog
One patch repository, which could conceivably contain a wide variety of patches,
might be specific to one patch administrator or might be used by a group of patch
administrators. Because a patch catalog can contain a large number of patches, BMC
BladeLogic uses smart groups to organize the patches in a meaningful way on the
BMC BladeLogic Console (for more information, see Grouping catalog contents on
page 811).
The patch catalog is how you maintain and work with that repository through BMC
BladeLogic Console. RPMs are added to the catalog as depot objects according to
filters defined for the catalog.

An RPM payload is downloaded prior to analysis; for SUSE Linux Enterprise servers,
this procedure is always done using the BMC-supplied patch download utility to an
NSH-accessible location on a network server known as the patch repository.
In a secure environment, where the servers have no connection to the Internet, RPMs
and payloads must first be downloaded outside of the air-gapped environment on a
server with Internet access. Once downloaded, the files are transferred to removable
storage and from there, copied into the patch repository.

Download the RPMs using the Patch Downloader utility provided by BMC
BladeLogic.
repository.
NOTE
pythonurlgrabber packages pre-installed before downloaded patches into the repository.


information, which includes the NSH path to a network location, as well as filters
used during download of metadata and payload from the SUSE Linux Enterprise
website.

The following additional procedures are also provided:
For a command that will download patches by defined filters, see To download
patches for specific filters on page 804.
page 804.
Before you begin


createrepo 0.4.6
(sample-suse-downloader-config.xml). For more information, see Configuration file
on page 805.

<port></port>
<host></host>
proxy server.
<username></username> Defines the user name required to log onto the SUSE Linux
Enterprise website.
<password></password> Defines the password used to log onto the SUSE Linux
Enterprise website.
name>
NLTM
NLTM-V2
Squid

response before considering the attempt has having failed. Use the following
syntax:
syntax:
8 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:
<os-arch-filter>
<os></os>
<arch></arch>
<url></url>
</os-arch-filter>
<os></os> Enter the operating system for the channel
label.
<url></url> Enter the URL for the vendor site.
<username></username> Enter the user name assigned for access to the
vendor site.
<password></password> Enter the password for the user name required
to access the vendor site.
9 Save the file.
sh suse_downloader.sh -configFile downloaderConfigurationFilePath
NOTE
The BMC-supplied downloader for SUSE Linux Enterprise is only supported when run on a
Microsoft Windows or Linux server.

suse_downloader.sh -extractPackagesFromISO -repoLocation

patchRepositoryFilePath -isoLocation isoFilePath -osArch
operatingSystemArchitecture
patchRepositoryFilePath Enter the local location of the patch repository
used by the patch downloader.
isoFilePath Enter the location of the ISO from which RPMs
will be extracted.
operatingSystemArchitecture Enter an operating system/architecture
combination; for example, SLES10x86.
To download patches for specific filters
suse_downloader.sh/suse_downloader.bat -configFile
downloaderConfigurationFilePath
downloaderConfigurationFilePath Enter the location of the patch repository used
by the patch downloader.
suse_downloader.bat/suse_downloader.sh -help
suse_downloader.bat/suse_downloader.sh -version

Configuration file
The sample-suse-downloader-config.xml file is shown below:
<suse-downloader-config>
<config>
<proxy-settings>
<port>8080</port>
<host>ipAddress</host>
<domain-name />
</proxy>
</proxy-settings>
</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>


suse_downloader.sh -createRepo -srcLocation locationOperSysArch -

EXAMPLE
suse_downloader.sh -createRepo -srcLocation /repo/suse_repo_repo1.SLES10-
x86;/repo/suse_repo2,SLES9-x86 -repoLocation /repo/suse_new_repo


Internet Access where the metadata and payload was stored
of information.

the BMC BladeLogic. The first step is to create the catalog inside the BMC BladeLogic
the next sub-task.

Adding filters


and so forth.
1 Right-click a folder in the Depot and choose New => Patch Catalog => SuSE Linux
Patch Catalog.
catalog is placed.
Option Description
Metadata and payload source Enter or browse to a location where existing metadata
location (NSH path) and/or payload files are stored. Files stored in this location
If the user specifies an offline source, that is not created or

converted into an 8.0 source by patch downloaders (for
example, vendor-supplied DVD), then the user should only
specify a single filter for the catalog. This filter identifies the
source and creates a repository location using the operating
system and architecture supplied by the filter definition.
Specifying more than one filter results in BMC BladeLogic
Console being unable to identify the source.
Metadata and payload Browse to or enter the NSH path to the location where the
repository location (NSH patch repository will be located. This location should have
path)* ample free space since the repository will contain a great

Box Description
deployment box.
NOTE
transmission on page 362.
Adding filters
page 811.

To select a filter
2 For OS Flavor, select an operating system/architecture combination from the list

provided.
Operating system (OS) and architecture are supplied in read-only format.
TIP

definitions for the patch catalog to retrieve new content from the SUSE Enterprise
Linux website.
catalog.
status.

catalog.


available for edit.
result information.
cancelled.
information.



Once created, you can open the SUSE Linux Enterprise catalog; a tab for that catalog
tabs:
defined during creation of the catalog. For more information, see Defining a patch
SUSE Linux Enterprise Catalog: Definitions for catalog type, repository and file
locations, and so forth. also defined during creation of the catalog. For more
information, see Defining a patch catalog on page 800.
page 809.
page 810.
Results: Results of all jobs run using the patch catalog are shown here.

initial creation and later, as new patches and RPMs are added to the catalog. A newly
created patch catalog automatically has one smart group predefined: RPMs. All
patches added to your catalog appear in this group. Others can be created as needed;
for example, a smart group could contain all Critical patches or patches for a
particular operating system/architecture combination.
on page 84.


For an offline catalog, the following procedures help you maintain the catalog.


A catalog update will regenerate metadata for the depot objects in the patch catalog.
TIP
those patches may be referenced in an analysis job or by a BLPackage. To clean up the catalog
Right-click the SUSE Linux Enterprise patch catalog and select Update Catalog.
NOTE



3 Click Close.

(Optional) Auto-Remediation: The patching job packages the payload as a
BLPackage and creates a Deploy Job.
job, right-click and select New => Patching Jobs => SUSE Patching Job.

6 Click Next.
Install Mode
Update Mode

8 Create an Include/Exclude list:
Exclude List: Define a list of RPMs to exclude either by selection from the
following options or by creating a specific Exclude List.
Include List: For an Include List, specify a list of RPMs that should be included
in analysis.
TIP
9 Identify when BMC BladeLogic should remediate servers where patches are
missing:
Option Description
Packaging Options
supplied.
Deploy Job Options
played.
patching job.
10 Click Next.

click Next.
14 Click Finish.
TIP
ated.
15 Viewing results of a patching job

provided under the name of the job. Options are available within the results view and
scanned and how many were not scanned. Right-click on this
line and perform one of the following actions: Refresh, Show
Log, or Export Log.

ommended by SUSE Enterprise Linux website, whether it is a
security patch, as well as a description of the patch. Right-
click on any patch within Object View and perform one of the
following actions: Add to Depot As => BLPackage or Open
Patch.
Missing RPMs, Missing patches, and final Status. Right-click
on this line or on Failed Targets and perform one of the fol-
lowing actions: Refresh or Export.

Action Description
current status.
played.

Action Description

Results Description
Action Description
current status.
Remediating servers
Remediation is the process of applying the patches determined to be missing on one
or more target servers in order to bring those servers up to the required level. When
you select the auto-remediation check box during patching job definition, the process
of packaging and deploying the payload is handled automatically according to a

Remediating servers
1 At the end of analysis, right-click the patching job and choose Results.
6 Click Next.
Option Description
supplied.
Option Description
Save batch/deploy job(s) in Enter or browse to a job folder where the batch and deploy
jobs created by the remediation job will be stored.
Deploy Job Options Select a set of pre-defined parameter definitions that will be

Remediating servers
9 In Deploy Job Properties, enter the following information:
Option Description
Results Retention Time Expressed in number of days, defines the length of time that
BMC BladeLogic retains a job run and result information.
Max_Parallel_Per_VM_Host Defines the maximum number of parallel work items
processed per Virtual Machine host.
Job_Timeout Expressed in number of minutes, defines the length of time a
job should run before being automatically cancelled.
Job_Part_Timeout Expressed in number of minutes, defines the length of time
that the job part/work item should run before being
automatically cancelled.
Deploy_Job_URL_Copy_ Expressed in number of seconds, defines the length of time a
Timeout URL copy command should run before being automatically
cancelled.
Deploy_Job_NSH_CMD_ Expressed in seconds, defines the length of time a NSH
Timeout command should run before being automatically cancelled.
10 Click Next.
click Next.
box.
NOTE
13 Click Finish.


Results Description
Action Description
current status.
Deploying patches
Patch deployment, when handled separately from the patching job, is similar to other
Deploy Jobs. During remediation, a number of deployment jobs are generated and
used to apply a specific set of missing patches to a list of target servers. For each of
those jobs, BMC BladeLogic requires parameter definitions which can be set
individually, for each job, or as a template which can be applied globally to every job.
Deploy Job Options can be copied from an existing Deploy Job; however, schedules
can never be copied between jobs.
NOTE
WARNING
recommends this action for the SUSE Linux Enterprise platform. The undo option, which

Patch Reporting
Patch Reporting
at a time.


Patch Reporting

Chapter
23
Patch management for Oracle
23
Enterprise Linux
This chapter describes the patch management process for servers operating on an
Oracle Enterprise Linux platform. The procedures described are based upon standard
Create an offline repository that contains the RPMs downloaded from the vendor
site. In an air-gapped environment, where servers do not have access to the
Internet, the repository is created by first downloading to a server outside of the
environment. The data is then transferred via removable storage to the repository
which is housed on a server within the environment.
those servers.
TIP
before branching out to all Oracle Enterprise Linux servers in your organization.


members. A patch administrator for Oracle Enterprise Linux should have the

LinuxSoftware.*
Role and ACL Policy definitions are made using role-based access control (RBAC).
For more information, see Managing authorizations on page 147.


specific.

SQUID
NLTM
NLTM-V2
Proxy Server.
Proxy Server.
4 Click the Oracle Enterprise Linux tab.


is set at 100.


reporting failure.

indicating that the commands succeeded. This field instructs
BMC BladeLogic to interpret the given exit code(s) as a
success.
In most cases, standard commands are used; occasionally,

the operating system uses a return code not known to BMC
to BMC BladeLogic as success return codes.
indicating that the commands failed. This field instructs BMC
BladeLogic to interpret the given exit code(s) as a failure.

to BMC BladeLogic as failure return codes.
codes which in turn sends warnings back to BMC BladeLogic. This
field instructs BMC BladeLogic to interpret the given exit
code(s) as a warning.
In most cases, standard warnings are used; occasionally, the

BladeLogic. This field instructs BMC BladeLogic to interpret
the given exit code(s) as a request for a reboot.

to BMC BladeLogic as reboot return codes.
5 Click Save.

to your Oracle Enterprise Linux servers is known as patch sourcing and starts with
creation of a patch catalog.


metadata, extracted from downloaded RPMs, and payload, as well as the patch
executables themselves. Because of platform requirements, RPMs must be
downloaded before analysis can begin. All of this information is stored in a patch
repository which is housed on a network server.
One patch repository could conceivably contain a wide variety of patches; perhaps
specific to one patch administrator or used by a group of patch administrators.
Because a patch catalog can contain a large number of patches, BMC BladeLogic uses
smart groups to organize the patches in a meaningful way on the BMC BladeLogic
Console (for more information, see Grouping catalog contents on page 839).
The patch catalog is how you maintain and work with that repository through BMC
BladeLogic Console. RPMs are added to the catalog as depot objects according to
filters defined for the catalog.

In a secure environment, where the servers have no connection to the Internet, RPMs
and payloads must first be downloaded from the vendor site outside of the air-
gapped environment. Download always occurs prior to analysis using a BMC-
supplied patch download utility. Once downloaded, the files are transferred to
removable storage and from there, copied into the patch repository.
After transfer to the patch repository, a patch catalog is created in the BMC
BladeLogic Console, which is the representation of the repository within BMC

Download the RPMs and Update Levels using the Patch Downloader utility
provided by BMC BladeLogic.
Create a patch catalog and define catalog parameters, including the location of the
repository.
NOTE


information, which includes the NSH path to a network location, as well as filters
used during download of metadata and payload from the Oracle website.

The following additional procedures are also provided:
For a command that will print out all available Oracle Enterprise Linux channels,
see To list available channels on page 832.
page 833.
Before you begin


createrepo 0.4.6
(sample-oel-downloader-config.xml). For more information, see Configuration file on
page 833.

<port></port>
<host></host>
proxy server.
<username></username> Defines the user name required to log onto the Oracle
Enterprise Linux website.
<password></password> Defines the password used to log onto the Oracle Enterprise
Linux website.
name>
<proxy-type></proxy-type> Select the type of proxy server used. Choose either:
NLTM
Squid

7 Indicate the number of downloads that can be performed in parallel. Use the
following syntax:
8 Modify the <subscription> command to create a filter that downloads the latest
RPMs according to operating system, architecture and channel combinations. Use
the following syntax:
<os-arch-filter>
<os></os>
<arch></arch>
<channel-label></channel-label>
</os-arch-filter>
</channel-label>
9 Save the file.
sh oel_downloader.sh -configFile downloaderConfigurationFilePath -

oelUser oelUserName -oelPass oelPassword
oelUserName Enter the user name required to log onto the Oracle
oelPassword Enter the password required to log onto the Oracle

NOTE
The BMC-supplied downloader for Oracle Enterprise Linux is only supported when run on a
Microsoft Windows or Linux server.
To list available channels
oel_downloader.sh/oel_downloader.bat -listChannels -oelUser

oelUserName -oelPass oelPassword
oelUserName Enter the user name required to log onto the Oracle
oelPassword Enter the password required to log onto the Oracle
oel_downloader.sh -extractPackagesFromISO -repoLocation

patchRepositoryFilePath -isoLocation isoFilePath
-osArch operatingSystemArchitecture
patchRepositoryFilePath Enter the local location of the patch repository used by the
patch downloader.
isoFilePath Enter the location of the ISO from which RPMs will be
extracted.
operatingSystemArchitecture Enter an operating system/architecture combination; for
example, OELES5x86.
oel_downloader.bat/oel_downloader.sh -help

oel_downloader.bat/oel_downloader.sh -version
Configuration file
The sample-oel-downloader-config.xml file is shown below:
<oel-downloader-config>
<config>
<proxy-settings>
<port>8080</port>
<host>ipAddress</host>
<domain-name />
</proxy>
</proxy-settings>
</config>
<subscription>
<os-arch-filter>
<os></os>
<arch></arch>
<channel-label></channel-label>
</subscription>
</oel-downloader-config>


oel_downloader.sh -createRepo -srcLocation locationOperSysArch -

EXAMPLE
oel_downloader.sh -createRepo -srcLocation /repo/oel_repo1,OEL5-
x86;/repo/oel_repo2,OEL4-x86 -repoLocation /repo/oel_new_repo


Internet Access where the metadata and payload was stored
of information.

BMC BladeLogic. The first step is to create the catalog inside the BMC BladeLogic
the next sub-task.

Adding filters


and so forth.
1 Right-click a folder in the Depot and choose New => Patch Catalog => OEL Linux
Patch Catalog.
catalog is placed.
3 In the Catalog Mode section, select Source from Disk Repository (Offline Mode).
Box Description
Metadata and payload source Enter or browse to a location where existing metadata
location (NSH path) and/or payload files are stored. Files stored in this location
If the user specifies an offline source that is not created or

converted into an 8.0 source by patch downloaders (for
example, a vendor-supplied DVD), then the user should only
specify a single filter for the catalog. This filter identifies the
source and creates a repository location using the operating
system and architecture supplied by the filter definition.
Specifying more than one filter results in BMC BladeLogic
Console being unable to identify the source.
Metadata and payload Browse to or enter the NSH path to the location where the
repository location (NSH patch repository will be located. This location should have
path)* ample free space since the repository will contain a great

5 In Depot Object Options, enter the following:
Box Description
directory on the target server during the Deploy Jobs
patch payloads are stored.(See also Network URL for
deployment box.
Object Policy Permissions Browse to select a pre-defined ACL Policy. Permissions
Objects created in the catalog.To create an ACL Policy, use
the RBAC Manager.
NOTE
transmission on page 362.
Adding filters
more information, see Adding filters on page 836).

To select a filter
2 In OS Flavor, select from the list provided.
Operating system (OS) and Architecture are supplied automatically in read-only

boxes.
TIP

definitions for the patch catalog to retrieve new content from the Oracle website.
catalog.
status.

catalog.


available for edit.
result information.
cancelled.
information.



Once created, you can open the Oracle Enterprise Linux catalog; a tab for that catalog
tabs:
defined during creation of the catalog. For more information, see Defining a patch
Oracle Enterprise Linux Catalog: Definitions for catalog type, repository and file
locations, and so forth. These values can also defined during creation of the
catalog. For more information, see Defining a patch catalog on page 828.
page 837.
page 838.
information, see Viewing results of a patching job on page 843 and Viewing
remediation results on page 848.

initial creation and later, as new patches and RPMs are added to the catalog. A newly
created patch catalog automatically has two smart groups predefined: RPMs and
Irrelevant Patches. All patches added to your catalog appear in the RPMs group.
Others can be created as needed; for example, a smart group could contain all patches
for a particular operating system/architecture combination.
on page 84.


The following procedures help you maintain the catalog. Choose from one of the
following:


A catalog update regenerates metadata files for existing depot objects in the catalog.
TIP
those patches may be referenced in an analysis job or by a BLPackage. Instead, those patches
appear in the Irrelevant Patches smart group. To clean up the catalog and remove these
patches, right-click the catalog and select Remove Irrelevant Patches.
Right-click the Oracle Enterprise Linux patch catalog and select Update Catalog.
NOTE



3 Click Close.

(Optional) Auto-Remediation: The patching job packages the payload as a
BLPackage and creates a Deploy Job.
job, right-click and select New => Patching Jobs => Oracle Enterprise Linux Patching
Job.
TIP


6 Click Next.
Install Mode:
Update Mode:
8 Create an Include/Exclude list:
Exclude List: Define a list of RPMs to exclude either by selection from the
following options or by creating a specific Exclude List:.
Include List: For an Include List, specify a list of RPMs that should be included
in analysis.
TIP
9 (Optional) Identify when BMC BladeLogic should remediate servers where patches
are missing:
Option Description
Packaging Options
supplied.
Deploy Job Options
played.

Option Description
patching job.
10 Click Next.
click Next.
14 Click Finish.
TIP
ated.


scanned and not scanned. Right-click on this line and per-
form one of the following actions: Refresh, Show Log, or
Export Log.
analysis, together with its architecture, whether the patch is
recommended by the Oracle website, whether it is a security
patch, as well as a description of the patch. Right-click on any
patch within Object View and perform one of the following
actions: Add to Depot As => BLPackage or Open Patch.
into ranges known as buckets and, within these ranges, tar-
get servers are listed individually, including the number of
Missing Bulletins, Missing Hotfixes, and final Status. Right-

Action Description
current status.

Action Description
played.
age can select that BLPackage, defined as an object in the Depot,

Results Description
Action Description
current status.

Remediating servers
Remediating servers
Remediation is the process of applying the patches determined to be missing on one
or more target servers in order to bring the identified target servers to up to the
required level. When you select the auto-remediation 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.
6 Click Next.
Option Description
jobs created during remediation. By default, the remediation
job name is entered automatically in this box.
location where the remediation job is stored in the Depot is
supplied.

Remediating servers
Option Description
ACL Policy for Browse to and select the ACL policy which will assign pre-
Deploy Job Options Select a set of pre-defined parameter definitions that will be
applied to each Deploy Job created by the remediation job.
9 Click Next.
click Next.
box.
NOTE
As part of the remediation job, Deploy and Batch jobs are created but those jobs are not
12 Click Finish.


Results Description
Action Description
current status.
Deploying patches
Patch deployment, when handled separately from the patching job, is similar to other
Deploy Jobs. During remediation, a number of deployment jobs are generated and
used to apply a specific set of missing patches to a list of target servers. For each of
those jobs, BMC BladeLogic requires parameter definitions which can be set
individually, for each job, or as a template which can be applied globally to every job.
Deploy Job Options can be copied from an existing Deploy Job; however, schedules
can never be copied between jobs.
NOTE
WARNING
recommends this action for the Oracle Enterprise Linux platform. The undo option, which

Patch reporting
Patch reporting
at a time.


Patch reporting

Chapter
24
24 Provisioning basics
BMC BladeLogic provisioning performs unattended installations of operating
systems onto new machines (bare metal machines) or re-provisions existing
machines. Provisioning is primarily intended for use with servers rather than desktop
machines. BMC BladeLogic provisioning supports the RAID system of data storage,
and it incorporates existing vendor tools for formatting disks. To provision operating
systems onto new machines, you run a Provision Job. For provisioning higher layers
of the server stack above the operating system, you can run jobs that configure server
settings, deploy files, and install software.
BMC BladeLogic uses the following provisioning technologies:
Pre-boot Execution Environment (PXE)for provisioning Windows and Linux

servers.
Designed to work in conjunction with established protocols like DHCP, TFTP, and
TCP/IP, BMC BladeLogics PXE-based approach to provisioning allows Intel-
based 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.
Sun Microsystems JumpStart softwarefor provisioning Solaris servers.
Designed to work with established protocols like NIS, NIS+, and DHCP, the BMC
BladeLogic JumpStart integration lets SPARC and x86-based computers boot from
the network using the BOOTP protocol, and communicate with JumpStarts boot,
config, and install servers for remote provisioning.
IBM Network Installation Manager (NIM) softwarefor provisioning AIX

servers.
Integrates with existing NIM environments for remote provisioning. Key NIM
resources utilized in the provisioning process include Shared Product Object Tree
(SPOT), lpp_source, mksysb, script, fb_script, resolve_conf, and bosinst_data.
Hewlett-Packard Ignite softwarefor provisioning HP-UX servers.

Supported operating systems
Integrates with existing Ignite environments for remote provisioning. Key Ignite
resources utilized in the provisioning process include the Ignite master server,
Ignite boot helper server, config files, INDEX file, and INSTALLFS.
Supported operating systems

BMC BladeLogics provisioning solution is available for SPARC, Intel, and PA-RISC
architectures and can provision the following operating systems:
Windows
Linux
VMware
Solaris
AIX
HP-UX
For detailed information on supported operating systems and versions, see the
Product Availability and Compatibility Matrix available at
http://www.bmc.com/support/reg/bladelogic-compatibility-tables.html.
Understanding provisioning
The following sections provide a general overview of the BMC BladeLogic
provisioning steps for supported provisioning technologies.
Provisioning Windows and Linux servers: PXE environment

Provisioning Solaris servers: JumpStart environment
Provisioning AIX servers: NIM environment
Provisioning HP-UX servers: Ignite environment

target machine
being provisioned
1
DHCP Server
3
database
PXE / TFTP Server
4 5
6
database
Application Server
7 8
9
HTTP or SMB Server
10
11
BMC BladeLogic
console
12
12

1 Prepare the Target Machine being Provisioned
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 provides the
target machine with instructions to either boot from its local disk or a boot image
obtained via TFTP. 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 BladeLogic
Application Server for instructions.
8 Provisioning Server Checks Database
Using the MAC Address of the target machine, the Provisioning Server checks its
database to obtain instructions for the target machine.

9 Provisioning Server Delivers Provisioning Instructions
Based on information obtained from the database, the Provisioning 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 Provisioning 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 BladeLogic. A registration event occurs to enter the target
machines information into BMC BladeLogic system so the server can be managed
from the BMC BladeLogic console.
12 Provisioning runs Batch Job for additional provisioning
Optionally, provisioning 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.

BMC BladeLogic environment JumpStart environment SPARC target being provisioned
BMC BladeLogic
1 console
3
boot
JumpStart boot
server
create system package
define data store instance
import target device
start provisioning job 4
2
obtain
config files
JumpStart config
server
obtain OS files and run

JumpStart install installer
server
6
BMC BladeLogic install agent
console 7
Batch Job for additional
configuration
Preparation: Prepare the target machine being provisionedinstall all necessary

cabling and make sure the OpenBoot PROM and the network card on the machine
to be provisioned are up to date.
Solaris x86 only: configure the target machines BIOS to boot to the network.

1 Create System Package and Data Store Instance, Import Device:
Create a system package that contains all the instructions needed 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 the system package includes a reboot script.
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 BladeLogic system by importing the device.
2 Run the Provisioning Wizard
The provisioning wizard launches a provisioning job. The provisioning 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.
Pushes all necessary JumpStart control files including sysidcfg, profile, and rules
to the JumpStart config server.
3 JumpStart Server Causes Target Device to Reboot
After registering the target and pushing JumpStart scripts, the provisioning 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 install server installs the RSCD agent, which is necessary
for managing the server with BMC BladeLogic. A registration event occurs to enter
the target machines information into the BMC BladeLogic system so the server can
be managed from the BMC BladeLogic console.
7 Provisioning Runs Batch Job for Additional Configuration
Optionally, the provisioning process can run a job that performs additional
configuration of the target machine. For example, a Batch Job can install and
configure all necessary applications on the target machine.
BMC BladeLogic environment Target being provisioned NIM master
BMC BladeLogic
1 console
2
import target device 3
start provisioning job
5
Application Server
Batch Job for

additional
configuration
BMC BladeLogic
7 6
console

1 Create System Package and Data Store Instance, Import Device, Run Provisioning
Wizard:
A Create a system package that contains all the instructions needed to install an
operating system over the network.
B Create a data store instance that points to the location of a data store, which is
systems.
C Register the target devices MAC address (and optional additional information)
D Run the provisioning wizard to launch a provisioning 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 BladeLogic Application Server.
5 Application Server Monitors Operating System Installation
The BMC BladeLogic 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 BladeLogic. A registration event occurs to enter the
target machines information into the BMC BladeLogic system so the server can be
managed from the BMC BladeLogic console.

BMC BladeLogic environment Target being provisioned Ignite master
BMC BladeLogic
1 console
2
import target device 3
start provisioning job
5
Application Server
Batch Job for

additional
configuration
BMC BladeLogic
7 6
console

1 Create System Package and Data Store Instance, Import Device, Run Provisioning
Wizard:
A Create a system package that contains all the instructions needed to install an
operating system over the network.
B Create a data store instance that points to the location of a data store, which is
systems.
C Register the target devices MAC address (and optional additional information)
D Run the provisioning wizard to launch a provisioning job.
2 Reboot the Target
If your provisioning 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 BladeLogic Application Server.
5 Application Server Monitors Operating System Installation
The BMC BladeLogic 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.

Integrated provisioning and server management
Optionally, the Ignite master installs the RSCD agent, which is necessary for
managing the server with BMC BladeLogic. A registration event occurs to enter the
target machines information into the BMC BladeLogic system so the server can be
managed from the BMC BladeLogic console.
Integrated provisioning and server management

The BMC BladeLogic system integrates provisioning with BMC BladeLogic 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 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.
Overview of the provisioning process

Use the following procedure as a process flow to provision servers.
1 Set up your provisioning environment, as described in Part one: preliminary

setup (PXE, JumpStart, NIM, Ignite) on page 863.
2 Depending on your provisioning technology, complete the provisioning process

by following the instructions in one of the following sections:
Part two: running the provisioning process (PXE) on page 864
Part two: completing the provisioning process (JumpStart, NIM, Ignite) on

page 864

Part one: preliminary setup (PXE, JumpStart, NIM, Ignite)
Part one: preliminary setup (PXE, JumpStart, NIM, Ignite)

Use this procedure for the preliminary setup of your environment.
1 Set up a provisioning system, by doing the following:
A Install all components of the provisioning system, as described in the BMC

BladeLogic Installation Guide.
B Use RBAC to do the following:
Grant the appropriate level of access to the different 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 machines might be assigned to another role that
is granted limited access. This role might only be granted the ability to
perform all actions related to provisioning.
Grant roles access to servers that are supposed to be provisioned.
For more information on RBAC, see Chapter 6, Managing access.
C Set up post-provisioning jobs.
After a system package installs an operating system and the RSCD agent, it can
also run a job to perform additional configuration on the server and install
software. For more information on setting up jobs used by system packages, see
Including a Batch Job in a system package on page 924.
D Configure provisioning so it works with the other components in the

You must configure provisioning to establish a connection to the data store and
other functional software components. For more information, see Configuring
provisioning on page 902.
2 Create system packages.
System packages are a consistent, logical way to represent the values passed to the
operating system installer. Optionally, a system package can also run a job to
further configure the server. You should set up a different system package for each
type of server you plan to provision. For more information, see Creating a system
package on page 925.

Part two: running the provisioning process (PXE)
3 Depending on which provisioning technology you are using, continue this

procedure by following the instructions in one of the following sections:

Part two: completing the provisioning process (JumpStart, NIM, Ignite)

Use this procedure to run the provisioning process for your environment.
1 Make sure you have completed the first set of steps outlined in Part one:
preliminary setup (PXE, JumpStart, NIM, Ignite) on page 863.
2 Connect a machine to be provisioned to your network.
3 Configure the boot order in the BIOS so the machine network boots first.
4 Reboot the server.
The server boots to the network and then waits for provisioning instructions. At
this point the server becomes visible in the Devices folder of the BMC BladeLogic
console.
5 Create and run a Provision Job to apply a system package to the server you want to
provision.
For more information, see Creating a Provision Job on page 1024.
The unattended installation begins. You can monitor its progress in the BMC
BladeLogic console. For more information, see Managing jobs in progress on
page 427.
Part two: completing the provisioning process (JumpStart,

NIM, Ignite)
Use the following procedure to complete the provisioning process in your
environment.
1 Make sure you have completed the steps outlined in Part one: preliminary setup
(PXE, JumpStart, NIM, Ignite) on page 863.
2 Import the target device into the BMC BladeLogic system.

For more information see Manually importing a device on page 1007 and
Manually importing a list of devices on page 1011.
3 Power on the target device.
4 Create and run a Provision Job, which applies a system package to the server you
want to provision. For more information, see Creating a Provision Job on
page 1024.
If your system package includes a reboot script, the target device automatically
reboots from the network. If your system package does not include a reboot script,
you must arrange to reboot the target by other means:
JumpStart:
Solaris:
Enter the boot monitor program (OpenBoot PROM) on the target device. You
can do this by a human operator or telnet/ssh script. Once in OpenBoot
PROM, issue the command:
boot net - install
to force a network reboot.
(For more verbose output during provisioning, use boot net -v install.)
x86:
You need to either configure the target machines BIOS to boot from the
network, or change the boot order on the target by running Suns ipmitool to
change the boot order before rebooting the target.
NIM: 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.
Ignite: Reboot the target by doing one of the following things:
Run the bootsys command, using the following syntax:
bootsys -a targetMachineName
for example, bootsys -a itanium1
On the booting menu, select network boot on an active LAN device.

The unattended installation begins. You can monitor its progress in the BMC
BladeLogic console. For more information, see Managing jobs in progress on
page 427.

Chapter
25
25 Provisioning servers
Provisioning servers can be divided into several main areas of functionality. The
following sections reflect that functionality:
Creating boot image files on page 868 describes how to create boot image files
that you can use when provisioning devices.
Configuring provisioning on page 902 describes how to set up your system so it

integrates with other functional components of the provisioning process, such as
the data store.
Creating a system package on page 925 describes how to set up a system

package, which is a collection of all the instructions necessary to provision a server
with an operating system and perform additional configuration by running a job.
Organizing system packages on page 1005 provides procedures that describe

how to organize system packages in the Depot folder and how to copy, cut, paste,
and delete system packages and system package folders.
Creating a Provision Job on page 1024 describes how to create and execute a
Provision Job, which applies a system package to one or more servers and
performs an unattended installation of the operating system.
Working with manually imported devices on page 1006 describes how to

administratively add devices to the BMC BladeLogic system, before the devices
boot up. This can automate and streamline the provisioning process.
Monitoring the provisioning status of servers on page 1019 describes how to

keep track of servers that have not yet been provisioned and servers that have
already been provisioned.
Managing Provision Jobs on page 1032 describes how to execute and view the
results of Provision Jobs, view and export job logs, add and delete devices from
existing jobs, and re-provision servers.

Creating boot image files
Properties and provisioning on page 1056 describes how to refer to device and
system package properties within system package definitions.
Creating boot image files

To provision a machine, you must create a BMC BladeLogic-specific boot image file.
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 WinPE image file. See:
Creating a WinPE 2.x boot image file
Creating a WinPE 1.6 image file

Linux machines Gentoo Linux image file. See Creating a Gentoo
Linux image file.
In addition, if you want to use any of the system packages you created in earlier BMC
BladeLogic releases, you need to obtain a DOS image file. See Obtaining a DOS
image file on page 902, for more information.

Boot image files and placeholders
Boot image files and placeholders

Once you create these image files and put them in the correct places on the TFTP
server, you can use the default placeholders built into the system. These placeholders
let you specify which image file you want to use for a given device. For example, if
you add a device, a drop-down menu appears, asking you which boot image file you
want to use:
blade.img
gentoo32
gentoo64
Skip Linux Pre-Install
VMware Server ESXi 4.0 image for x64 devices
WindowsPE_2_x_Image
WindowsPE_2_x_x64_Image
WindowsPE_2_x_ISO_Image
WindowsPE_2_x_x64_ISO_Image
WindowsPE_1_6_Image
WindowsPE_1_6_x64_Image
These placeholder choices become operational only after you create the
corresponding image files and place these files on the TFTP server, as described in
Creating a WinPE 2.x boot image file on page 869, Creating a Gentoo Linux image
file on page 898, and Obtaining a DOS image file on page 902.
NOTE
You cannot configure the Skip Linux Pre-Install image to set it as the default image
type. For information about the Skip Linux Pre-Install image, see Using the Skip
Linux Pre-Install image on page 901.

Use this procedure to set up a machine for WinPE 2.x image file creation and create
the image file.
1 Prepare the machine on which you plan to create the WinPE image. See Preparing
a machine for image creation.
2 Create image files using one of the following methods:
The image creation wizard. (See Creating WinPE 2.x image files using the
image creation wizard on page 872.)

The CreateWinPE2_x.vbs script. (See Creating WinPE 2.x image files using the
BMC BladeLogic script on page 878.)
3 Copy the image files to the appropriate location for provisioning. (See Copying
image files to a location for provisioning on page 884.)
Preparing a machine for image creation

Before you create the image file, you must prepare the machine on which you will be
creating the image file 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 only going to use the image creation tool, some of
these steps do not apply (and are so noted).
To prepare the machine:
1 Download and install Microsoft Core XML Services (MSXML) 6.0. (You can get
this from the Microsoft Web site.)
2 Download Windows Automated Installation Kit (WAIK). (You can get this from
the Microsoft Web site.) Note that this is a very large file and may take a while to
download.
To create WinPE 2.0 images, download WAIK 1.0.

To create WinPE 2.1 images, download WAIK 1.1.
3 Use an image file editor (such as WinImage) to:
A Open the WAIK image file. The image file should have a name that looks
something like this:
vista_6000.16386.061101-2205-LRMAIK_EN.img
B Extract the winpe.cab file to the desktop.
C If you are using an x86 machine, extract the waikx86.msi file and use it to install
WAIK.
If you are using an AMD64 machine, extract the waikamd64.msi file and use it to
install WAIK.
4 Locate the BMC BladeLogic file:

current_release-provision-files.zip
You can get this file the same way you get external-files.zip. For detailed
information, see the BMC BladeLogic Installation Guide.
Copy this file to a directory on the machine where you installed WAIK, for
example C:\BMC_BL.
5 Unzip provision-files.zip.
This file unzips to create the following subdirectory:
\provisioning\winpe
6 If you are using the Provisioning image creation tool, and not the script, to create
boot image files, you can begin image creation. (See Creating WinPE 2.x image
files using the image creation wizard on page 872).
If you are using the script to create boot image files and you want 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.
7 (Applies only to using the script to create boot image files.) Find the following files:
CreateWinPE2_x.vbs
extractpxeboot.bat
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.bat are located here:

C:\BMC_BL\provisioning\winpe\CreateWinPE2_x.vbs
C:\BMC_BL\provisioning\winpe\extractpxeboot.bat
8 (Applies only to using the script to create boot image files.) Copy
CreateWinPE2_x.vbs and extractpxeboot.bat to the WAIK installation subdirectory:
\Tools\PETools
For example:
C:\Program Files\WinAIK\Tools\PETools
Creating WinPE 2.x image files using the image creation

wizard
Use this procedure to create WinPE 2.x x86 or x64 boot image files using the image
creation wizard.
Prerequisites:
Prepare the machine on which boot images will be created. See Preparing a
machine for image creation on page 870.
If you plan to create image files for booting from media local to the target server,
create a network.ini file. For information, see Creating a network.ini file on
page 877.
To create the WinPE boot image:
1 Select Configuration => Provisioning Image Creation.
2 In the Toolkit Select window, provide information on the type of image you are
creating and the location of the image creation tools,
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. For information about roles and permissions, see
Chapter 6, Managing access.

Image Type: Specifies the method of creation and format of the WinPE 2.x image
you want to create. Select one or more types.
PXE Image: Creates a WinPE 2.x 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 a WinPE 2.x image in ISO format (bootImageName.iso) for
booting from media connected to the target server.
UFD Image: Creates a WinPE 2.x 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 Windows Automated
Installation Kit (WAIK) directory. Type the path or click Browse to select the
directory. For example: C:\Program Files\WinAIK\Tools\PETools
CreateWinPE 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 path to the directory for the new image
files. The image creation process uses the name of last directory in the path as
the image name.
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 information about roles and permissions, see
Chapter 6, Managing access.
How you specify the Boot Image Target Directory depends on the image types
you selected:
PXE image typeIf this the only image type you selected, specify the Boot
Image Target Directory in either of these ways:

Select Use TFTP Root as base directory to specify that tftproot on the tftp server
be used as the base directory, and in the text box type the directory under
tftproot in which you want the image file created. If the kernel image has a
name other than boot_2_0, the system creates a placeholder for the custom
image. This placeholder appears on the Image Files tab of the Provisioning
Configurations window.
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/boot_2_0_x64
ISO or UFD image typeIn 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:
NOTE
Spaces are not supported in the boot image name. (The boot image name is last
directory in the Boot Image Target Directory Path).
3 Click Next.
The Driver Selection window opens. It is optional to provide information in this

window. Provide information only if you want to inject drivers into the WinPE
image.
If you already have a Driver.txt file that contains paths to the .inf driver files you
want to inject into the image, for Open Driver.txt file, click Browse to select
your Driver.txt.
The paths contained in Driver.txt appear in the large Driver Files panel in the
middle of the window.
If you want to add additional drivers, click Add to open the Select Driver
Files dialog and browse for and select drivers. Click OK when you are done
selecting the drivers.
NOTE
The path to the Driver.txt file may contain spaces. However, the paths to .inf driver files
may not contain spaces.

If you want to create a new Driver.txt file that contains all the drivers shown in
the Driver Files panel, click Save new Driver.txt file. Then do one of the
following:
Type in 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 where you want to save this new Drivers.txt
file. Add the file name to the path in the edit box under Save new Driver.txt,
for example:
//myComputerHostname/myDriversFile/Driver.txt
4 Click Next. The Custom Script window opens.
It is optional to provide information in this window. Provide information if you

want to run an external script when the image is mounted; otherwise, click Next.
Specify an external script using one of the following methods:
Click Browse to select the script file in the Select Custom Script dialog. Click
OK after selecting the file.
Type the script in the text box.
5 Click Next. The Configuration Details window opens.
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.
Network Details: 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). You would
specify this file if the provisioning environment does not contain a DHCP
server. For information about creating this file, see Creating a network.ini file
on page 877.
Click Browse to select the network.ini file.
This step is optional; you do not have to select the file.
If you select a network.ini file, the image creation process copies the network.ini
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 serverif there
is no DHCP server present in the provisioning environment.
When you run the Provision Job, it searches for the network.ini file at the root of
the local media. If no network.ini file is present there, it allows the DHCP server
to provide network details dynamically. If no DHCP server is present, the
Provision Job prompts you for those details.
NOTE
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.
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 DataStore: 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 CONFIG_STORE. (For information, see
The CONFIG_STORE property on page 1052.) 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 you want 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 you
want 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.
6 Click Finish to begin image file creation.
A progress dialog informs you that the image file creation is running. When it
completes, the script execution log appears in the dialog.
Creating a network.ini file

The network.ini file provides network details for each target server (static IP address,
subnet mask, default gateway, WINS server, and DNS servers). You would use this
file in provisioning environments where there is no DHCP server, for example,
environments 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
[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 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.x image files using the BMC BladeLogic

script
You can create WinPE 2.x x86 or WinPE 2.x x64 boot image files by running the
CreateWinPE2_x.vbs script.
To create a WinPE image with this script:
1 Create the input file containing image creation parameters. See Creating the input
parameters .ini file.
2 Run the CreateWinPE_2_0.vbs script to create the image files. See Running the
CreateWinPE2_x.vbs script on page 883.
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 884.

Creating the input parameters .ini file
You create the input parameters file to provide to the CreateWinPE2_x.vbs script with
parameters for the boot image, for example: 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

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.exe and rscd.iss files.

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 Y to copy these files to the root of the WinPE ISO.

This is the default.
Specify 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. See Creating a network.ini

file on page 877.
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 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 N to suppress generation of the files.

CreateISOFlag (Local boot image only) Specifies whether to generate ISO
boot files for the image.
Specify 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 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 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 N to suppress generation of UFD files. (This is the

default.)
WAIKRootDir Specifies a path to the 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 Y to display this information.
Specify N to suppress the display of this information. (This

is the default.)

Example 1: WinPE image for booting from the PXE server
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
Example 2: WinPE image for booting from local media
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
Use this procedure to create a WinPE 2.x x86 or x64 image file by running the
Prerequisites
Prepare the machine on which you will create the image files. See Preparing a
machine for image creation on page 870.
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.
If you plan to create image files for booting from media local to the target server,
create a network.ini file. For information, see Creating a network.ini file on
page 877.
To run the script, 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

Use this procedure to copy WinPE 2.x image files to the location where the
provisioning process can use them. The location to which you copy files depends on
the image type of the WinPE image you created.
For image files of the PXE image type, do the following:
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 on page 884.
2. Extract the boot files and copy them to the TFTP server. See Extracting boot
files for PE 2.x images on page 885.
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 2.x security settings on
page 886.
For image files of the ISO image type, 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.
For image files of the UFD image type, do the following:
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
(For image files of the PXE image type)
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
information, see Creating WinPE 2.x image files using the BMC BladeLogic script
on page 878.)

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:
\boot_2_0
BCD
boot.sdi
WinPE.wim
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
Extracting boot files for PE 2.x images
Use the following procedure to extract the pxeboot.0 and bootmgr.exe files and copy
them to the TFTP server.
1 Create a temporary local directory that will hold 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 Windows AIK installation directory. For example:
3 Start the WinPE command prompt by typing:
pesetenv.cmd
4 Run the extractpxeboot.bat 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 2.x security settings
If the server that contains your data store does not support the following Microsoft
NT Lan Manager (NTLM) settings:
NTLMv2 Level 3
then use the following procedure to change the NTLM settings for the WinPE image
on the TFTP server.
Prerequisite: The TFTP server must have the following software installed:
Microsoft Windows Automated Installation Kit (WAIK)
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:
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.
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 next step assumes that no LMCompatibilityLevel value currently exists, and
so you need to add it. However, if you already have an LMCompatibilityLevel
value, simply edit it to match the settings shown below.
Choose 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

Use this procedure to use the CreateWinPE1_6.bat script to set up a machine for WinPE
1.6 image file creation and create the image file. ISO

1 Prepare the machine on which you plan to create the image. See Preparing a
machine for WinPE 1.6 image creation.
2 Create image files using the CreateWinPE1_6.bat script. See Creating a WinPE 1.6
image file using the script on page 893.
Preparing a machine for WinPE 1.6 image creation

Before you create the image file, you must prepare the machine on which you will be
creating the image file by installing required software and ensuring that files are in
the appropriate locations.
Use this procedure to set up a machine for WinPE 1.6 image file creation and create
the image file.
1 Download the Microsoft Windows Pre-installation Environment (WinPE) 2005 on

the machine where you will be creating the image file and copy the files into a
directory. (The appropriate license is required to acquire this from Microsoft.)
The instructions in this section use the following the default directory as the
location for the files:
C:\BMC_BL\WinPE_1.6
After you copy the files, you should see the following subdirectories: DOCS,
EXAMPLES, I386, PROGRAM FILES, SAMPLES, and WINPE.
2 Download and install Microsoft Windows XP Embedded with SP 1 Tool Kit on the
machine where you will be creating the image file. (You can get this from the
Microsoft Web site.) Use the instructions in Installing Microsoft Windows XP
Embedded SP1 Tool Kit on page 891 for this installation.
3 Download and install Microsoft Windows Server 2003 Resource Kit on the
machine where you will be creating the image file using the following steps:
A Download the product from the Microsoft Web site.
This downloads the rktools.exe file.
B Locate the rktools.exe file from where you downloaded it and run it to begin the
installation.
C When the installation is complete, reboot the computer.
The default installation directory is:
C:\Program Files\Windows Resource Kits

4 Download the following installation media based on your image file creation
needs:
For 32-bit image creation, download the Microsoft Windows Server 2003 SP1
installation media on the machine where you will be creating the image file.
For 64-bit image creation, download Windows XP SP2 64-bit installation media
on the machine where you will be creating the image file.
You can get these from the Microsoft Web site.
Download them to any location you choose on the machine where you will be
creating the image file.
An example location for Microsoft Windows Server 2003 SP1 (for 32-bit image
creation) is
C:\ENGLISH\32BIT\STANDARD_WITH_SP1_VLP
An example location for Microsoft Windows XP SP2 64-bit (for 64-bit image
creation) is
C:\ENGLISH\64BIT\STANDARD_WITH_SP2_VLP
In the image creation instructions, this directory is referred to as the Windows ISO
path.
5 Locate the following BMC BladeLogic provisioning file:
current_release-provision-files.zip
Copy this file to a directory on the machine where you installed the software in the
previous steps. For example, you might copy it to a directory named C:\BMC_BL.
6 Unzip provision-files.zip.
This file unzips to create the following subdirectory:
\provisioning\winpe
7 If you want to inject drivers into the WinPE image, create a text file called Driver.txt
and put this file in the directory where you put Microsoft Windows Pre-
installation Environment (WinPE) 2005 during step 1. Using the default location
from those instructions, you would put Driver.txt in the following location:

C:\BMC_BL\WinPE_1.6\WINPE\Driver.txt
Add the following line to the Driver.txt file
Drivers=<full_path_to_INF_driver> <full_path_to_INF_driver> ...
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.
8 Find the following files:
CreateWinPE1_6.bat
DrvLetter.vbs
extractstartrom.bat
MountSDI.vbs
SDIDrive.vbs
These files are located in the provisioning\winpe subdirectory that was created
when you unzipped provision-files.zip. For example, if you placed provision-
files.zip in C:\BMC_BL and unzipped to that same location, CreateWinPE1_6.bat is
located in the following place:
C:\BMC_BL\provisioning\winpe\CreateWinPE1_6.bat
All of the other files are also in
9 Copy the CreateWinPE1_6.bat, DrvLetter.vbs, extractstartrom.bat, MountSDI.vbs, and

SDIDrive.vbs files to the WINPE directory that was created as the default location
for Microsoft Windows Pre-installation Environment (WinPE) 2005 during step 1:
C:\BMC_BL\WinPE_1.6\WINPE
For example, you would copy CreateWinPE1_6.bat to
C:\BMC_BL\WinPE_1.6\WINPE\CreateWinPE1_6.bat
Copy all other files to this location as well.

10 Use CreateWinPE1_6.bat to create image files, then copy these files to the TFTP
server (see Creating a WinPE 1.6 image file using the script on page 893).
11 Extract the ntldr, ntdetec.com, and startrom.0 files and copy them to the TFTP server,
as described in Extracting boot files for WinPE 1.6 images on page 898.
12 By default WinPE supports the following Microsoft NT Lan Manager (NTLM)

settings:
NTLMv2 Level 3
If the server that contains your data store has incompatible NTLM settings, you
need to change the NTLM settings for the WinPE image on the TFTP server, as
described in Configuring WinPE 2.x security settings on page 886.
Installing Microsoft Windows XP Embedded SP1 Tool Kit

Use these instructions to download and install the Microsoft Windows XP Embedded
SP1 Tool Kit. The tool kit is available from the Microsoft Web site. Note that the
download link on the Web site refers to SP2, but when you run the download file, you
can choose to install SP1.
The instructions in this section highlight choices that are important to make for the
BMC BladeLogic installation.
1 Download the product from the Microsoft Web site.
This downloads the XPEFFI.exe file.
2 Locate the XPEFFI.exe file from where you downloaded it and run it.
3 Click Run to confirm.
4 Make the following selections:
In the Main Product Install Options section, choose Windows XP Embedded SP1
Tools.
In the Download Location section, click Change and browse and select C:\tmp.
5 Click Start Download Now.
When the download is complete, it launches the installer.

NOTE
If the installer fails to launch, extract the downloaded data1.cab and tools.cab (found in
C:\tmp) into a temporary folder. Run WINDOWS XP EMBEDDED TOOLS SP1.MSI, which
will continue the installation.
6 In the next window, click Tools Setup.
The Setup Wizard window appears.
7 Click Next.
8 The license agreement displays in the next screen. Click Next to accept the
agreement.
The Customer Information window appears.
9 Provide the user name, organization, and product key as shown in the next
window.
You can find the product key in the productkey.txt file, which is located in the disk1
directory in the directory where you extracted data1.cab earlier. Using the example
from that step, the location is:
C:\tmp\Disk1\productkey.txt
10 Click Next.
The Setup Type window appears.
11 Choose Typical, if it is not already selected, and click Next.
The Windows Embedded Server Location window appears.
12 Choose This computer, if it is not already selected, and click Next.
The installation continues.
13 When the installation completes, reboot your computer.
14 Locate and run the sdiloader.exe file to complete the setup, which includes
registering the ActiveX required for the script to create the SDI file.
The file resides in the \bin subdirectory of the Windows XP Embedded SP1 Tool
Kit installation directory. For example:
C:\Program Files\Windows Embedded\bin

When you run sdiloader.exe, the Storage Device Image Loader window appears.
15 Click Done to close the application. (You do not need to add a disk.)
Creating a WinPE 1.6 image file using the script

You can create a WinPE 1.6 image file only by using the BMC BladeLogic
CreateWinPE1_6.bat script. Refer to the following topics for instructions on how to
create a PE 1.6 image file using the CreateWinPE1_6.bat command and then copy it to
the TFTP server:
Creating a PE 1.6 x86 image file

Creating a PE 1.6 AMD64 image file
Creating a PE 1.6 x86 image file
Use the following procedure to create an x86 image file and copy it to the TFTP
server.
1 Open a command window and change directories to:

2 Use the CreateWinPE1_6.bat command syntax shown below to create an x86 image
file.
To create an x86 WinPE 1.6 image...

General syntax CreateWinPE1_6.bat architecture
installDirectory WinISOPath destination
bootDirectory EmbeddedToolKitDirectory
[script]
architecture Set this to x86.
installDirectory This is the full path of the directory where
you unzipped provision-files.zip, for
example:
WinISOPath This is the Windows 2003 SP1 Windows XP
SP2 ISO path (the location where you
installed the installation media), for example:
C:\ENGLISH\32BIT\STANDARD_WI
TH_SP1_VLP
Note: Pathnames containing spaces are not

supported.

To create an x86 WinPE 1.6 image...

destination First, create a temporary local directory to
hold the image files you are about to create,
for example, you might create a directory like
this:
C:\BMC_BL\tmp

supported.
bootDirectory After you run CreateWinPE1_6.bat, you will
create a boot directory on the TFTP server,
and you will copy all the image files into that
directory.
bootDirectory is the name of the boot directory

on the TFTP server.
In general, you should set bootDirectory to:
boot_1_6
so that you can use the default placeholders

for images.

supported.
EmbeddedToolKitDirectory This is the directory in which you installed
the Windows XP Embedded SP1 Tool Kit.
Specify the full path through the utilities
folder, for example:
C:\Program Files\Windows
Embedded\utilities
[script] Optional. If you want to run an optional
external script when the image is mounted,
you can specify the scripts full path and
name here.
Example command syntax: CreateWinPE1_6.bat x86
C:\ENGLISH\32BIT\STANDARD_WITH
_SP1_VLP
C:\BMC_BL\tmp\WinPE1_6_x86\boot_1_
6 C:\Program Files\Windows
Embedded\utilities
(Type this command all on one line.)
This command creates the WinPE 1.6 image

files and places them in destination.

3 On the TFTP server, create a bootDirectory subdirectory where you plan to place the
image you just created by running CreateWinPE1_6.bat. Create this subdirectory
directly under the <tftproot> directory.
In general, you should call this subdirectory:
boot_1_6
For example:
(This name lets you use the default placeholders for images. See Boot image files
and placeholders on page 869.)
4 The image file is actually made up of separate files that CreateWinPE1_6.bat

places in destination. The contents of destination should look like this:
WINPE2005.SDI
winnt.sif
Copy the entire contents of destination to the subdirectory you just created on the
TFTP server.
If you are using the recommended naming conventions, you would copy the
contents of destination to the boot_1_6 subdirectory directly under the tftproot
directory, for example:
Creating a PE 1.6 AMD64 image file
Use the following procedure to create an AMD64 image file and copy it to the TFTP
server.
1 Open a command window and change directories to:

2 Use command syntax shown below to create an AMD64 WinPE image file.
To create and place an AMD64 WinPE 1.6

image...
General syntax CreateWinPE1_6.bat architecture
installDirectory WinISOPath destination
bootDirectory [script]
architecture Set this to amd64.


image...
installDirectory This is the full path of the directory where
you unzipped provision-files.zip, for
example:
WinISOPath This is the Windows XP SP1 64-bit ISO path
(the location where you installed the
installation media), for example:
C:\ENGLISH\64BIT\STANDARD_WI
TH_SP2_VLP

supported.
destination First, create a temporary local directory to
hold the image files you are about to create,
for example, you might create a directory like
this:
C:\BMC_BL\tmp

supported.
bootDirectory After you run CreateWinPE1_6.bat, you will
create a boot directory on the TFTP server,
and you will copy all the image files into that
directory.
bootDirectory is the name of the boot directory

on the TFTP server.
In general, you should set bootDirectory to:
boot_1_6_x64
so that you can use the default placeholders

for images.

supported.
EmbeddeToolKitDirectory This is the directory in which you installed
the Windows XP Embedded SP1 Tool Kit.
Specify the full path through the utilities
folder, for example:
C:\Program Files\Windows
Embedded\utilities


image...
[script] Optional. If you want to run an optional
external script when the image is mounted,
you can specify the scripts full path and
name here.
Example command syntax: CreateWinPE1_6.bat amd64
C:\ENGLISH\64BIT\STANDARD_WITH
_SP2_VLP
C:\BMC_BL\tmp\WinPE1_6_amd64\boot
_1_6 C:\Program Files\Windows
Embedded\utilities
This command creates the WinPE 1.6 image

files and places them in destination.
3 On the TFTP server, create a bootDirectory subdirectory where you plan to place the
image you just created by running CreateWinPE1_6.bat. Create this subdirectory
directly under the <tftproot> directory.
In general, you should call this subdirectory:
boot_1_6_x64
For example:
C:\tftproot\boot_1_6_x64
(This name lets you use the default placeholders for images. See Boot image files
and placeholders on page 869.)
4 The image file is actually made up of separate files that CreateWinPE1_6.bat

places in destination. The contents of destination should look like this:
WINPE2005.SDI
winnt.sif
Copy the entire contents of destination to the subdirectory you just created on the
TFTP server.
If you are using the recommended naming conventions, you would copy the
contents of destination to the boot_1_6_x64 subdirectory directly under the tftproot
directory, for example:
C:\tftproot\boot_1_6_x64

Creating a Gentoo Linux image file
Extracting boot files for WinPE 1.6 images

Use the following procedure to extract the ntldr, ntdetec.com, and startrom.0 files and
copy them to the TFTP server.
1 Create a temporary local directory that will hold the files you are about to extract,
for example:
C:\BMC_BL\tmpboot
2 Open a command window and change directories to

C:\BMC_BL\WinPE_1.6\WINPE.
3 Run the extractstartrom.bat script to extract ntldr, ntdetec.com, and startrom.0. Use
the following syntax:
extractstartrom WinISOPath destination
where WinISOPath is the Windows 2003 SP1 or Windows XP SP2 64-bit ISO path
(the location where you copied the installation media) and destination is the
temporary local storage directory you created at the beginning of this procedure,
for example:
extractstartrom C:\ENGLISH\32BIT\STANDARD_WITH_SP1_VLP
C:\BMC_BL\tmpboot
4 Take a look at the contents of C:\BMC_BL\tmpboot. You should see ntldr,

ntdetec.com, and startrom.0.
Copy these files to the following locations on the TFTP server:
Copy startrom.0 into <tftproot>\x86pc\pxelinux, for example:
C:\tftproot\x86\pxelinux\startrom.0
Copy ntldr and ntdetec.com into <tftproot>, for example:
C:\tftproot\ntldr
C:\tftproot\ntdetec.com

Use this procedure 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.
In this procedure, this ISO image file is referred to as: gentooMinimalIsofile.
Place gentooMinimalIsofile in a directory on the Linux machine where the TFTP

server is installed, for example:
/tmp/bmc_bl
2 Locate the BMC BladeLogic file:
current_version-provision-files.zip
Place this file in a directory on the Linux machine where the TFTP server is
installed, 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 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 you just created by unzipping provision-files.zip. This is the location
of the script you will use to create the image filemkgen2img.sh.
Use the mkgen2img.sh 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/x86/bmi32
gentooMinimalIsofile outDirectory
location This is the full path the /provisioning/linux
subdirectory, for example:
gentooMinimalIsofile This is the full path to the minimal ISO file
you downloaded from the Gentoo site, for
example:
/tmp/bmc_bl/install-x86-minimal-
2007.0-r1.iso
outDirectory This is the location where you want to place
the generated image file. Set outDirectory to:
/tftproot/x86pc/pxelinux
Example: /bin/sh mkgen2img.sh
/tmp/bmc_bl/provisioning/linux/x86/bmi32
/tmp/bmc_bl/install-x86-minimal-2007.0-
r1.iso /tftproot/x86pc/pxelinux
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/amd64/bmi64
gentooMinimalIsofile outDirectory
location This is the full path the /provisioning/linux
subdirectory, for example:
gentooMinimalIsofile This is the full path to the minimal ISO file
you downloaded from the Gentoo site, for
example:
/tmp/bmc_bl/install-x86-minimal-
2007.0-r1.iso

Using the Skip Linux Pre-Install image
To create an AMD64 Gentoo image...

outDirectory This is the location where you want to place
the generated image file. Set outDirectory to:
/tftproot/x86pc/pxelinux
Example: /bin/sh mkgen2img.sh
/tmp/bmc_bl/provisioning/linux/amd64/bmi
64 /tmp/bmc_bl/install-x86-minimal-2007.0-
r1.iso /tftproot/x86pc/pxelinux
This command creates the files gentoo and

gentoord.gz, which collectively make up the
Gentoo image file entity.
Using the Skip Linux Pre-Install image

To skip the Gentoo pre-installation image during provisioning of the Red Hat,
VMware ESX, or SUSE 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.
Note the following about using the Skip Linux Pre-Install image:
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 auto-discovery 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.
To use the Skip Linux Pre-Install image in provisioning:

Obtaining a DOS image file
1 When you add or import a device, select Skip Linux Pre-Install as the boot image
file. For information, see Working with manually imported devices on
page 1006.
2 Create the system package and create and run the Provision Job as you normally
would.
As soon as 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.
Obtaining a DOS image file

If you want to use any system packages created in BMC BladeLogic releases earlier
than 7.4, you need to obtain the DOS image file, blade.img. For information on
obtaining the DOS image file when upgrading from an earlier release, see the BMC
BladeLogic Installation Guide. If you have a 7.4 or later version of BMC BladeLogic, you
can create new DOS-based system packages, but you cannot execute them.
Configuring provisioning
The provisioning process uses four provisioning technologiesPXE, JumpStart,
NIM, and Ignite.
Prerequisite: Before configuring for one of these technologies, you must install
required support components:
PXE: DHCP, PXE, TFTP servers, data store(s), agent install files.
JumpStart: Working JumpStart environment, configured for and stocked with all
the operating system installation files you want to use to provision target
machines. Agent install files.
NIM: Working NIM environment, configured for and stocked with all the
operating system installation files you want to use to provision target machines.
Agent install files.
Ignite: Working Ignite environment, configured for and stocked with all the
operating system installation files you want to use to provision target machines.
Agent install files.
These installation tasks are described in the BMC BladeLogic Installation Guide.

Configuring the data store
Once you have installed the components required for your provisioning technology,
you can configure provisioning. You need to do certain configuration tasks regardless
of what technology you are using, whereas you need to do other tasks only if you are
using a specific technology. These differences are noted in the table below.
Provisioning Technology Tasks

PXE Configuring the data store
Creating custom system package types (optional)
Changing the location of installation files
Configuring the PXE server (if you did not do so when you
installed the PXE server)
Configuring the TFTP server (if you did not do so when you
installed the TFTP server)
Configuring boot image files
JumpStart Configuring the data store
NIM Configuring the data store
Ignite Configuring the data store

Applies to: PXE, JumpStart, NIM, Ignite
Use this procedure to set values needed to access data sources. 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. Those installation files are used
during the provisioning process.
Of course, any data store you specify must already be set up. For more on setting up a
data store, see the BMC BladeLogic Installation Guide.
To provision from a local data store, set up the local data store and use the local data
store instance as described in Provisioning Windows 2003 or 2008 servers from a
local data store on page 1044.
Data store values are stored in the Data Store system object, which you can edit by
using the Property Dictionary:

2 In the left hand Property Class Navigation panel, open the Built-in Property Classes
folder, then open the DataStore sub-folder. Click Jumpstart DataStore, Pxe DataStore,
NIM DataStore, or Ignite DataStore.
3 You need to create at least one instance of a data store, so click the Instances tab
in the right panel.
A DataStore instance specifies the server(s) that function as a data store. You can
create more than one instance of a data store. For example:
You may want to create one instance of a data store that contains installation
files for provisioning Windows systems, and another instance that contains files
for provisioning Linux systems.
If you are managing an enterprise WAN, you may want to create one instance of
a data store to serve the London network segment, another instance 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 DataStore instance as described in Creating or modifying an instance of a

property class on page 129. As you create this instance, fill in the PXE, JumpStart,
NIM, or Ignite properties shown in the table below.
Property Name Description

PXE Properties
LOCATION 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 both NSH and the BMC BladeLogic console.)
Important: If the PXE server, TFTP server, and the data store are
all on the same machine, follow these naming rules:
If you will be using this data store instance to provision Linux

systems: Set the LOCATION property to the IP address (not
the host name).
If you will be using this data store instance 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, so
LOCATION is the name of the NFS server.


FULL_PATH 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 files needed for provisioning a

particular operating system (see Changing the location of
installation files on page 913), you specify that location in relation
to the directory you identify in this step.
VIRTUAL_DIR 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 via the
following URL:
http://host1/installs
This means that you should 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\
This means that you should 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 needed to access the data
PASSWORD store.
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
BOOT_SERVER Host name of the boot server. (Note that this server must have a
running RSCD agent that is licensed for both NSH and the BMC
BladeLogic console.)
BOOT_SERVER_FULL Full path to the Jumpstart root folder on the boot server.
_PATH
BOOT_SERVER_DOCUM (For WAN boot installation) The path to the document root
ENT_ROOT_PATH directory of the web server on the boot server.
BOOT_SERVER_URL (For WAN boot installation) The URL through which the
document root directory can be accessed via HTTP.
BOOT_SERVER_CGI (For WAN boot installation) The path to the cgi-bin directory on
_BIN_PATH the boot server.
BOOT_SERVER_CGI (For WAN boot installation) The URL through which the cgi-bin
_BIN_URL directory on the install server can be accessed via HTTP.
CONFIG_SERVER Host name of the configuration server. (Note that this server must
have a running RSCD agent that is licensed for both NSH and the
BMC BladeLogic console.)
CONFIG_SERVER Full path to the configuration root on the configuration server.
_FULL_PATH
INSTALL_SERVER Host name of the install server. (Note that this server must have a
running RSCD agent that is licensed for both NSH and the BMC
BladeLogic console.)
INSTALL_SERVER Full path to the installers on the install server. This is the full path
_FULL_PATH to the directory that functions as a data store.
INSTALL_SERVER_DOC (For WAN boot installation) The full path to the document root
UMENT_ROOT_PATH directory of the web server on the install server.
INSTALL_SERVER (For WAN boot installation) The URL through which the
_URL document root directory can be accessed via HTTP.
INSTALL_SERVER_CGI (For WAN boot installation) The path to the cgi-bin directory on
_BIN_PATH the install server.
INSTALL_SERVER_CGI (For WAN boot installation) The URL through which the cgi-bin
_BIN_URL directory on the install server can be accessed via HTTP.

Creating custom system package types

Note: If all three JumpStart services (boot, config, install) are on the same partition of the
same server, then all three of the property pairs listed above will be set 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
NIM_MASTER The host name of the NIM master. This must be resolvable from
the BMC BladeLogic application server. The NIM master must
have a running RSCD agent that is licensed for both NSH and the
BMC BladeLogic console.
STAGING_DIR_PATH An existing directory location on the NIM master. BMC
BladeLogic will use this directory to stage all generated NIM
resources. The directory needs to be writable by anyone who will
create a provisioning job, since the job execution will create sub-
folders and files as necessary.
Ignite Properties
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 must be
resolvable from the BMC BladeLogic Application Server. The
primary Ignite server must have a running RSCD agent that is
licensed for both NSH and the BMC BladeLogic console.
STAGING_DIR_PATH An existing directory location on the primary Ignite server. BMC
BladeLogic will use this directory to stage all generated Ignite
resources. The directory needs to be writable by anyone who will
create a provisioning job, since the job execution will create sub-
folders and files as necessary.

The System Package Types tab on the Provisioning Configurations window lists the
available system package types. If necessary, you can create your own custom system
package type. For example, you might want to create a custom system package type if
you need to deploy an operating system based on an older Microsoft service pack.

This procedure requires you to provide the location of installation files stored in the
data store. The data store is a directory structure that holds installation files. When
your BMC BladeLogic system is first set up, a data store is typically also set up. On
Windows, the PXE installer gives you the option to set up a data store on the same
machine as the PXE Server.
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 (see
Configuring the data store on page 903).
JumpStartspecifying the INSTALL_SERVER_FULL_PATH property in the Data

Store system object (see Configuring the data store on page 903).
NIMspecifying the NIM_MASTER property in the Data Store system object (see
Ignitespecifying the IGNITE_SERVER property in the Data Store system object

(see Configuring the data store on page 903).
The location you specify on the System Package Types tab is relative to that root.
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.
Note that once you click an operating system, the window displays only the fields
you need for that operating system.

The fields for each operating system are shown in the table.
Operating
System Field Description
Windows Windows 2008 only: Check this box if this system package type is for
Windows 2008.
Then from the drop-down menu, select the
Windows 2008 operating system type.
Architecture: x86 or x64 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 installer resides in
C:\Program Files\BMC
Software\BladeLogic\8.0\PXE\pxestore\win2k
and the root directory of the data store is

Software\BladeLogic\8.0\PXE
you would enter pxestore\win2k.

RSCD agent installer Directory where the installer for the RSCD agent
location resides.

Operating
Initial partition size Size of the initial disk partition (in MB).
(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 operating systems: At

least 10000 MB for an x86 system package
type and at least 15000 MB for an x64 system
package type.
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 (Disk Partition Windows on page 929).

Operating
Red Hat, SUSE Linux only: Check this box if this system package type is for
VMWare ESX, SUSE/SLES Version SUSE/SLES Version 10.x or higher.
SUSE Linux 10.x or higher Then from the drop-down menu, select the
SUSE/SLES version.
Red Hat only: RHAS 5 Check this box if this system package type is for
or Higher RHAS version 5 or higher.
VMWareESX only: ESX Select the VMware ESX version from the drop-
version down menu.
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 installer resides in
C:\Program Files\
BMC Software\BladeLogic\8.0\PXE\
pxestore\RedHat_Advanced_Server_3_0
C:\Program Files\
BMC Software\BladeLogic\8.0\PXE\
you would enter

pxestore\RedHat_Advanced_Server_3_0
RSCD agent installer Directory where the installer for the RSCD agent
location resides.
Boot kernel file name For Boot kernel file name, enter the name
Boot image file name assigned to the boot kernel file stored in the
X86PC\pxelinux directory on the TFTP server.
For Boot image file name, enter the name
assigned to the boot image file in the same
location.
The names you enter in this step vary depending

on the system package type you are defining.
Initially, the boot kernel file is named vmlinuz
for Red Hat and linux for SUSE. Similarly, the
boot image file is initially named initrd-
everything.img for Red Hat and initrd for Linux.
These files are renamed when the TFTP server is
configured during the initial setup of your
provisioning system. For more information on
configuring the TFTP server, see the BMC

Operating
Solaris Solaris architecture Indicate the type of machine you plan to
provision with this system package type by
clicking either SPARC or x86.
OS installer location Relative path to the Tools directory of the
installer tree. The location you specify should be
relative to the data store install server root.
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.
Solaris WAN boot only: WAN Boot Parameters
Archive location The path to the Solaris Flash archive on the
install server, relative to the install server
document root directory.
Miniroot Location The path to the miniroot file on the boot
server, relative to the boot server document
root directory.
WAN Boot Location The path to the wanboot installation
program on the boot server, relative to the
boot server document root directory.
AIX System package type Name of the 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
HPUX HPUX architecture Indicate the type of machine you plan to
provision with this system package type by
clicking either HP ITANIUM or HP PA-RISC.
Index File Use Browse to browse to the Ignite index file
you want to use for this system package.
5 Click OK. The information you entered on the System Package Type window
displays on the System package tab.


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 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 BladeLogic system is first set up, a data store should also be set up. On
Windows, the PXE installer gives you the option to set up a data store on the same
machine as the PXE Server.
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 (see
JumpStartspecifying the INSTALL_SERVER_FULL_PATH property in the Data

Store system object (see Configuring the data store on page 903).
NIMspecifying the NIM_MASTER property in the Data Store system object (see
Ignitespecifying the IGNITE_SERVER property in the Data Store system object

(see Configuring the data store on page 903).
The location you specify on the System Package Types tab is relative to that root.
1 Choose Configuration => Provisioning Configurations.
2 Click the System Package Types tab.
3 Under Relative Paths for OS Images, select a type of system package, and click Edit
.
The System Package Type window opens.
4 Note that this window shows only the fields needed for your chosen operating
system. Fill in the fields as shown in the table below.

Operating System Field Description

Windows Windows OS installer Directory where the operating system
location installer is located.
The location you specify should be

relative to the root directory of the data
store. For example, if the installer resides
in
Software\BladeLogic\8.0\PXE\
pxestore\win2k
Software\BladeLogic\8.0\PXE
you would enter pxestore\win2k.

RSCD agent installer location Directory where the installer for the
RSCD agent resides.
Red Hat, ESX, and OS installer location Directory where the operating system
SUSE installer is located.
The location you specify should be

relative to the root directory of the data
store. For example, if the installer resides
in
C:\Program Files\BMC Software\

BladeLogic\8.0\PXE\pxestore\RedHat
_Advanced_Server_3_0
Software\BladeLogic\8.0\PXE\
you would enter
pxestore\RedHat_Advanced_Server_3_
0
RSCD agent installer location Directory where the installer for the
RSCD agent resides.

Configuring the PXE server
Operating System Field Description

Solaris OS installer location Relative path to the Tools directory of
the installer tree. The location you
specify should be relative to the data
store install server root.
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.
AIX 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
HPUX Index File Use Browse to browse to the Ignite
index file you want to use for this system
package.
5 Click OK. The information you entered on the System Package Type window
displays on the System package tab.
Configuring the PXE server

Applies to: PXE
NOTE
To see the PXE configuration tab, you must have, at minimum, the ProvisionConfig.Read
authorization.
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. A multicast group is a group of IP
addresses that have been defined to receive a multicast.

Configuring the TFTP server
2 Click the PXE tab.
3 Under PXE Settings, for Interface to bind, enter the name of the Ethernet interface
that the PXE server uses to listen. For example, you might enter the name of a
network interface card, such as eth0 or eth1.
4 For Multicast address, enter the IP address of the multicast group that the PXE
server listens on. By default, the BMC BladeLogic 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.
5 For Listening port, enter the port on which the PXE server listens for connections
from target machines being provisioned. By default, the PXE server listens on port
4011.
6 For Prompt timeout, enter 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 does not display.
7 For Domain, enter the domain of the PXE server.
8 Check Use multicast if the PXE Server should listen to multicast requests.
9 Check Use broadcast 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.
10 Click OK to save the current values.
11 Stop and restart the PXE server, as described in Starting and stopping the PXE
server on page 917.
Configuring the TFTP server

Applies to: PXE
NOTE
To see the TFTP configuration tab, you must have, at minimum, the ProvisionConfig.Read
authorization.

Starting and stopping the PXE server
The TFTP tab on the Provisioning Configurations window lets you provide
information, such as an IP address, for TFTP and MTFTP servers. The TFTP or
MTFTP servers download the bootstrap program needed to initiate the provisioning
process.
2 Click the TFTP tab.
3 Under TFTP Settings, for IP address, enter the IP address that the TFTP server
listens on.
4 For Base directory, enter the base directory of the file system used to store operating
system bootstrap programs to be downloaded.
5 Under MTFTP Settings, for IP address, enter the multicast address that the TFTP
server listens on.
6 For Client port, enter the multicast port that servers being provisioned should use
to communicate with the TFTP server. By default BMC BladeLogic uses port 1758.
7 For Server port, enter the multicast port that the TFTP server should use to listen for
communication from servers being provisioned. By default BMC BladeLogic uses
port 1759.
9 Stop and restart the TFTP server, as described in Starting and stopping the TFTP
server on page 918.
Starting and stopping the PXE server

Use these procedures to start and stop the PXE server.

Starting and stopping the TFTP server
Action Windows Linux

Start PXE Server The PXE server is a Windows Type the command:
service, so choose Start =>
Settings => Control Panel => /etc/init.d/blpxe start
Administrative Tools =>
Services.
Right-click BladeLogic PXE

Server and select Start.
Stop PXE Server The PXE server is a Windows Type the command:
service, so choose Start =>
Settings => Control Panel => /etc/init.d/blpxe stop
Administrative Tools =>
Services.
Right-click BladeLogic PXE

Server and select Stop.
Starting and stopping the TFTP server

Use these procedures to start and stop the TFTP server.
Action Windows Linux

Start TFTP Server The TFTP server is a Type the command:
Windows service, so choose
Start => Settings => Control /etc/init.d/bltftp start
Panel => Administrative
Tools => Services.
Right-click BladeLogic TFTP

Server and select Start.
Stop TFTP Server The TFTP server is a Type the command:
Windows service, so choose
Start => Settings => Control /etc/init.d/bltftp stop
Panel => Administrative
Tools => Services.
Right-click BladeLogic TFTP

Server and select Stop.


Applies to: PXE
When provisioning a device, the provisioning process uses an image file 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.
The standard installation process includes creating appropriate WinPE or Gentoo

Linux image files that contain generic network drivers that work for most hardware
types. The installation process may also include obtaining an image file (blade.img)
for working with legacy system packages.
By default, the BMC BladeLogic GUI contains the following pointers to these image
files:
Boot image file Description

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
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 1055.
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 1044.
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 1044.
WindowsPE_1_6_Image Used to provision x86 Windows machines.
WindowsPE_1_6x64_Image Used to provision AMD64 and Windows
machines.

These pointers become operational once you create (or obtain) the corresponding
image files and place them in the correct locations on the TFTP server, as described in
Creating boot image files on page 868.
The Image Files tab on the Provisioning Configurations window includes various
configuration settings for each image file, including a description and an indication of
which image file is the default for your environment. You can review and adjust these
settings, using the Image Files tab.
In addition, if you want to provision a device that requires a custom image file
containing specialized network drivers, you can register the custom image file, using
the Image Files tab. Once you register the custom image file, you can assign it to the
specific device you want to provision. Typically, a BMC BladeLogic 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 Under PXE Boot Image Files:
To edit the configuration settings for an existing image file listing, highlight the
image file name, then click Open .
To add a listing for a new image file, click Add .
The Add Image File window opens.
NOTE
This window shows only the fields needed for your chosen operating system. Fill
in the fields as shown in the following table.

Image Type Field Description

WinPE 2.x Image file The name of the image file. Assuming you used
the standard BMC BladeLogic image creation
WinPE 1.6 wizard or script, the image file is named one of
the following:
WindowsPEImage
WindowsPE64Image
(For information about creating these files, see

Creating boot image files on page 868.)
Description 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:
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 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.
Check this field if this is the default image for

your environment.


Linux Image file The name of the image file (RAM drive).
Assuming you used the standard BMC
BladeLogic image creation script, the image file
is named:
gentoord.gz
Kernel name The kernel required for PXE booting a Linux
machine. Assuming you used the standard
BMC BladeLogic image creation script, the
kernel name is:
gentoo
(For information about using the BMC

BladeLogic image creation script, see Creating
a Gentoo Linux image file on page 898.)
Kernel commandline Command line arguments that the kernel
requires at boot time.
otherwise.

your environment.
DOS Image file The name that will appear in the boot image
drop-down menus in the BMC BladeLogic GUI.
the systems sends this device the default image.

your environment.


ESXi 4.0 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
For information on creating this image file, see

Provisioning target servers with ESXi 4.0 on
page 1055.
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.

Including a Batch Job in a system package

WinPE 2.x ISO Image file The name of the image file.
For information on creating this image file, see

from a local data store on page 1044.
Description (Optional) Description of the 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.

otherwise.
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

When you use a system package to provision a server, the system package can run a
Batch Job, which allows you to build the server stack beyond the operating system or
to perform other tasks that you might typically perform using the BMC BladeLogic
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. See Chapter 16, Batch Jobs.
2 Create the system package and define its settings to include the Batch Job. See
Creating a system package.

Creating a system package

In order to perform an unattended installation of an operating system, you must
create a system package for each server configuration you want to install. A system
package not only contains all the instructions needed to install an operating system
over the network, it can also run jobs that install software and configure a machine
for a particular purpose. Consequently, you may want to create a different system
package for each type of server you want to provision rather than just creating one
system package for each type of operating system you want to install. For example,
you might want to create a system package for a web server running Windows 2000
and IIS. You could create another system package for a database server running
Linux 8.0 and Oracle.
Use this procedure to create a new system package. After you create the system
package, you must define how the operating system is installed and provide other
configuration information. The type of system package determines the type of
settings you must provide. You can create the following types of system packages:
System Package Type Relevant Procedure

Windows Defining settings for Windows servers on page 927
Linux Defining settings for Linux servers on page 948
ESX Defining settings for ESX servers on page 960
Solaris Defining settings for Solaris servers on page 971
AIX Defining settings for AIX servers on page 987
HP-UX Defining settings for HP-UX servers on page 997
For detailed information on supported operating systems and versions, see the BMC
A system package type uses installation files for a specific operating system.
Consequently, system packages for the various types of Windows, Linux, ESX,
Solaris, AIX, and HP-UX operating systems are not interchangeable. Create separate
system packages for servers running different operating systems.
TIP
When you define a system package, you must provide many categories of information. If you
are creating multiple system packages with similar settings, you may want to create one
system package and copy and paste that package to create another system package, adjusting
settings as necessary. (See Copying, cutting, and pasting groups, folders, and system objects
on page 95.)
Prerequisite: Every system package must belong to a folder in the Depot. In the
Depot folder, create an appropriate folder for your new system package, as described
in Creating a folder or group on page 91.

To create a system package:
1 In the Depot folder, right-click the folder where you want to add a new system
package. From the pop-up menu, choose New => System package.
The New System Package wizard displays.
2 For Name, enter a name for the system package.
3 For Description, you can optionally provide descriptive text.
4 The Member of field displays the group to which this system package belongs.
5 For System package type, select the type of system package.
6 Click Next.
7 (Optional) On the Properties panel, edit the properties for the system package.
The Properties panel shows a list of properties automatically assigned to a system

package. You can modify the value of any properties in this list that are defined as
editable. For more information on assigning property values, see Setting values
The default list of properties assigned to a system package is determined by the

Depot Object built-in property class in the Property Dictionary. If necessary, you
can use the Property Dictionary to create new properties. For more information,
8 Click Next.
The Permissions panel appears.
The Permissions panel defines permissions for this system package in the form of
an access control list (ACL). The ACL specifies the roles that have access to the
system package and the types of actions those roles are authorized to perform.
9 Use the Permissions panel to define permissions for this server. For more
page 186.
10 Click Finish. The system package is created and opens in the content editor.
11 Define the system package.
To define a system package for any type of supported Windows operating system,
see Defining settings for Windows servers on page 927.

Defining settings for Windows servers
To define a system package for any type of supported Linux operating system, see
Defining settings for Linux servers on page 948.
To define a system package for any type of supported ESX operating system, see
Defining settings for ESX servers on page 960.
To define a system package for any type of supported Solaris operating system, see
Defining settings for Solaris servers on page 971.
To define a system package for any type of AIX operating system, see Defining
settings for AIX servers on page 987.
To define a system package for any type of supported HP-UX operating system,
see Defining settings for HP-UX servers on page 997.
TIP
When defining a system package, note the presence of the Select Property icon next to
various input fields. Whenever you see this icon next to an input field, it 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 1059 and Using properties to reference scripts on page 1063.
For an example of how using parameters can streamline provisioning, see Importing
MAC Addresses and Configuration Values on page 1012.
12 When you finish defining the system package, select File => Save.
Defining settings for Windows servers

Use this procedure to specify settings for an unattended installation of a server
running a Windows operating system.
In addition to installation of an operating system, this procedure allows you to run a

Batch Job that can install software and perform other configuration on the server.
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 Define standard system package settings by clicking the tabs at the bottom of the
system package tab. Each tab represents a category of settings, as described in the
following sections:

Pre-Install Scripts Windows

Disk Partition Windows
Post-disk partition Windows
Basic configuration Windows
Computer Settings Windows
OS components Windows
Network Windows
Unattend entries Windows
Post-install configuration Windows
Local properties Windows
3 When you finish defining settings for the system package, click the system package
tab and select File => Save.

The BMC BladeLogic system uses the Windows PE DiskPart utility to create WinPE-
based Windows system packages. 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.
1 Click the Pre-Install Scripts tab.
2 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 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%


The Disk Partition tab lets you define partitions for the servers being provisioned.
To define partitions, you can use a text-based or GUI-based approach:
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. Instructions for configuring other partitions
are added to the runonce.bat file, and they execute before any post-install
configuration options run.
If you use a text-based approach to defining disk partitions, the script you enter
executes in its entirety during the Disk Partition stage of provisioning.
If you are creating a WinPE-based Windows system package, any script you enter
here must use DiskPart syntax.
1 Click Disk Partition tab.
2 There are two ways to define a partitionby supplying a script or using fields in
the GUI:
To supply a script, check Use script for disk partitioning and do one of the
following:
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 on
how to use properties to reference scripts, see Using properties to reference
scripts on page 1063.)
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 907.)
To use the GUI to define a partition, follow the rest of the steps in this
procedure.
3 To define a partition, do one of the following:

To create a new partition, click Add .
To modify an existing partition, select the partition in the Disk Partition list and
click Open .
The Disk Partition window opens.
4 Under Partition Configuration, for Label, select a drive letter from the drop-down
list. If this partition is the primary partition, check Primary partition.
5 Under File System Options, from Type, 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.
6 Under Size Options:
For Size, enter the size of the partition in megabytes.
Set this value according to Microsofts available disk space recommendations

for the operating system you specified in creating the system package.
NOTE
To ensure that the operating system installation completes successfully, the provisioning
process requires the following primary disk partition values:
For Windows 2008 operating systems: At least 10000 MB for an x86 system package
type and at least 15000 MB for an x64 system package type.
For all other Windows operating systems: At least 2000 MB.
If you want the partition to fill all remaining space on the disk, check Fill all
unused space on disk. Only one partition can fill all unused space.
Check Quick format to format the partition much faster than the normal format
option.

For Partition label, you can specify a name for the partition. This name will
appear along with the drive letter, for example, Misc (D:).
7 Click OK. The partition appears in the Disk Partitions list.
To delete a partition, select the partition in the Disk Partitions list and click Delete .

The Post-disk partition tab lets you specify scripts to execute after the disk has been
partitioned.
1 Click the Post-disk Partition tab.
2 The Post-disk Partition tab displays a text box, where you can either:
Enter Windows PE-based commands.
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.
For information on how to use properties to reference scripts, see Using

properties to reference scripts on page 1063.
This tab also displays a check box, which gives you the option of rebooting the server
after those commands execute.

The Basic Config tab lets you provide local information about a server, such as its
name, workgroup, domain, and user account.
1 Click the Basic Config tab.
2 Under Local Settings, do the following:
A For Computer Name, enter a unique name that should be assigned to the server.
To generate a name automatically using the Windows algorithm, check Auto-

generate computer name.

Rather than auto-generate names, you can use the same system package to
provision multiple servers and assign a unique name to each server when you
apply the system package to the server, as described in If you are provisioning
multiple servers... on page 1028.
B You can optionally choose a different name for this server to display when it
appears in the BMC BladeLogic console. If you want this server to appear with a
different name, type that name in the OM Server Name text box.
If you want this server to display its Computer name when it appears in the
BMC BladeLogic console, leave the OM Server Name box 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.
C For Administrator password, enter the local administrators password. Then

confirm your typing by entering the password again in the Confirm password
field.
3 Under Workgroup or Domain, specify whether the server should be part of a

workgroup or domain by doing one of the following:
Select Workgroup 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.
Select Windows server domain and then enter the name of the domain in the text
box to the right. A domain is a collection of computers defined by a network
administrator rather than a user.
4 Create an account so the computer can be added to a domain by doing the

following:
A Check Create a computer account in the 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.
B For User name, enter a user name for the computer account.
C For Password, enter a password for the users computer account. Then confirm
your typing by entering the password again in the Confirm password field.


The Computer Settings tab lets you provide information about users, plug-and-play
drivers, software license keys, and localization. The tab displayed depends on the
Windows operating system for which you are creating the system package.
Computer Settings Windows 2008

Use this procedure to configure computer settings for Windows 2008.
1 Click the Computer Settings tab.
2 Under User Information, for Name, enter a user name. For Organization, enter the
name of the organization.
3 Under Driver Setup, specify the location of plug-and-play (PnP) drivers and mass
storage drivers in your data store.
A For configuring PnP or OEM drivers, for PnP driver paths, click Browse to
select drivers.
For PnP drivers, you can alternatively type 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
B 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 BladeLogic environment a server object whose
name matches the LOCATION property of the data store instance you selected.
If there are multiple databases 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.

C In the left pane, navigate to the directory that contains the PnP driver or mass
storage driver you want to add. Then select the drivers:
To select PnP drivers: Click the name of the directory in the left pane; then
click the right arrow to move this directory path to the right pane. Repeat this
procedure to select as many directories as you want.
To select mass storage drivers:
In the left pane, 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 Checking the format of txtsetup.oem on page 940.)
In the right pane, click the driver(s) you want to add. Use Control-click or
Shift-click to select multiple drivers.
D 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.
4 Under License Setup, for 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.
5 Under Localization, do the following:
A For Time zone, select a time zone from the drop-down list.
B For Locale, select a language option from the drop-down list. For example, in the
United States, select English United States.
Computer Settings all other Windows operating systems

Use this procedure to configure computer settings for all the other Windows
operating system versions.

2 Under User Information, for Name, enter a user name. For Organization, enter the
name of the organization.
3 The Driver Setup section lets you specify the location of plug-and-play (PnP)
drivers and mass storage drivers in your data store.
Under Driver Setup, do the following:
A Specify the location of your $OEM$ directory.
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. You need to specify
this location in the Path to $OEM$ directory field.
For more information, see When to use Specify path to $OEM$ directory on
page 936. Also see the BMC BladeLogic Installation Guide for a description of how
to set up a data store to hold plug-and-play drivers.
B For PnP driver 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 937.
NOTE
Browsing the data store for the PnP and mass storage drivers has the following
requirements:
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.

C For Mass storage drivers, click Browse and use the driver selection GUI to
automatically fill in the mass storage drivers. For information on how to use this
GUI, see Using the driver selection GUI: mass storage drivers on page 938.
4 Under License Setup, for 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.
A For Time zone, select a time zone from the drop-down list.
United States, select English United States.
When to use Specify path to $OEM$ directory
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 933.
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 would need to look something like this:

However, you may 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 that
looks like this:
In this case, you need to check Specify path to $OEM$ directory and then specify the
location of your $OEM$ directory in the 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.
Using the example above, (where drive:\pxestore is your data store root) you would
specify the following path:
drivers\vendor1\model1
Using the driver selection GUI: PnP driver paths
NOTE
This information applies to Windows operating systems other than Windows 2008. For
information on specifying the location of Windows 2008 PnP drivers, see Computer Settings
Windows 2008 on page 933.
Next to PnP driver paths, click Browse and the driver selection GUI appears. You
can use this GUI to automatically fill in the PnP driver paths field.
1 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:
2 In the left pane, navigate to the directory that contains the driver you want to add.

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.
3 Click the name of the directory in the left pane, then click the right arrow to move
this directory path to the right pane.
4 Repeat this procedure to move as many directories as you want into the right pane.
5 Click OK. The selections appear in the PnP driver paths field on the Computer
Settings panel and the required entries are added 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 this to work, you need to have specified the OS installer path for this system package
type. If you have not specified this path, an error is displayed.)
For more information, see When to use Specify path to $OEM$ directory on page 936.
6 If you have not yet associated this system package with this data store, a message
appears, asking you if you would like to set this data store as the default data store
for this system package.
If you would like to have the contents of this data store displayed 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
NOTE
This information applies to Windows operating systems other than Windows 2008. For
information on specifying the location of Windows 2008 mass storage drivers, see Computer
Settings Windows 2008 on page 933.
Next to Mass storage drivers, click Browse and the driver selection GUI appears.
You can use this GUI to automatically fill in the Mass storage drivers field.

1 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:
2 In the left pane, navigate to the directory that contains the first driver 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.
3 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 Checking the
format of txtsetup.oem on page 940.)
4 In the right pane, click the driver(s) you want to add. Use Control-click or Shift-
click to select multiple drivers.
5 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$\TEXTMODE
For more information, see When to use Specify path to $OEM$ directory on page 936.
6 If you have not yet associated this system package with this data store, a message
appears, asking you if you would like to set this data store as the default data store
for this system package.

If you would like 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 is displayed
by default if you subsequently browse for PnP drivers.)
Checking the format of txtsetup.oem
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].
The OS Components tab lets you choose individual components that you want
included in the operating system being provisioned. Component selections depend
on the operating system.

OS Components Windows 2008

Use this procedure to select operating system components for Windows 2008
computers.
1 Click the OS Components tab.
2 Select the Operating System type.
3 Specify the server roles you want to install. Do one of the following:
Under Select Server Roles/Features, select the server roles. To install all server
roles, check Windows 2008 Server Roles. To install a subset of roles, check each
role you want.
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.

Network Windows
OS Components all other Windows operating systems

Use this procedure to select operating system components for all Windows operating
system types except 2008 computers.
1 Click the OS Components tab.
2 To install all IIS components, check IIS. To install a subset of all IIS components,
check the IIS components you want.
3 Under System, check MSMQ (Message Queuing Service) to install tools for creating
distributed messaging applications that can communicate across heterogeneous
networks, including computers that might be offline.
4 To install Terminal Services, check 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
For information on adding unattended entries, see Unattend entries Windows

on page 943.
Network Windows
The Network tab lets you provide networking information for a server, such as its IP
address and DNS configuration.
1 Click the Network tab.
2 Under IP Configuration, do one of the following:
Select Obtain an IP address automatically if the network connection should obtain

an IP address automatically from a DHCP server.

Select Use the following IP address if the network connection should use a static
IP address. If you choose this option, enter the static IP address in the IP address
field. For Subnet mask, enter a subnet mask number, which is used to identify
which segment of the network the server is on.
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.
For Default gateway, enter the address of the IP router that is used to forward
traffic to destinations outside of the local network.
3 Under DNS Configuration, do one of the following:
Select Obtain DNS server automatically if the DHCP server should provide the
addresses for DNS servers.
Select Use the following DNS server addresses if you want to manually identify
addresses for a primary and secondary DNS server. Then, enter IP addresses for
Primary DNS server and Secondary DNS server.

When you use the system package tabs in the Windows provisioning process, your
input is automatically converted into entries in the Unattend Entries file. This file is
used in unattended installations to provide answers to the prompts that would be
provided interactively in a live installation.
The Unattend Entries tab lets you modify the contents of the Unattend Entries file.
The file modified depends on the Windows operating system type.
1 Click the Unattend Entries tab.
2 Add or modify unattend entries, based on the Windows operating system for
which you are creating the system package:
Windows 2008. See Unattend Entries Windows 2008.
All other Windows operating systems. See Unattend Entries All Other
Windows Operating Systems on page 945.

Unattend Entries Windows 2008

For Windows 2008, the Unattend Entries tab modifies the unattend.xml file.
Your input on the system package tabs is automatically converted into the entries in
this unattend.xml file. The Unattend Entries tab lets you modify the file. You can:
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.
NOTE
The Additional Unattend Entries XML editor is an XML editor only and is not intelligent
about the BMC BladeLogic provisioning process or components required in Windows
installations.
Create a custom unattend.xml file by editing it in the Customize Unattend Entries

text box. The System Package tool always uses this unattend.xml exactly as shown
in the Customized Unattend Entries text box, instead of generating the file from
the System Package fields at deploy time.
Use this procedure to add or replace entries in the unattend.xml file.
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 be
edited or to which you want to add entries. 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 you want 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. See Using properties to

reference scripts.
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.
Use this procedure 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.
3 Click OK.
Use this procedure to delete an entry from the Additional Unattend Entries list.
1 Select the entry in the Additional Unattend Entries list and click Delete .
2 Click Yes to confirm your deletion.
Use this procedure 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 Other Windows Operating Systems

For Windows operating systems other than Windows 2008, the Unattend Entries tab
modifies the unattend.txt file.
When you define a system package, your input on the system package tabs is
automatically converted into text in the first edit box at the top of the Unattend
Entries tab.

If you want to add additional entries for configuration elements that are not covered
by the tabs for system package definition, type these entries into the second edit box
under Additional entries for the unattend.txt file. When you add additional entries, you
need to enter the header for each category of information, such as [Display].
Check Customize the Unattend Entries file if you want to modify the automatically
generated entries in the first edit box. Checking Customize the Unattend Entries file
also affects how you can use the second edit box for additional entries, as described in
the following two scenarios.
Scenario 1:
Suppose you want to leave the automatically generated entries in the first edit box
unchanged, and you want to add a few additional entries in the second edit box.
To do this, leave Customize the Unattend Entries file unchecked and add your new
entries in the second edit box. (Make sure to include entry headers, for example
[Display].)
Scenario 2:
Suppose you want to modify the automatically generated entries in the first edit box,
and you also want to add additional entries in the second edit box.
In this case you need to:
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.

The Post-install Configuration tab lets you do the following:
Choose whether you want to install a BMC BladeLogic RSCD agent. An agent
must be installed on every server you want to manage using the BMC BladeLogic
console or Network Shell.

Specify a Batch Job that runs after the operating system is installed on the server. A
Batch Job can sequentially run a series of other jobs that install software and
perform additional configuration on the server.
NOTE
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. For
information about roles and permissions, see Chapter 6, Managing access.
Enter commands that are included in the runonce.bat file, which runs once when
Windows starts the first time after an unattended installation of the Windows
operating system. Any commands you enter into this script are appended to
commands that BMC BladeLogic 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 that you specify.
1 Click the Post-Install Config tab.
2 Under Operations Manager Settings, check Install RSCD agent if you want to install
an agent on the server being provisioned.
3 Check Push ACLs if you want to push the ACLs defined for the server in the BMC
BladeLogic 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 BladeLogic 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 BladeLogic console but also through Network Shell and the BLCLI. For
detailed information on agent ACLs, see Using agent ACLs on page 192.
4 To run a job that can install software and configure the server, do the following:
A Check Run post-install batch job. (Note that 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.)
B For Path to post-install job, enter the path to the appropriate job.
5 Under Application server for BMI callback, provide 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.
6 Under Post-Install Script, enter any commands that you want to include in the
runonce.bat file, or click the Select Property icon to insert a parameter. (See Using
properties to reference scripts on page 1063.)

The runonce.bat file runs one time when Windows starts for the first time after an
unattended installation of the operating system.

The Local Properties tab lets you add and modify properties for this system package.
1 Click the Local Properties tab.
2 Do one of the following.
If you are adding a new property, click the Add .
If you are modifying an existing property, right-click the name of the property
and click Edit from the drop-down menu.
A property dialog displays.
3 Use the property dialog to add or modify a local property. For more information,
see Adding or modifying properties on page 125.
Defining settings for Linux servers

running a Linux operating system.

A tab for the system package appears in the Content Editor view.
system packages tab. Each tab represents a category of settings, as described in the
following sections:
Pre-install scripts Linux

Disk partition Linux
Basic configuration Linux
Computer settings Linux
OS components Linux

Network Linux
Kickstart entries Red Hat Linux
AutoYaST entries SUSE Linux
Post-install configuration Linux
Local properties Linux

You can use the Pre-Install Scripts tab to provide custom scripts for disk cleanup,
hardware configuration, disk array configuration, and pre-disk partitioning, for
example:
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
parted /dev/sda print >> /root/log.txt
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


1 Click the Disk Partition tab.
2 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:

scripts.)
If you want to reboot after script execution, click Reboot after the script is
executed.
To use the GUI, follow the instructions in the rest of this procedure.
3 To define a partition, do one of the following:
click Open .
The Disk Partition window opens.
4 Under Partition Configuration, for Mount point, enter the location within a file
directory where a volume should exist or select a location from the drop-down list.
5 Under File System Options, from 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.
jfsSupports journaling.

xfsSupports journaling.
6 Under Size options, 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 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.
7 If you are creating a Gentoo-based system package, under Disk Options, for Disk,
enter the physical volume (hda, hdb, hdc, etc.) on which to place the partition.
8 Click OK. The partition appears in the Disk Partitions list.
To delete a partition, select the partition in the Disk Partitions list and click Delete
.

name and the password needed to access the machine.
A For Computer name, enter a unique name that should be assigned to the server.
appears in the BMC BladeLogic console.If you want this server to appear with a
different name, enter that name in the OM Server Name box.
BMC BladeLogic console, leave the OM Server Name box blank.
C For Root password, enter the password used to access the root account. Then
field.
3 Under Provisioning Settings, do one of the following:
For Kickstart network device or AutoYaST network device, enter the name of the
network interface that the server uses to communicate with the HTTP server.

For example, you might enter eth0 or eth1. Note that the name of the field under
Provisioning SettingsKickstart network device or AutoYaST network device
varies depending on the type of system package you are defining.
NOTE
When defining settings for provisioning of SUSE Linux servers, if you specify the AutoYaST
network device, it can result in timeout. To avoid this problem, 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.
For Boot Kernel Parameters, type any 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
problems on some systems.
For a full list of available boot kernel parameters, see the Red Hat and SUSE
installation documentation.

The Computer Settings tab lets you provide information about peripheral devices
and localization settings.
2 Under Device Settings, select the keyboard layout type that you want to be the
system default. For example, in the United States you would probably select us.
3 For Mouse, select a type of mouse that you want to use with the machine.
A For 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.

OS components Linux
United States, select English (USA).
5 (Red Hat 5) Under Key Setup, for Installation Number, do one of the following:
Enter the 16-character alpha-numeric key that can be used during the
installation process.

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 Linux
The OS Components tab lets you choose individual components that you want
included in the operating system being provisioned. The options available vary
depending on whether you are defining a Red Hat or SUSE system package.
OS components Red Hat Linux

When you are defining a Red Hat system package, the OS Components tab lets you
select operating system components to be installed using a text-based approach or a
GUI-based approach. If you use the GUI-based approach, check the components you
want installed. 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 that when you script your own OS components, you must include wget, either
by itself or by including a package that contains it.

Network Linux
OS components SUSE Linux

When you are defining a SUSE system package, the OS Components tab lets you
select operating system components to be installed using a text-based approach or a
GUI-based approach. If you use the GUI-based approach, check the components you
want installed. 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 Linux
and DNS configuration.

which segment of the network the server is on. For Default gateway, enter the
address of the IP router that is used to forward traffic to destinations outside of
the local network. For DNS Server, enter an IP address for DNS Server.

Select Use the following DNS server address if you want to manually configure a
DNS server. Then, enter an IP address for DNS Server.

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.
by the standard shortcuts, type these entries into the second edit box under Additional
entries for the kickstart file.
Check Customize the Kickstart file if you want to modify the automatically generated
entries in the first edit box. Checking Customize the Kickstart file also affects how you
can use the second edit box for additional entries, as described in the two scenarios
below.
Scenario 1
To do this, leave Customize the Kickstart file unchecked and add your new entries in
the second edit box.
Scenario 2
1 Check Customize the Kickstart file.
3 Then, still in the first edit box, add your additional entries.

second edit box.

When you are defining a SUSE system package, an AutoYaST file is automatically
generated at deploy time that incorporates all of the options you have chosen when
defining this SUSE system package. The AutoYaST file is an XML file used in
unattended installations of SUSE Linux. 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
reflect those choices.
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 (see Creating a Provision Job on
page 1024). 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 the BMC BladeLogic
Installation Guide.
??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.

Token Description
??SUBNET_MASK?? The subnet mask that was specified in the
??DEF_GATEWAY?? The default gateway that was specified in the
??DNS_SERVER?? The DNS server that was specified in the
??HOST_NAME?? The computer name that was specified in the
Basic Config panel of the system package
Basic Config panel of the provisioning
wizard.
??ROOT_PASSWORD?? The root password that was specified in the
wizard.
??NET_DEVICE?? The network device that was specified in the
wizard.
??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 913).
??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 903).
??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 903).

To edit the AutoYaST file:
1 Click the AutoYaST Entries tab.
2 Check Customize the AutoYaST file.
A message warns that the AutoYaST file will be generated using your current
settings in the system package wizard.
3 Edit the XML of the AutoYaST file.
The BMC BladeLogic 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.
4 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 have 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.

NOTE
provisioning wizard logs in 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.
For information about roles and permissions, see Chapter 6, Managing access.

Enter commands that are included in 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. Any commands you enter into the post-install
script are appended to commands that BMC BladeLogic 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.
1 Click the Post-Install config tab.
BladeLogic console to the RSCD agent you are installing on the server.
the server in the BMC BladeLogic console into a users configuration file on the
B For Post-install batch job, click Browse . The Select Post-Install Batch Job dialog
opens. Use it to navigate to a Batch Job. Select the Batch Job and click OK.
6 Under Post-Install Script, enter any commands that you want added to the post-
install section of the Kickstart or AutoYaST file, or click Select Property to insert
a parameter. (See Using properties to reference scripts on page 1063.)
The commands you enter run one time immediately after an unattended
installation of the operating system.


Defining settings for ESX servers
If you are adding a new property, click Add .
and select Edit from the drop-down menu.
Defining settings for ESX servers

running an ESX operating system.

A tab for the system package appears in the content editor.
following sections:
Pre Install Script ESX

Disk Partition ESX
Basic configuration ESX
Computer Settings ESX
Network ESX
Kickstart Entries ESX
Post-Install Configuration ESX
Local properties ESX


You can use the Pre Install Script tab to 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.
To specify a pre-install script:
1 Open the system package and click the Pre Install Script tab.
2 To specify a custom script, click Add . To edit an existing script, click Edit .
3 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.
4 For Script Contents, do one of the following:
Enter Gentoo Linux commands.
Click Select Property to display a drop-down menu of available properties. Select

the property that contains the script from the list.
NOTE
For information on how to use properties to reference scripts, see Using properties to
reference scripts on page 1063.
5 (Optional) Select Reboot after the script is executed to reboot the server after the
script commands execute.

Disk Partition ESX
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.
Open the system package and click the Disk Partition tab.
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:

scripts.)
If you want 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 .
The Disk Partition dialog opens.
2. Under Partition Configuration, for Mount point, enter the location within a file
directory where a volume should exist or select a location from the drop-down
menu.
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.

Disk Partition ESX
3. Under File System Options, for 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.
swapSupports virtual memory, that is, swapping data in and out of this
partition when there is insufficient RAM to perform an operation.
vmfs3Supports 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.)
4. For Size, do either of the following:
Enter the size of the partition in megabytes.
Check Fill all unused space on disk if you want the partition to fill all
remaining space on the disk.
ESX 4.0 system package: You can specify both the size of the partition in
megabytes and Fill all unused space on disk.
If you are specifying the size of a swap partition, make sure the size you specify
is supported by the specific version of this system packages operating system.
5. For Disk, enter the device name and optionally, parameters related to the device
name. For example: cciss/c0d0 --asprimary.
ESX 4.0 system package:
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.
6. Click OK. The partition appears in the Disk Partitions list.

Creating Virtual Disk Partitions

ESX 4.0 system package only
If you created a data store (storage partition) for the vmfs3 file system, you can create
a virtual partition on it.
1 If you have not done so, define a storage partition disk partition for the vmfs3 file
type. See Disk Partition ESX on page 962.
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.

1 Open the system package and click the Basic Config tab.

A For Computer name, enter a unique name that should be assigned to the server.
different name, enter that name in the OM Server Name box.
If you want this server to display its Computer name when it appears in BMC
BladeLogic console, leave the OM Server Name box blank.
field.
3 Under Provisioning Settings:
For Kickstart network device, enter the name of the network interface that the
server uses to communicate with the HTTP server. Or click Select Property to
display a drop-down menu of available properties.
ESX 4.0 system package: Type the MAC address, using a colon-separated
format (for example: 00:22:19:50:5E:AB) or select the MAC_ADDRESS_CD
property for the colon-separated MAC address.
NOTE
The ESX 4.0 Kickstart does not support ethX as the value for --device.
All other ESX system packages: Enter the name of the network interface, for
example: eth0 or eth1.
For Boot Kernel Parameters, type any additional boot time kernel parameters you
would like to use for the server.
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.


The Computer Settings tab lets you provide information about peripheral devices
and localization settings.
1 Open the system package and click the Computer Settings tab.
2 Under Device Settings, for 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.
3 For 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.
4 Under Localization, for Time zone, select a time zone from the drop-down list.
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.
5 For Locale, select a language option from the drop-down list. For example, in the
United States, select English (USA).
NOTE
The ESX 4.0 system package type does not include this option.
6 (ESX 4.0 System Package only) For License Key, enter the key to the software
license you are using, including all hyphens in the key. Use the format: XXXXX-
XXXXX-XXXXX-XXXXX-XXXXX.
Network ESX
and DNS configuration.
1 Open the system package and click the Network tab.


IP address. Then do the following:
A. Enter the static IP address in the IP address field.
B. For Subnet mask, enter a subnet mask number, which is used to identify
which segment of the network the server is on.
C. For Default gateway, enter the address of the IP router that is used to forward
traffic to destinations outside of the local network.
DNS server. Then, enter an IP address for DNS Server.

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.
For ESX 4.0, kickstart file entries have a format and syntax different from all other
ESX platforms. See Kickstart entries for ESX 4.0 on page 968.
by the standard tabs, type these entries into the second edit box under Additional
entries for the kickstart file.
Check Customize the Kickstart file if you want to modify the automatically generated
entries in the first edit box. Checking Customize the Kickstart file also affects how you
can use the second edit box for additional entries, as described in the two scenarios
below.
Scenario 1

To do this, leave Customize the Kickstart file unchecked and add your new entries in
the second edit box.
Scenario 2
1 Check Customize the Kickstart file.
3 Then, still in the first edit box, add your additional entries.
second edit box.
Kickstart entries for ESX 4.0

The kickstart file for ESX 4.0 has the following characteristics:
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.
NOTE
The ESX 4.0 Kickstart does not support ethX as the value for --device.
If you provided a License Key on the Computer Settings tab, its Kickstart entry is
serialnum.

The --hostname key specifies the name for the installed system. This key works
only with --bootproto=static.
By default, the system specifies --overwritevmfs for 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:
accepteula
keyboard us
serialnum --esx=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
network --bootproto=dhcp --device=??MAC_ADDRESS_CD??
bootloader --location=mbr
clearpart --alldrives --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


NOTE
provisioning wizard logs in 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.
For information about roles and permissions, see Chapter 6, Managing access.
Enter commands that are included in the Kickstart file, which runs once after a
server reboots for the first time after an unattended installation of an ESX
operating system. Any commands you enter into the post-install script are
appended to commands that BMC BladeLogic 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.
1 Open the system package and click the Post-Install Configuration tab.
BMC BladeLogic console but also through Network Shell and the BLCLI. For
6 Under Post-Install Script, enter any commands that you want added to the post-
install section of the Kickstart or AutoYaST file, or click Select Property to insert
a parameter. (See Using properties to reference scripts on page 1063.)

The commands you enter run one time immediately after an unattended
installation of the operating system.

1 Open the system package and click the Local Properties tab.
To add a new property, click Add .
To modify an existing property, right-click the name of the property and select
Edit from the drop-down menu.
Defining settings for Solaris servers

running a Solaris operating system.
In addition to installing an operating system, this procedure lets you run a Batch Job
that can install software and perform other configuration on the server.
A tab for the system package appears in the content editor view.
following sections:
Disk partition Solaris

Basic configuration Solaris
Computer settings Solaris
Network Solaris
Package specifications Solaris

Additional sysidcfg entries

Preview
Add Install Client Script Solaris
Rules File Script Solaris
Begin Script Solaris
Finish Script/Agent Install Solaris
Reboot Script Solaris
x86 Parameters Solaris
Preview
Local Properties Solaris

The information you provide here becomes part of the JumpStart profile file.
2 There are two ways to define a partitionby supplying a script or using the
wizard:
To supply a script, click Use script for disk partitioning, then do one of the
following:

NOTE
To use the wizard, follow the instructions in the rest of this procedure.
3 To define a partition, first select the type of partition you want to define:
Explicit Partition

Default Partition
Existing Partition
4 Then, do one of the following:
click Update or Edit .
If you are adding a new partition, a wizard displays. If you are editing an existing
partition, a tabbed window displays. Both provide the same options.
5 Under Slice Configuration, select one of the following slice options:
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.
6 Click Next.
7 Under Size Options, select one of the following size options:
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.
8 Click Next.
9 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.
10 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.
11 Click Finish. The partition appears in the Disk Partitions list.
To delete a partition, select the partition in the Disk Partitions list and click Delete
.

Note the presence of the Select Property icon . This icon indicates that you can
insert a parameter that refers to a local property to supply the value for this
field. For information on inserting a parameter, see Inserting a parameter in a
system package field on page 1059.
For an example of how inserting a parameter here can streamline provisioning,

see Importing MAC Addresses and Configuration Values on page 1012.

different name, enter that name in the OM Server Name text box.
BMC BladeLogic console, leave the OM Server Name text box blank.
Note the presence of the Select Property icon. This icon indicates that you can

field.
3 Under Install Type, you can optionally check Specify Install Type, then use the
drop-down menu to select one of the following install types:
Initial Install
Flash Install
Note that if you do not specify an install type here, you must do so on the
Additional Profile Entries panel, as described in Preview on page 986.

The Computer Settings tab lets you provide information about localization settings.
A For Timezone:
First, look at the time zones in the drop-down list. If the time zone you need is
there, select it.

Network Solaris
If the time zone you need is not in the drop-down list, click Use a parameter or
specify an unlisted timezone. The drop-down list changes to a field where you
can either type in the name of a time zone, or insert a parameter.
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
If you have created a property for the unlisted time zone(s), you can insert a
parameter that references this property. For information on inserting a
parameter, see Inserting a parameter in a system package field on
page 1059.
B For 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, click Use a
parameter or specify an unlisted system locale. The drop-down list changes to a
field where you can either type in an encoding scheme, or insert a parameter.
(For information on inserting a parameter, see Inserting a parameter in a
system package field on page 1059.)
For information on the system locales supported in the Solaris environment,

consult the Sun Microsystems documentation.
If you have created a property for the unlisted encoding scheme(s), you can
insert a parameter that references this property. For information on inserting
a parameter, see Inserting a parameter in a system package field on
page 1059.
Network Solaris
configuration settings and name service.

Network Solaris
2 Under Network Configuration, if you want this machines primary interface to

connect to the network, check Enable networking on the Primary interface.
3 Under Primary Interface, do one of the following:
Select Initialize the Primary interface using DHCP if the network connection
should obtain an IP address automatically from a DHCP server.
Select Use the following settings if the network connection should use a static IP
address. If you choose this option, enter the static IP address in the IP address
field. For Netmask, enter a subnet mask number, which is used to identify which
segment of the network the server is on. For Default Route, enter the address of
the IP router that is used to forward traffic to destinations outside of the local
network.
If this IP address conforms to the Internet Protocol version 6 (IPv6) network

layer standard, check the Use IPv6 box.
4 Under Name Service Configuration, select the name service this server should use,
or select NONE if this server should not use a name service:

Name Service Associated Fields

NIS Domain Name: Name of the group of systems using NIS.
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.
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:
??

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.
1 Click the Package Specifications tab.
2 Under Meta Clusters, 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.

NOTE

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 BladeLogic 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

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
BladeLogic 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

The Add Install Client Script tab lets you customize the add_install_client command.
1 Click the Add Install Client Script tab.
A default add_install_client command appears in this panel.
2 If you want to customize the add_install_client command, check Customize

add_install_client script, then do one of the following:
Type your customized script directly in the input box.

NOTE
3 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.

1 Click the Rules File Script tab.
2 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

Select the property that contains the rules.
NOTE
The rules are included in the Jumpstart rules file.
To view the customizations, make sure Advanced Options shortcuts are displayed.
(Choose View => Advanced Options.) Click the Preview tab and then click Rules
Entry.
To return to the default rules file contents, clear the Customize add_install_client
script option.

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 has
been installed yet, but this script can do things like perform special disk partitioning
operations or change EEPROM settings.
1 Click the Begin Script tab.


NOTE

The Finish Script/Agent Install tab lets you specify processes you would like to run
after the operating system is installed on the server. You can:
console or Network Shell. (For a Solaris WAN boot installation, this option is not
available.)
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.
NOTE
If you specify a post-install Batch Job, make sure that the provisioning operator who runs
the provisioning wizard logs in 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. For information about roles and permissions, see Chapter 6, Managing access..
Specify any additional scripts you want to run after the operating system is
installed. Any commands you enter into the finish script are appended to
commands that BMC BladeLogic 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.
1 Click the Finish Script/Agent Install tab.

A Check Run post-install Batch Job.
B For Post-install Batch Job, click Browse . The Select Post-Install Batch Job dialog
5 Under Finish Script, specify the contents of the JumpStart finish script by doing one
of the following:

NOTE
The finish script runs one time immediately after an unattended installation of the
operating system.

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 BladeLogic representative. You
will need to customize the scripts for your specific device hardware and networking
environment, but the sample scripts can provide you with a useful head start.
1 Click the Reboot Script tab.


NOTE

Applies to: x86 system packages only
The x86 Parameters tab lets you define fdisk partitions and kernel parameters for the
x86 servers being provisioned. The fdisk information you provide here becomes part
of the JumpStart profile file. The x86 kernel parameters are passed to
add_install_client.
1 Click the x86 Parameters tab.
2 Specify fdisk partition information, as described in FDisk Partitions on page 984.
3 Specify kernel parameters, as described in Kernel Parameters on page 985.
FDisk Partitions
1 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 displays. If you are editing an existing
partition, a tabbed window displays. Both provide the same options.
2 The Disk Name panel lets you specify where this fdisk partition is located. Select
one of the following options:
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.
3 Click Next.
4 The Type panel lets you specify what type of fdisk partition this is. Select one of the
following options:
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.
5 Click Next.
6 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.
7 Click Finish. The partition appears in the FDisk Partitions list.
Kernel Parameters
Use this procedure to add new or modify existing kernel parameters.
1 For Kernel Parameters, do one of the following:
To create a new kernel attribute/value pair, click Add .

Preview
To modify an existing attribute/value pair, select the pair in the x86 Kernel
Parameters list and click Open .
2 Specify a kernel Attribute Name and associated Value.
3 Click OK.
To delete an attribute/value pair, select the pair in the x86 Kernel Parameters list
and click Delete .
Preview
The Preview tab lets you examine the contents of:
sysidcfg file
profile file
rule entry to be added to the rules file
add_install_client command options
This panel is display only.
Local Properties Solaris

and select Edit from the drop down menu.

Defining settings for AIX servers
Defining settings for AIX servers

running an AIX operating system.
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

Target disk AIX
Localization settings AIX
Network Config AIX
NIM scripts
Control flow
Optional Bosinst Attributes
Agent Install/First boot script AIX
Pre Machine Definition Scripts
Pre bos_inst Script
Post bos_inst Script
Preview
Local properties AIX




C The Nim Machine Name field indicates the name by which this machine will be
known within the NIM environment. Depending on what the machines host
name is, either leave this field blank or fill it in as described below:
NIM machine names cannot contain periods in the name, but a host name can
be fully qualified with respect to domain, and therefore can include periods.
If the machines host name is a legal NIM machine name (no periods), leave
this field blank to indicate that this machines NIM name is the same as its
host name.
If the machines host name is not a legal NIM machine name (includes
periods), type in a legal NIM name for this machine.
D For Root password, enter the password used to access the root account. Then
field.

Target disk AIX
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.
1 Click the Target Disk tab.
2 If you want to specify target disk information by using a script rather than by
using the target disk GUI fields, 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 on inserting a parameter, see Inserting a
parameter in a system package field on page 1059.
Skip the rest of this procedure.
3 If you want 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 .
4 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 on the rules of precedence for these fields.

The Localization Settings tab lets you provide localization information.
1 Click the Localization Settings tab.
2 For BosInst Locale, first, look at the locales in the drop-down list. If the locale you
need is there, select it.

If the locale you need is not in the drop-down list, click Use a parameter or specify an
unlisted locale for use during bosinst. The drop-down list changes to a field where
you can either type in the name of a locale, or insert a parameter.
For a list of valid locales, consult the AIX documentation.
If you have created a property for the unlisted locale(s), you can insert a
parameter, see Inserting a parameter in a system package field on page 1059.
3 For Cultural Convention, select the cultural convention you want to use.
If the cultural convention you need is not in the drop-down list, click Use a
parameter or specify an unlisted locale for the cultural convention. The drop-down list
changes to a field where you can either type in a cultural convention, or insert a
parameter.
For information on the cultural conventions supported in the AIX environment,

consult the AIX documentation.
If you have created a property for the unlisted cultural convention(s), you can
insert a parameter that references this property. For information on inserting a
4 For Messages Catalogs, select the messages catalogs you want to use.
If the messages catalogs you need are not in the drop-down list, click Use a
parameter or specify an unlisted locale for the messages catalogs. The drop-down list
changes to a field where you can either type in a messages catalogs name, or insert
a parameter.
For information on the messages catalogs supported in the AIX environment,

If you have created a property for the unlisted messages catalogs, you can insert
a parameter that references this property. For information on inserting a
parameter, see Inserting a parameter in a system package field.
5 For Keyboard, select the keyboard map you want to use.

Network Config AIX
If the keyboard you need is not in the drop-down list, click Use a parameter or
specify an unlisted locale for the keyboard map. The drop-down list changes to a field
where you can either type in a keyboard map, or insert a parameter.
For information on the keyboard maps supported in the AIX environment,

If you have created a property for the unlisted cultural convention(s), you can
insert a parameter that references this property. For information on inserting a
Network Config AIX

The Network Definition tab lets you provide networking information for a server.
1 Click the Network Config tab.
2 Under NIM Network object definition, use the following fields:
If you want to use the NIM find_net keyword to find the target machine you
want to provision, leave Use an existing network object checkbox 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.
If you want to use an existing network object, check Use an existing network
object and specify the objects name in the Network object name field.
If you want to browse for an object, click Browse .
3 If you are planning to use the find_net keyword to find a network object, fill in the
fields in the Specify net definitions settings section. If you specified a network object
explicitly in the previous step, skip this step.
For Network Type, specify one of the following types:
ent
tok
fddi
generic
For Subnet Mask, enter a subnet mask number, which is used to identify which
segment of the network the server is on.
4 Under Optional net_definition settings, you can optionally fill in the following
fields:

For Network Name, you can specify a name to use for a network object you
define, if NIM is not able to match the NIM device to an existing network.
For Client Gateway, you can specify the IP address or host name of the default
gateway that the target machine uses to communicate with the NIM master.
For Master Gateway, you can specify the IP address or host name of the default
gateway used by the NIM master to communicate with clients on other subnets.
5 Under Optional Machine definition settings, you can optionally fill in the following
fields:
For Network Adapter Name, you can specify the logical device name of the
network adapter in the target machine you plan to provision.
6 Under resolve.conf definition, fill in the following fields:
For DNS IP Address, specify the IP address of the DNS server that the target
machine will use.
For Domain Name, specify the default domain to use when looking for machines
via a host name, and the host name is not fully qualified.
Note the presence of the Select Property icon . This icon indicates that you can insert
a parameter that refers to a local property to supply the value for each field. For
information on inserting a parameter, see Inserting a parameter in a system package
field on page 1059.

The Firstboot Script/Agent Install tab lets you specify processes you would like to
run after the operating system is installed on the server. You can:
the server.

NOTE
Job. For information about roles and permissions, see Chapter 6, Managing access.
Specify the first script you want to run after the operating system is installed. This
script runs before any post-install Batch Job that you specify.
1 Click the Firstboot Script/Agent Install tab.
A Check Run post-install batch job.
5 Under First boot Script, specify the contents of the NIM first boot script by doing

NOTE

The first boot script runs one time immediately after an unattended installation
and reboot of the operating system.

and click Edit from the drop down menu.
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.
1 Click the NIM scripts tab.
To define a new script, click Add .
To modify an existing script, select the script in the list and click Edit .
A script dialog displays.
3 For Script Name, do one of the following:

Control flow

4 For Verbose Level, you can use the drop-down menu to specify the verbose level of
the scripts output. You can specify levels from 1 to 5, 1 being the least verbose and
5 being the most verbose. You can also select 0, which means that the verbose level
is unspecified.
Type the contents of the script.

NOTE
6 Click OK.
To delete a script, select the script in the list and click Delete .
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 from the list.


You can use the Bosinst Attributes tab to specify additional bosinst attribute/value
pairs, which are passed on to the nim -o bosinst operation.
1 To define an additional attribute/value pair, 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 .
An edit dialog displays.
2 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.
3 For Value, specify the value of the attribute.
You can use property references in this field too, using the same techniques
described above.
4 Click OK.
Pre Machine Definition Scripts

This script, if specified, is executed on the NIM master before the targets machine
object is defined in NIM. You can leave this tab empty, or specify a script as described
in Using properties to reference scripts on page 1063.
Pre bos_inst Script

This script, if specified, is executed on the NIM master before the bosinst operation is
executed. You can leave this panel empty, or specify a script as described in Using


This script, if specified, is 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
Preview
bosinst.data file
Machine definition command
NIM resource definition
Bosinst command
Defining settings for HP-UX servers

running the HP-UX operating system.
A tab for the system package appears in the Content Editor view.
following sections:
Basic configuration HP-UX

Disk partition HP-UX
Computer settings HP-UX
Network settings HP-UX
Ignite Commands/Scripts
Ignite parameters
Software selection

Boot script
Post-install config HP-UX
Preview
Local properties HP-UX


If you want this server to display its Computer name when it appears within
the BMC BladeLogic console, leave the OM Server Name text box blank.


field.

You can use the default Ignite disk partitioning, or specify your own disk partitioning
script.
2 If you want to use the default disk partitioning configuration associated with this
system package type, click Use Default Disk Partition.
3 If you want to provide your own script for disk partitioning, click Use Custom Disk
Partition. Then either type the script into the box, or use a property to reference the
script, as described in Using properties to reference scripts on page 1063.
Computer settings HP-UX

The Computer Settings tab lets you provide information about localization settings.
A For Timezone:
First, look at the time zones in the drop-down list. If the time zone you need is
there, select it.
If the time zone you need is not in the drop-down list, click Use a parameter or
specify an unlisted timezone. The drop-down list changes to a field where you
can either type in the name of a time zone, or insert a parameter.
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
If you have created a property for the unlisted time zone(s), you can insert a
page 1059.
B For Keyboard, select the keyboard map you want to use.
If the keyboard you need is not in the drop-down list, click Use a parameter or
specify an unlisted locale for the keyboard map. The drop-down list changes to a
field where you can either type in a keyboard map, or insert a parameter.
For information on the keyboard maps supported in the HP-UX

environment, consult the HP-UX documentation.
If you have created a property for the unlisted keyboard map, you can insert
a parameter that references this property. For information on inserting a
page 1059.

The Network Settings tab lets you provide networking information for a server.
1 Click the Network Settings tab.

which segment of the network the server is on. For Default gateway, enter the
address of the IP router that is used to forward traffic to destinations outside of
the local network.

DNS server. Then, enter an IP address for Primary DNS Server and an IP address
for Secondary DNS Server.
4 Under LAN Configuration, specify MAC address of the server in the Hardware
Address field.
5 If you want to use a network configuration script, click Use Network Configuration
Script. Then either type the script into the box, or use a property to reference the
script, as described in Using properties to reference scripts on page 1063.
Ignite scripts are shell scripts that the Ignite master runs on the client when the base
operating system is finished being installed. The Ignite Commands/Scripts tab lets
you define Ignite scripts to customize the target machines operating system before it
reboots for the first time.
1 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 displays.
2 For Script Name, do one of the following:

Type the contents of the script.

Ignite parameters

NOTE
4 Click OK.
To delete a script, select the script in the list and click Delete .
Ignite parameters
The Ignite Parameters tab lets you add parameter entries to the following Ignite
configuration 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
If you want 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, as
described in Using properties to reference scripts on page 1063.

Boot script
Boot script
This script, if specified, provides instructions to automatically reboot the target
during provisioning. You can either type the script into the box, or use a property to
reference the script, as described in Using properties to reference scripts on
page 1063.
Post-install config HP-UX

The Post-Install Config tab lets you specify processes you would like to run after the
operating system is installed on the server. You can:
the server.
NOTE
Job. For information about roles and permissions, see Chapter 6, Managing access.
Specify the first script you want to run after the operating system is installed. This
script runs before any post-install Batch Job that you specify.
1 Click the Post-Install Config tab.

Preview
A Check Run post-install batch job.
5 Under Post-Install Script, specify the first script you want to run after the operating
system is installed. You can either type the script into the box, or use a property to
reference the script, as described in Using properties to reference scripts on
page 1063.
Preview
Complete configuration script

Software selection script
Other configuration script
Disk partition script
Network configuration script
Local properties HP-UX

and click Edit from the drop down menu.

Organizing system packages
Organizing system packages

In the Depot folder, you can perform any of the following procedures to organize
system packages:
Create folders
Cut and paste folders
Copy, cut, and paste system packages
Delete folders and system packages
Folders, access control, and system package sharing: an

example
In some environments, certain users may be responsible for designing system
packages, and other users may be responsible for running the provisioning wizard to
provision the devices. Here 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.
1 Create two roles, for example:
ProvisioningDesigners
ProvisioningOperators
For information on creating roles, see Chapter 6, Managing access.
2 In the Depot folder, 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.
For more information, see Creating a folder or group on page 91. For
page 186.

Importing and exporting system packages
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.
For information on moving a system package from one folder to another, see
Copying, cutting, and pasting groups, folders, and system objects on page 95.
Importing and exporting system packages

You can export system packages to an external file system and then import that
system package back into the BMC BladeLogic system. The procedure for importing
and exporting system packages is the same as the procedure for importing and
exporting BMC BladeLogic objects.
NOTE
To export to machines other than your local machine, you must have, at minimum, the
Server.Browse authorization.
1 In the Depot folder, do either of the following.
To export a system package: Navigate to the system package, right-click, and

select Export from the pop-up menu.
To import a system package: Navigate to the folder where you want to put the
system package. Right-click the folder and select Import from the pop-up menu.
2 Use the Export dialog or the Import wizard, as described in Importing and
exporting BMC BladeLogic objects on page 101.
Working with manually imported devices

Devices can be in one of two states. The state of a device is indicated by the folder that
contains the device:
ImportedRegistered with the BMC BladeLogic system, but not yet provisioned.

Manually importing a device
ProvisionedProvisioned with an operating system and possibly additional post-

install software.
In a PXE environment, devices can become imported in two ways:
When they boot up and are connected to the network, they automatically appear as
imported devices in BMC BladeLogic system.
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
BladeLogic 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 (see Creating a Provision Job on page 1024), many of the
fields will be automatically filled in.
For more information on working with manually imported devices, see:
Adding devices one at a time, as described in Manually importing a device on

page 1007.
Importing a list of devices, as described in Manually importing a list of devices

on page 1011.

Use this procedure to manually import a single device.
1 Right-click the Devices folder and select Add Device. A wizard displays.
2 For MAC Address, enter the MAC address of the device 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
3 For Description, you can optionally provide descriptive text.
PXE only: For Boot Image File, choose the image file you want to use for this device.
The drop-down menu lists standard image files.

packages.
4.0.
machines.
machine.
connected to the machine.
machines.
4 These files are created as part of the standard installation process, as described in
the BMC BladeLogic Installation Guide.
If you created a custom image file, its name appears here too. For information
about custom image files, see Configuring boot image files on page 919.
5 For 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.)

6 Use the Properties list to 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
Environment Property Value Required or Optional?
PXE ARCHITECTURE Set ARCHITECTURE Required
to one of the
following:
x86
x64
JumpStart ARCHITECTURE Set ARCHITECTURE Required
to one of the
following using all
lowercase letters as
shown:
sun4u
sun4v
x86 JumpStart ARCHITECTURE Set ARCHITECTURE Required
to:
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 Optional
PLATFORM to one of
the following values,
using the drop-down
list:
chrp
rs6k
rspc

Provisioning
Environment Property Value Required or Optional?
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
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 Required
values:
PA-RISC
Itanium
For information on how to edit the value of a property, see Setting values for
The Properties list shows properties defined for the Device class in the Property
Dictionary.
The Permissions panel defines permissions for this device in the form of an access
control list (ACL). The ACL specifies the roles that have access to this device and
the types of actions those roles are authorized to perform.
8 Use the Permissions panel to define permissions for this device. For more
page 186.

Manually importing a list of devices
9 Click Finish. This device is now part of the BMC BladeLogic system.

This section describes two approaches for manually importing a list of devices:
Importing a list of MAC addresses for the devices you want to manually import.
See Importing a list of MAC addresses on page 1011.
Importing a list of MAC addresses for the devices you want to import, and
assigning configuration values to each device. See Importing MAC Addresses
and Configuration Values on page 1012.
Importing a list of MAC addresses

Using this procedure to import a list of the MAC addresses for the devices you want
to manually import.
1 Create a text file that lists the MAC addresses of your devices.
PXE, JumpStart, x86 JumpStart, or Ignite: If you are using one of these provisioning
technologies, you must also specify the architecture as well as the MAC address for
each device.
PXE architectures: x86, amd64

JumpStart architectures: sun4u, sun4v
x86JumpStart architecture: i86pc
Ignite architectures: PA-RISC, Itanium
Use one of the following formats:
PXE, JumpStart, x86 JumpStart, or Ignite Format

Format Example File
MAC,ARCHITECTURE MAC,ARCHITECTURE
00-0B-CD-1B-E0-44,x86
00-C0-9F-4B-9E-1B,amd64
00-0B-CD-1B-E0-44,sun4u
00-C0-9F-4B-9E-1B,sun4v
00-D4-EF-3A-8A-2B,i86pc
00-0C-4B-D4-CD-3A, Itanium
00-C0-1B-D5-8B-33, PA-RISC
NIM Format

PXE, JumpStart, x86 JumpStart, or Ignite Format

Format Example File
MAC MAC
00-0B-CD-1B-E0-44
00-C0-9F-4B-9E-1B
In addition to specifying the MAC addresses of your devices, your import file can
contain additional optional configuration values. For more information, see
Creating a MAC address file on page 1015.
2 Import this list as described in Importing the MAC address file on page 1017.
Importing MAC Addresses and Configuration Values

Use this procedure to import a list of MAC addresses and assign configuration values
to the devices represented by the MAC addresses. This description explains how to
associate a computer name with each MAC address. If you do this, the provisioning
operator does not have to type in a computer name for each device when
provisioning devices (see Creating a Provision Job on page 1024). You can use the
techniques described below to automatically fill in many other wizard fields as well.
Use this general procedure to manually import a list of devices with configuration
values for each device. Follow the references for detailed information about each step.
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
For instructions on how to add a property to a built-in class (like the Device class),
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:
LOCAL_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 1014.

3 Edit a system package to use your newly created local property. (For information
on how to create a system package, see Creating a system package on page 925.)
You need to enter your newly created local property in the Computer name field on
the system packages Basic Configuration panel. In this example, you would 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 931

Basic configuration Linux on page 951
Basic configuration ESX on page 964
Basic configuration Solaris on page 974
Basic configuration AIX on page 987
Basic configuration HP-UX on page 998
4 Create a MAC address import file. This file contains the MAC addresses of all the
devices you want to import, along with the property values you want to assign to
each device.
For instructions on how to do this, see Creating a MAC address file on

page 1015.
5 Import the MAC address file into BMC BladeLogic.
For instructions on how to do this, see Importing the MAC address file on
page 1017.
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. (For information on running the provisioning wizard to configure a device,
see Creating a Provision Job on page 1024.)
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.)

Then define your

If you want this Create a Device class Create a local system system package to
provisioning wizard property called... package property use the new property
field to be filled in... called... like this...
Panel 2: Basic Config COMPUTER_NAME LOCAL_COMPUTE On the Basic Config
R_NAME panel of the system
Computer name package, fill in the
Set Default value Computer name field
(See Basic Config.) field to: like this:
DEVICE.COMPUTE ??LOCAL_COMPUT
R_NAME ER_NAME??
Panel 2: Basic Config OM_NAME LOCAL_OM_NAME On the Basic Config
panel of the system
OM Server name Set Default value package, fill in the
field to: OM server name
(See Basic Config.) field like this:
DEVICE.OM_NAME
??LOCAL_OM_NAM
E??
Creating a local property in the system package

Use this procedure to 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. (For
instructions on how to add a property to a built-in class like the Device class, see
Adding or modifying properties on page 125.)
In this example, assume you call your local property:
LOCAL_COMPUTER_NAME
1 In the Depot folder, navigate to the system package, right-click and select Open
3 Click Add to add a new property. The Add Property dialog displays.
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??
Creating a MAC address file

Use this procedure to create a text file that contains:
The MAC addresses of the devices you plan to manually import.
PXE, JumpStart, Ignite only: the architecture for each device (x86, amd64, sun4u,
sun4v, i86pc, Itanium, PA_RISC).
NIM only: Optional CABLE_TYPE, PLATFORM, NETBOOT_KERNEL, and

NET_SETTINGS values for each device.
Additional optional property values you want to assign to each device.
Use the following comma-separated values (CSV) format:
The first line of the file must contain the column header:
MAC (for NIM devices)

MAC,ARCHITECTURE (for PXE, JumpStart, Ignite devices)
followed by optional comma-separated property names of any properties you

want to set for each device.

NOTE
Before you list a property name in this import file, the property must already exist as a
Device property.
For information on how to add a property to the Device class, see Adding or
modifying properties on page 125.
Note that the MAC address is a default Device class propertyyou do not have
to add it. You also do not have to add the PXE/JumpStart/Ignite
ARCHITECTURE property, or the NIM CABLE_TYPE, PLATFORM,
NETBOOT_KERNEL, or NET_SETTINGS properties.
Subsequent lines of the file must contain valid MAC addresses (and architecture
specifications, if JumpStart/Ignite) for each device you want to provision, followed
by optional comma-separated property values for each device.
Examples:
The first examples simply list the MAC addresses of your devices.
NIM Example PXE, JumpStart or Ignite Example

MAC MAC,ARCHITECTURE
00-0B-CD-1B-E0-44 00-0B-CD-1B-E0-44,x86
00-C0-9F-4B-9E-1B 00-C0-9F-4B-9E-1B,x64
00-02-B3-B1-1B-E3 00-0B-CD-1B-E0-44,sun4u
00-C0-9F-4B-9E-1B,sun4v
00-02-B3-B1-1B-E3,sun4v
00-0C-4B-D4-CD-3A,Itanium
00-C0-1B-D5-8B-33,PA-RISC
This next example shows how to specify COMPUTER_NAME values for several
MAC addresses. (Note that COMPUTER_NAME values must not contain spaces.)
NIM Example PXE, JumpStart or Ignite Example

MAC,COMPUTER_NAME MAC,ARCHITECTURE,COMPUTER_NA
00-0B-CD-1B-E0-44,"Sales1" ME
00-C0-9F-4B-9E-1B,"Sales2" 00-0B-CD-1B-E0-44,x86,"SalesA"
00-02-B3-B1-1B-E3,"Sales3" 00-C0-9F-4B-9E-1B,amd64,"SalesB"
00-0B-CD-1B-E0-44,sun4u,"Sales1"
00-C0-9F-4B-9E-1B,sun4v,"Sales2"
00-02-B3-B1-1B-E3,sun4v,"Sales3"
00-0C-4B-D4-CD-3A,Itanium,Sales4
00-C0-1B-D5-8B-33,PA-RISC,Sales5

Importing the MAC address file

Use this procedure to import a MAC address file.
1 Right-click the Devices folder and select Import. The MAC Addresses panel
displays.
2 Click Add to display the Select File panel.
3 For Provisioning Method, click either PXE, JumpStart, x86 JumpStart, NIM, Ignite
PA-RISC, or Ignite Itanium.
PXE only: For Boot Image File, select the boot image file you want to use. The drop-
down menu lists standard image files.

packages.
4.0.
machines.
machine.
connected to the machine.
machines.
These boot image files are created as part of the standard installation process, as
described in the BMC BladeLogic Installation Guide.
If you created a custom image file, its name appears here too. For information
about custom image files, see Configuring boot image files on page 919.

Device Smart Groups
4 Navigate to the MAC address file you created in Creating a MAC address file on
page 1015.
5 Click the MAC address file name, and then click OK to return to the MAC
Addresses panel.
The file import mechanism alerts you of any syntactical errors in the file.
This panel defines permissions for the devices listed in the file in the form of an
access control list (ACL). The ACL specifies the roles that have access to these
devices and the types of actions those roles are authorized to perform.
7 Use the Permissions panel to define permissions for the devices listed in the file.
object on page 186.
8 Click Finish.
The devices now appear in the Imported contents pane.
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.
To create a device smart group, see Defining a smart group on page 92.
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.

Monitoring the provisioning status of servers
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. See Limiting objects
using filters on page 66.
NOTE
The Imported and Provisioned folders are BMC BladeLogic-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.
Monitoring the provisioning status of servers

You can monitor the provisioning status of servers by doing any of the following:
Viewing devices that have been registered with BMC BladeLogic but have not yet
been provisioned (see Viewing imported devices on page 1019).
Viewing servers that have been provisioned (see Viewing provisioned servers
on page 1020).
Viewing a devices properties, permissions, and manufacturer settings (see

Viewing device information on page 1020).
Examining a servers provisioning history (see Viewing a servers provisioning

history on page 1022).
Examining a system packages provisioning history, meaning all the servers a

system package has provisioned (see Viewing a system packages provisioning
history on page 1023).
Changing the provisioning status of servers. You can classify a server as imported
(see Re-provisioning servers on page 1042) or provisioned (see Classifying
servers as provisioned on page 1023).
Viewing imported devices

Imported devices have been registered with BMC BladeLogic, but have not yet been
provisioned.
In a PXE environment, these 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 these devices manually.

Viewing provisioned servers
To view imported devices, in the Devices folder, open the Imported folder.
Viewing provisioned servers

Provisioned servers are servers that have already completed the provisioning
process. When a server has been provisioned, the operating system has been
successfully installed and a post-install job may have begun running, depending on
the scheduling parameters set for that job. The post-install job does not have to
complete for a server to be in a provisioned state.
To view provisioned devices, in the Devices folder, open the Provisioned folder.
Viewing device information

Use this procedure to view information about a specific device. Depending on the
device, you can also change some of its information, such as its description,
architecture, or associated boot image file.
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.
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:

Viewing and changing device properties
A Open the Devices folder and select the device.
B To display the view you want, click its tab in the Properties, Permissions, and
Audit Trail tab group.
For information on these views, see Properties, Permissions, and Audit Trail tab
group on page 98.
Viewing and changing device properties

To view a devices properties, display its Properties view:
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. For information about this view, see Properties
view on page 98.
To edit a property:
1 Click 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.
class.
??MyPARAMETER??) or click the Select Property . For more information, see
NOTE
To change the value for the ARCHITECTURE property, do not use the Properties view.
Instead, open the device in the device editor and change the value there. See Viewing device
information on page 1020.

Viewing a servers provisioning history
Viewing a servers provisioning history

Use this procedure to display provisioning history for a server. With this procedure
you can see every system package that has been applied to a server. You can also
view detailed log information for each provisioning job that has been run on a server.
1 Open the Devices folder and do one of the following:
Open the Provisioned folder and select a server.

Open the Imported folder and select a server
2 Right-click a server and select View provision history from the pop-up menu.
The Provision History window appears. The System Packages area (on the left side
of the window) 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 displays:
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. 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.
4 To view the system package settings that were used in this job run, click the
System Package Details tab. (For information about system package settings, see
Creating a system package on page 925.)
NOTE
If you migrated this job from a previous version, the Properties section of the System Package
Details window does not display.
NOTE
If you cancel a JumpStart provisioning job while it is running, you may 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
Viewing a system packages provisioning history

Use this procedure to display provisioning history for a system package. With this
procedure you can see every provisioning job that has been run using this system
package. This lets you know every server that this system package has provisioned.
You can also view detailed log information for each provisioning job that has been
run on each server.
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
the job runs that have used this system package. Each job run entry includes the
name and MAC address of the server 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.
Classifying servers as provisioned

Use this procedure to classify a server as provisioned without actually provisioning
the server. By doing this, you can easily include existing servers in a system managed
by BMC BladeLogic.
1 In the Devices folder, open the Imported folder.
2 Select the server, right-click, and select Set as provisioned from the pop-up menu.
Deleting servers
Use this procedure to delete a server from those listed as imported or provisioned.
For example, if you change the network card on a PXE server, this server is identified
as newly imported. In this situation, you should delete the old entry for the server
(that is, the entry with the servers old MAC address).
1 In the Devices folder, open the Provisioned folder.
2 Select a server, right-click, and select Delete from the pop-up menu. A confirmation
dialog displays. Click Yes to confirm the deletion.

Creating a Provision Job
Creating a Provision Job

You provision servers using a Provision Job, a BMC BladeLogic job that, when
executed, applies a system package to a server and begins an unattended installation
of the operating system.
Use this procedure to create a Provision Job. This procedure launches the Provision
Device wizard, which first asks you to choose the system package you want to apply
and then allows you to override settings defined in the package.
You can create a Provision Job in either of two ways:
Create a job in the Jobs folder. The BMC BladeLogic system creates the job and
stores it in the Jobs folder. Use this method to create a Provision Job that you can
edit, execute at any time, or schedule for execution.
Create a job directly from a device. Use this method to create a Provision Job that
executes automatically when you finish the creation.
Prerequisites:
Create a boot image. For information, see Creating boot image files on page 868.
Create a system package. For information, see Creating a system package on

page 925.
Create a folder for Provision Jobs. Right-click the Jobs folder and select New => Job
Folder.
To create a Provision Job:
1 Start the Provision Device wizard. Do either of the following:
To create a Provision Job from the Jobs folder, open the Jobs folder, right-click a
folder, and select New => Provision Job.
To create a Provision Job from a device (the job executes automatically):
1. In the Devices folder, open the Imported folder.
2. Right-click a device and select Provision.
The Provision Device wizard opens.
2 Define the Provision Job, as described in the following sections. (Note that the
panels and their sequence vary, depending on the type of Provision Job.)

General
General
Choose Devices
System Package Selection
Select Image (PXE only)
System Package Properties
Basic Config
Network Config
Post-install Configuration
Provisioning Job Settings (PXE only)
Optional Bosinst Attributes (NIM only)
Begin Script (JumpStart only)
Server ACL
Server Properties
Properties
Provisioning Summary (multiple servers only)
Once you are familiar with the fields in the wizard, you might want to consider
streamlining some of the wizard selections by using parameterized properties in
your system package definitions. For an example of how to do this, see
Streamlining the wizard with parameterized properties: an example on
page 1058.
The job is stored in the Jobs folder of the BMC BladeLogic console.
If you created the job directly from a device, the job executes automatically. The job
appears in the Tasks in Progress view. For information about this view, see
Managing jobs in progress on page 427.
If you created the job from the Jobs folder, the BMC BladeLogic system creates the job
and stores it in the Jobs folder. You can execute the job at any time. See Executing a
Provision Job on page 1033.
General
The General panel of the Provision Device wizard lets you provide information that
identifies a Provision Job.
1 For Name, enter an identifying name for the Provision Job. For Description, you can
2 For Save in, click Browse to select the Job folder where you want to store this
Provision Job. The Select Folder dialog opens. Select a folder or click New Job
Folder to create one. Then click OK.

Choose Devices
access simultaneously. See the BMC BladeLogic Server Automation Administration
Guide for more information on configuring Application Servers.
managed servers.
5 Click Next.
Choose Devices
The Chooses Devices panel of the Provision Device wizard lets you choose the
devices you want to provision with the Provision Job.
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 BladeLogic 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.


The System Package Selection panel of the Provision Device wizard lets you identify
the system package and the boot image to use for provisioning one or more servers.
For Path to System Package, click Browse to select the system package that should
be used to provision the server(s).
From the Selected Boot Image list, select the boot image that should be used to
provision the server(s).

(For creating Provision Jobs from the Jobs folder)
The Select Image panel of the Provision Device wizard lets you identify the boot
image to use for provisioning one or more servers.
From the Selected Boot Image list, select the boot image for provisioning the servers.

The System Package Properties panel of the Provision Device wizard lets you select
which instance of the Data Store you want to use. It also lets you specify values for
any properties you added to this system package.
For information about Data Store instances (used to specify the location of your
installation files), see Configuring the data store on page 903.
For information about adding properties to system packages, see Local

properties Windows on page 948, Local properties Linux on page 959,
Local properties ESX on page 971, Local Properties Solaris on page 986,
Local properties AIX on page 994, and Local properties HP-UX on
page 1004.
For information on editing property values, see Setting values for system object

Basic Config
Basic Config
The Basic Config panel of the Provision Device wizard lets you provide local
information about a server, such as its name, workgroup, domain, and user account.
Specifying information in the wizard overrides definitions set for the system package
you are deploying to a server.
The type of information you can provide on this panel varies, depending on the type
of server you want to provision. For information about the settings possible on this
page, refer to the appropriate section, listed in the following table.

Windows Basic configuration Windows on page 931
Linux Basic configuration Linux on page 951
ESX Basic configuration ESX on page 964
Solaris Basic configuration Solaris on page 974
AIX Basic configuration AIX on page 987
HP-UX Basic configuration HP-UX on page 998
If you are provisioning multiple servers...

The Basic Config panel contains identifying fields (for example, Computer Name and
OM Server Name) that must be unique for each server. The Provision Device wizard
has several features that automate the process of creating unique names:
Suppose you are provisioning 10 servers at once, and you specify an explicit value
in the Basic Config panels Computer Name field, for example MyServer. The
wizard will automatically name the first server MyServer, then name the second
Server MyServer_1, the third server MyServer_2, and so on. These unique names
are visible later on in the wizard, in the Provisioning Summary (multiple servers
only) on page 1029 panel.
Now suppose that, before you started running the Provision Device wizard, you
used the Import Device feature to associate a computer name with each devices
MAC address. (For detailed information on how to do this, see Importing MAC
Addresses and Configuration Values on page 1012.)
In this case, you would see a parameterized property value like

??LOCAL_COMPUTER_NAME?? in the Basic Config panels 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 for some reason, 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).

Network Config
If the parameterized property value results in some devices not having names, you
need to provide names later on in the wizard (see Provisioning Summary
(multiple servers only) on page 1029).
Network Config
The Network Config panel of the Provision Device wizard lets you provide
networking information for a server such as its IP address and DNS configuration.
These settings override any definitions set for the system package you are deploying.
The type of information you provide on this panel can vary, depending on the type of
server you want to provision. For information about the settings possible on this
page, refer to the appropriate section, listed in the following table.

Windows Network Windows on page 942
Linux Network Linux on page 954
ESX Network ESX on page 966
Solaris Network Solaris on page 976
AIX Network Config AIX on page 991
HP-UX Network settings HP-UX on page 1000

The Provisioning Summary panel of the Provision Device wizard takes all the
information you have provided in the previous panels and resolves this information
to show you the actual values that will be assigned to the servers you are
provisioning. For example, starting with a servers MAC address, it shows you each
servers proposed computer name, IP address, etc.
If you want to change some of these proposed values, you can do so, as described in
the following procedure.
1 Click the server (row) whose values you want to edit.
2 Click Update or Edit and type in your new values for the following fields:
Computer name
OM server name
OS license
3 Click OK.


The Optional Bosinst Attributes panel of the Provision Device wizard lets you add,
change, and delete optional bosinst attributes, as described in Optional Bosinst
Attributes.

The Begin Script panel of the Provision Device wizard 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 has been installed yet, but this script can do things like
perform special disk partitioning operations or change EEPROM settings. For
information about the begin script, see Begin Script Solaris on page 981.
The Post-install Configuration panel of the Provision Device wizard lets you specify
options for installing a BMC BladeLogic RSCD agent, running a Batch Job, and
entering commands that are included in a runonce.bat, AutoYaST, Kickstart, or finish
file. For information about the settings possible on this page, refer to the appropriate
section, listed in the following table.

Windows Post-install configuration Windows on page 946
Linux Post-install configuration Linux on page 958
ESX Post-Install Configuration ESX on page 969
Solaris Finish Script/Agent Install Solaris on page 982
AIX Agent Install/First boot script AIX on page 992
HP-UX Post-install config HP-UX on page 1003


The Provisioning Job Settings panel lets you pause a provisioning job after each
logical step. This can be useful for troubleshooting.
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 Job Settings panel are not valid for
provisioning the Linux operating system.
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 provisioning 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 BladeLogic system to stop a job to
let you debug, then start the job again after the last successfully completed logical
step.
To stop a provisioning job, at the target console, press Ctrl+C.
To restart the provisioning job at the same place, at the target console, type:
bmi

Server ACL
If you plan to stop and restart a provisioning 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.
Server ACL
The Server ACL panel of the Provision Device wizard lets you set permissions for the
server you are provisioning in the form of an access control list (ACL). The ACL
specifies the roles that have access to this server and the types of actions those roles
are authorized to perform.
For detailed information on how to work with these ACLs, see Defining permissions
Server Properties
The Server Properties panel of the Provision Device wizard lets you edit property
values for the server you are provisioning. For information on how to edit property
Properties
The Properties panel of the Provision Device wizard lets you edit property values of
the Provision Job you are creating. For information on how to edit property values,
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 1033.
Show the results of a job. See Viewing the results of a Provision Job on
page 1035.
View the status of a running Provision Job. See Managing jobs in progress on
page 427.

Executing a Provision Job
Cancel a job in progress. See Canceling a Provision Job in progress on page 1035.
Open a job to view or edit its contents. See Viewing and editing a Provision Job
on page 1036.
Add devices to or delete them from an existing job. See Changing the devices for a
Provision Job on page 1037.
Show the messages generated by a job. See Viewing the log for a Provision Job
on page 1041.
Export the log from a job. See Exporting the log for a Provision Job on page 1041.
Schedule a job for execution. See Scheduling a Provision Job for execution on
page 1038.
Create smart groups for Provision Jobs. See Defining a smart group on page 92.
Delete Provision Jobs from folders in the Jobs folder. See Deleting a folder, group,
smart group, or system object on page 96.
Cut, copy, and paste Provision Jobs between folders in the Jobs folder. See
Copying, cutting, and pasting groups, folders, and system objects on page 95.

Use this procedure to execute a Provision Job in the Jobs folder. This procedure
executes the job immediately. (To schedule the jobs execution for a specific date and
time, see Scheduling a Provision Job for execution on page 1038.)
In the Jobs folder, select the Provision Job, right-click, and select Execute.
NOTE
If the BMC BladeLogic administrator has specified that this job type requires BMC Remedy
ITSM approval prior to execution, you must select the approval type.
Check the Execute on Approval option, and select an Approval type. Optionally, you can
select to use an existing change ticket for approval. The Execute on Approval field appears
when you:

For information on available approval types and change ticket options, see Setting the
approval type on page 423.

The job appears on the Tasks in Progress view, where you can view its status or
cancel it, if necessary. For information about this view, see Managing jobs in
NOTE
If you execute a Provision Job on servers already provisioned, the job re-provisions
the servers. For information see Re-provisioning servers on page 1042.
What Happens When a Provision Job Executes

When you execute a Provision Job, the provisioning environment determines the
actions the system takes:
PXE Environment:
If you have selected a bare metal server that has just completed a network boot
and is waiting for provisioning instructions, the server is provisioned.
If you have selected an existing server, reboot the server and it is provisioned
automatically.
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 need to manually force the server to boot
from the network, and the server is provisioned automatically.)
The newly provisioned or re-provisioned server is part of the BMC BladeLogic

system.
All Environments: You can re-provision a server by re-executing the Provision Job
associated with the server. (For information, see Re-provisioning servers on
page 1042.) If the existing server was part of the BMC BladeLogic system before
you re-provisioned it, you must redefine any jobs you want to run on the newly re-
provisioned server. Any jobs you want defined for the server before you re-
provisioned it will not run now, even if you keep the same host name for the
machine. For information about setting up jobs, see Chapter 10, Managing jobs.
The newly provisioned or re-provisioned server is part of the BMC BladeLogic

system. For information about working with servers, see Chapter 7, Using the
Servers folder.

Viewing the results of a Provision Job
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 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:
To 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.
To 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 1041.
Export the log for the job. See Exporting the log for a Provision Job on
page 1041.
Canceling a Provision Job in progress

Use this procedure to cancel a Provision Job in progress.
NOTE
To cancel a Provision Job, your role must be granted both ProvisionJob.Cancel and
ProvisionJob.Read permissions.
You can cancel only one Provision Job at a time.

Viewing and editing a Provision Job
1 In the Tasks in Progress view, a Provision Job appears as one job with a work item
for each device being provisioned. Select any work item for the Provision Job.
2 Click Cancel Selected Tasks .
To have a Provision Job automatically cancelled after a certain amount of time, define
a time-out period for the job using the JOB_TIMEOUT property. For information, see
Defining time-outs for jobs on page 444.
Viewing and editing a Provision Job

Use this procedure to view or change the definition of a Provision Job.
1 Open the Jobs folder and navigate to a Provision Job. Right-click the job and select
Open.
The content editor displays tabs that correspond to the panels of the Provision
Device wizard you used to create the job.
General
Choose Devices
Basic Config
Network Config
Server ACL
Server Properties
In addition, there are tabs for editing existing jobs.
Devices Preview: See Changing the devices for a Provision Job.
Schedules: See Scheduling a Provision Job for execution on page 1038.
Default Notifications: See Setting up default notification of job completion on

page 1040.
2 Use the tabs to view or change the job definition.
3 To save your changes, select File => Save.

Changing the devices for a Provision Job
Changing the devices for a Provision Job

Use this procedure to add or delete devices for an existing Provision Job. You can also
edit the computer name assigned to the server in the BMC BladeLogic system.
1 Open the Jobs folder, navigate to a Provision Job, right-click the job and select
Open.
2 Click the Devices Preview tab.
3 Provide information about the IP Configuration for the devices. Select one of the
following:
Obtain IP Address Automatically: Specifies that the network connection should

obtain an IP address automatically from a DHCP server.
Specify IP Later: Specifies that the IP address
Specify IP Range: Specifies a range of IP addresses that can be used for devices.
Start IP: The IP address that starts the range.
End IP: The IP address that ends the range.
Subnet Mask: The subnet mask number which is used to identify which
segment of the network the device is on.
Default Gateway: The address of the IP router used to forward traffic to

destinations outside the local network.
4 To add a device to the job, in Devices to Provision, click Add .
5 In the Select Device dialog, do either of the following:
Check Auto-generate computer name to have the computer name generated for
the server.
For Computer name, enter a unique name for the server. Optionally, for OM
Server Name, enter different name to display when the server appears in the
BMC BladeLogic console.

Scheduling a Provision Job for execution
Note the presence of the Select Property icon for each field. This icon indicates
that you can insert a parameter that refers to a local property to supply the value
for this field. For information on inserting a parameter, see Inserting a
parameter in a system package field on page 1059.

6 In the Available Devices list, select one or more devices and click the right arrow to
move them to the Selected Devices list on the right. Then click OK.
To change the computer name or OM server name to be assigned to a device, select

the device in Devices to Provision and click Edit .
To delete a device from the Provision Job, select the device in Devices to Provision and
click Delete .

Use this procedure to schedule a Provision Job for execution and optionally, to set up
notification via email and SNMP traps when the scheduled job completes.
After you create a Provision Job, you can schedule it for execution. If you created the
job from the Jobs folder, you can edit it to specify the date and time that the job
executes. If you created the job directly from the device, the job executes
automatically; however, after it executes, 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.
To schedule a job for execution:
Open.
2 Click the Schedules tab.
3 Add a new schedule by clicking Add New Schedule or modify an existing

schedule by clicking click Edit Schedule .
To delete an existing schedule, select it and click Remove Schedule .
information:
Schedule
Scheduled Job Notification

5 When you finish entering information on the scheduling window, click OK.
6 To save your changes to the Provision Job, select File => Save.
Schedule
The Schedule tab lets you schedule the execution of a Provision Job.
1 The only scheduling option allowed for Provision Jobs is Once. Provide the
following information:
For On Date, enter the month, day, and year when the job should occur. Use a
yyyy/mm/dd format.
For At, enter the time when the job should occur. Use a 24-hour clock format
(00:00 to 23:59).
NOTE
If the BMC BladeLogic administrator has specified that this job type requires BMC Remedy
ITSM approval prior to execution, you must select the approval type.
Check the Execute on Approval option, and select an Approval type. Optionally, you can
select to use an existing change ticket for approval. The Execute on Approval field appears
when you:

For information on available approval types and change ticket options, see Setting the
approval type on page 423.
Scheduled Job Notification

notifications.
system. The MIB can be found at installationDirectory/Share/BladeLogic.mib.
1 Click the Scheduled Job Notifications tab.

Setting up default notification of job completion
sysadmin@abc.com;sysmgr@abc.com.
a server.
Setting up default notification of job completion

Use this procedure to define default email messages and SNMP traps that are
generated when a job completes. These notifications are sent when you run a job
immediately (that is, you do not schedule the job) or a scheduled job completes but
you did not set up email or SNMP notifications when you scheduled the job.
system. The MIB can be found at installationDirectory/Share/BladeLogic.mib.
To define default notifications:
Open.
2 Click the Default Notification tab.

Viewing the log for a Provision Job
sysadmin@abc.com;sysmgr@abc.com.
a server.
5 To save your changes, select File => Save.
Viewing the log for a Provision Job

Use this procedure to show the messages generated by a Provision 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 that allows you to scroll through messages one by
one, double-click on a message. The Log Item Details dialog opens. Click the Up
arrow or Down arrow to scroll through messages.
Exporting the log for a Provision Job

Use this procedure to export the log generated by a Provision Job. Logs are exported
in CSV format so you can import their contents into spreadsheets and databases.

Re-provisioning servers
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 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 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 re-provision a server by re-executing the Provision Job associated with the
server. You can re-provision servers in either of two ways:
Re-provision from the Provision Job in the Jobs folder. You would use this method
to execute the same Provision Job on the same devices, with the same system
package as before. See Re-provisioning from the Provision Job.
Re-provision from a provisioned device. You might use this re-provisioning

method if you want to provision the same devices but with a different system
package. See Re-provisioning from a device.
NOTE
To re-provision a server, you must have, at minimum, the Server.Decommission
authorization.
Re-provisioning from the Provision Job

Use this procedure to execute the same Provision Job on the same devices, with the
same system package as before.
Open the Jobs folder, navigate to a Provision Job, right-click the job and select Execute.

When the Provision Job starts, the provisioning process does the following:
Automatically decommissions the server, if it is part of the BMC BladeLogic

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, where you can view its
status or cancel it. For information about this view, see Managing jobs in progress
on page 427.
Re-provisioning from a device

Use this procedure to re-provision servers directly from a device by executing the
Provision Job associated with the device. You might use this re-provisioning method
if you want to provision the same devices but use a different system package.
1 In the Devices folder, open the Provisioned folder and select a server.
2 Right-click and select either Re-Provision Now or Re-Provision Later from the pop-
up menu.
If you click Re-Provision Now, 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

BladeLogic environment. In some situations this can take a few moments.
Changes the status of the server 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. For information about this view, see Managing jobs in
If you click Re-Provision Later, the server is automatically decommissioned and

appears as a server 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 Windows 2003 or 2008 servers from a local data store

from a local data store
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 BladeLogic provisioning also lets you
provision Windows 2003 or 2008 servers 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 needed for BMC BladeLogic 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 the WinPE 2.x image for booting from local media
To provision target servers from a local data store:
1 Create a WinPE 2.x 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 the WinPE 2.x image for booting from local media.
To create a WinPE image for booting the target server from the PXE server (PXE
boot), see Creating the WinPE 2.x image for booting from the PXE server on
page 1048.
2 Create a system package that points to the local data store as the location of the
installation files. See Creating a system package for use with a local data store on
page 1048.
3 Associate the local data store instance with the system package. See Associating
the LocalDataStore instance with the system package on page 1051.
Prerequisites
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.
Use this procedure to create an 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 WinPE 2.x boot image file, use either the Image Creation wizard or the
BMC BladeLogic script.
Prerequisites:
Prepare the machine on which images are created. See Preparing a machine for
image creation on page 870.

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 877.
Using the Image Creation wizard to create an image for

local boot
Use this procedure to use the image creation wizard to create the image files for
booting from media connected to the target server (local boot).
1 Select Configuration => Provisioning Image Creation.
2 In the Toolkit Select window, do the following:
A. For the following options, provide information as you normally would in

creating a WinPE 2.x boot image:
Image Toolkit Host
Architecture
Win AIK Directory Path
CreateWinPE Script Directory Path
B. For Image Type, select one or more of the following:
ISO Image: Creates a WinPE 2.x 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 a WinPE 2.x 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.
C. 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:
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.x image files using the image creation wizard on page 872.)
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 877.
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.x
image files using the image creation wizard on page 872.
5 Click Finish.
Using the BMC BladeLogic script to create a local boot

image
Use this procedure to use the CreateWinPE2_x.vbs script to create the image files for
booting from media connected to the target server (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 parameters
.ini file on page 879.
2 Run the CreateWinPE2_x.vbs script as described in Running the

CreateWinPE2_x.vbs script on page 883.

Creating the WinPE 2.x image for booting from the PXE server
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 884.
Creating the WinPE 2.x image for booting from the PXE server
Use this procedure to create an image file for booting from the PXE server (PXE boot)
in conjunction with provisioning from a local data store.
To create the boot image file using the Image Creation wizard, follow the steps
Creating WinPE 2.x image files using the image creation wizard on page 872.
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.
To create the boot image file using the BMC BladeLogic script, follow the steps in
Creating WinPE 2.x image files using the BMC BladeLogic script on page 878.
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 system package for use with a local data store

To create the system package that points to the local data store as the location of the
operating system installation files:
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. (For information, see The CONFIG_STORE
property on page 1052.)
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 (see Creating WinPE 2.x image files using the image creation wizard on
page 872), specify the name of the leaf directory that you provided for RSCD
Installer Path. (This directory contains the rscd.exe and rscd.iss files.) 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 as described in Creating a system package on

page 925 and open it.
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 927.
4 On the Local Properties tab, you can 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 1052.
5 On the Computer Settings tab, define settings for User Information, License setup,
and Localization as described in Computer Settings Windows on page 933.
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 (see Creating WinPE 2.x image files using the image creation wizard on
page 872), 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 If you are creating a Windows 2003 system package and if you need to provide
mass storage drivers in the system package, you must add entries for them to the
unattend.txt file.
A Click the Unattend Entries tab.
B Leave Customize the Unattend Entries file unchecked and add the entries to the
Additional entries for the unattend.txt file.

Associating the LocalDataStore instance with the system package
For example:
[MassStorageDrivers]
"VMware SCSI Controller" = "OEM"
[OEMBootFiles]
vmscsi.sys
vmscsi.inf
vmscsi.cat
txtsetup.oem
8 When you have finished defining system package settings, select File => Save.
Associating the LocalDataStore instance with the system

package
The BMC BladeLogic installation includes an instance of a local data store; you do not
have to create one. Associating the LocalDataStoreInstance with a system package
tells the provisioning system to search the local media for the operating system
installation files needed to provision the target server. You can associate the
LocalDataStoreInstance with a system package when you provision the server.
To associate the LocalDataStoreInstance with a system package:
1 Create the Provision Job, as described in Creating a Provision Job on page 1024.
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 appears.
5 Select LocalDataStoreInstance and click OK.
6 Complete the remaining steps of the Provision Device wizard and click Finish.
When the Provision Job is executed, the target server is provisioned from the local
data store.

The CONFIG_STORE property
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. You would use this property only when provisioning
from a local data store.
You can set the default value 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 drive (UFD)
All (The default value) The provisioning process searches both locations in this
order:
A. In the LDS directory inside the WinPE image.
B. On all supported removable media connected to the target server.
To change the default value of CONFIG_STORE, see Local properties Windows

on page 948.
Provisioning Solaris servers using a WAN boot

installation
Use this procedure to use the WAN boot installation method to provision the Solaris
operating system over a public network to SPARC target servers.
Prerequisites:
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 BladeLogic console.

Provisioning Solaris servers using a WAN boot installation
An install server. This server must have a running RSCD agent that is licensed for
both NSH and the BMC BladeLogic 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 903.)
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.

Provisioning Solaris servers using a WAN boot installation
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 as described in Creating a system package on

page 925.
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.)

Provisioning target servers with ESXi 4.0
8 On the Network Config tab, provide information for Local Settings as you
normally would for a Solaris installation. For the WAN Boot Network IP, enter the
network IP address of the target server. (This field is required for a WAN boot
installation.)
9 Provide information on the other tabs of the system package as you would for a
Solaris Flash installation.
On the Finish Script/Agent Install tab, the Install RSCD agent option is not
available. (The RSCD agent is part of the Flash archive.) If you specify a post-
installation Batch Job or if you select the Push ACL option, the provisioning
process executes these actions only if the RSCD agent is installed and running on
the Flash archive.
10 Create a provisioning job, as described in Creating a Provision Job on page 1024.
Provisioning target servers with ESXi 4.0

Use this procedure to perform a stateless (scriptless) installation of ESXi 4.0 on a
target server.
Note the following about the ESXi 4.0 boot image:
The ESXi 4.0 boot image provided in the BMC BladeLogic installation can be used
to provision only 64-bit devices. In addition, this image cannot be configured 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 919.
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 on the TFTP server at this location:
tftproot/X86PC/prelinux.
For information on extracting the image, see the VMware web site information on
PXE booting VMware ESXi.
2 Edit the values for the ESXi 4.0 image file (vmkboot.gz) provided in the BMC
BladeLogic installation:

Properties and provisioning
A In the BMC BladeLogic 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 importing a device on page 1007.
4 Reboot the target device in order to have it boot into 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 commandline.
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 tryretries=30.
The tftp.conf file resides in the following locations:
Windows: installationDirectory/PXE/br/tftp.conf
Unix: installationDirectory/NSH/br/tftp.conf
Properties and provisioning

Provisioning uses three types of system objectdevices, system packages, and data
store instances. Like other system objects in BMC BladeLogic, these system objects
have properties.
For information about device properties, see Device Properties on page 1057.
For information about system package properties, see System package


Device Properties
For information about data store instances, see Data store instance properties on
page 1064.
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

Inserting a parameter in a system package field
System package fields that accept property references
Using properties to reference scripts
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 becomes a part of every device. For information on how to add properties to
the Device class, see Adding or modifying properties on page 125.
System package properties

Like other system objects, system packages inherit properties defined for a built-in
class in the Property Dictionary. However, unlike many other system objects, you
cannot change the properties defined for the system package built-in class in the
Property Dictionary. (In fact, the built-in class for system package is hidden from
display within the Property Dictionary.)
Instead, if you want 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. For information on adding local properties to a system package, see Local
properties Windows on page 948, Local properties Linux on page 959, Local
properties ESX on page 971, Local Properties Solaris on page 986, Local
properties AIX on page 994, and Local properties HP-UX on page 1004.
NOTE
If you want 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:

Streamlining the wizard with parameterized properties: an example
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 1058.
For information on how to insert a parameter into a system package, see Inserting
a parameter in a system package field on page 1059.
For information on how to use a property to refer to a script, see Using properties
to reference scripts on page 1063.
Streamlining the wizard with parameterized properties: an

example
This example shows you 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 knowing the exact syntax required for the field.
In this example, 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, which are described in Basic configuration
Linux on page 951.)
To accomplish this task, you:
Add a local property to the system package.

Insert a parameter that refers to this property in your system package definition.
Run the wizard and view the resulting drop down menu for the field.
These steps are described in detail in the following procedure.
1 Create your Red Hat system package, as described in Creating a system package
on page 925.
2 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

For more on adding a local property, see Local properties Linux on page 959.
3 On the Basic Configuration panel for your Red Hat system package, type the
following into the Kickstart network device field:
??ACTIVE_NIC_PORT??
For information on the Basic Configuration panel, see Basic configuration

Linux on page 951.
4 Provision a device with your Red Hat package, as described in Creating a

Provision Job on page 1024. 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 have already specified when
you defined the system package.

You can insert parameterized references to properties within your system package
definitions. For example, if you are designing a system package, you might want to
insert a parameter that represents a path to a network driver. Later, when this system
package is being used to provision a server, a user can insert a value for the path that
is applicable to the server being provisioned. To insert a parameterized reference to a
property into a system package, do one of the following:
Click Select Property to display a drop-down menu of available properties, then

click the property you want to insert. Note that whenever you see the Select
Property icon next to a field, you can insert a property into that field.
You can also type the name of the property directly into the system package field.
Be sure to delimit the property with two question marks, such as
??NIC_DRIVER_PATH??.

You can use parameterized property references:
In all script areas of a system package.

In the fields shown in the following table.

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 1058.
System Package Type Panel Fields

Windows Basic Config Computer name
OM Server Name
(See Basic configuration Windows server domain
Windows on page 931.) Workgroup
Domain admin user name
Computer Settings User Information/Name
User Information/Organization
(See Computer Settings PnP driver path
Windows on page 933.) Path to $OEM$ directory
License key
Network Settings IP address
Subnet mask
(See Network Windows Default gateway
on page 942.) Primary DNS server
Secondary DNS server
Local Properties Default value for an added property
(See Local properties

Windows on page 948.)
Linux Basic Config Computer name
OM Server Name
(See Basic configuration Kickstart network device/AutoYaST
Linux on page 951.) network device
Boot Kernel Parameters
Network Settings IP Address
Subnet mask
(See Network Linux on Default gateway
page 954.) DNS server
(See Local properties

Linux on page 959.)


Solaris Basic Config Computer name
OM Server Name
(See Basic configuration
Solaris on page 974.)
Computer Settings Timezone
System Locale
(See Computer settings
Network Settings IP Address
Netmask
(See Network Solaris on Default Route
page 976.) NIS/NIS+ Domain Name
NIS/NIS+ Name Server Host Name
NIS/NIS+ Name Server IP Address
DNS Domain Name
Primary DNS Server
Secondary DNS Server
Tertiary DNS Server
LDAP Domain Name
LDAP Profile Name
LDAP Profile Server IP Address
LDAP Proxy DN
(See Local Properties



AIX Basic Config Computer name
OM Server Name
(See Basic configuration Nim Machine Name
AIX on page 987.)
Localization Settings Bosinst Locale
Cultural Conventions
(See Localization settings Message Catalogs
AIX on page 989.) Keyboard
Network Settings Network object name
Network Type
(See Network Config AIX Subnet Mask
on page 991.) Network Name
Client Gateway
Master Gateway
Network Adapter Name
DNS IP Address
Domain Name
(See Local properties AIX

on page 994.)
Nim Scripts Script Name
(See NIM scripts on

page 994.)
Bosinst Attributes Bosinst attribute name
Value
(See Optional Bosinst
Attributes on page 996.)


HP-UX Basic Config Computer name
OM Server Name
(See Basic configuration
HP-UX on page 998.)
Disk Partition Use Custom Disk Partition
(See Disk partition HP-UX

on page 999.)
Computer Settings TimeZone
Keyboard
(See Computer settings HP-
UX on page 999.)
Network Settings IP address
Subnet mask
(See Network settings HP- Default gateway
UX on page 1000.) Primary DNS server
Secondary DNS server
Hardware Address
(See Local properties AIX

on page 994.)
NOTE
You can use property references in any field that displays the Select Property icon .

When you create a system package, there are many places where you may want to
insert a script. A good way to do this is to create a local property that contains the
script, then insert a parameter that refers to this property in the system package, as
described below.
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.

Data store instance properties
(For complete information on creating properties, see Adding or modifying

properties on page 125.)
2 Insert a parameter that refers to the newly created script property in the relevant
system package field, enclosing 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
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 1064.
Data Store Instances and provisioning strategies

You can create numerous data store instances that point to a variety of physical
machines on your network. In addition, you can create data store instances that point
to different directories on the same machine, and data store instances that refer to the
same configuration setting in different ways (for example, host name vs. IP address).
Having set up these various data store instances, when you run the provisioning
wizard, you can then choose the appropriate data store instance for the machine you
are provisioning.
Here are a few practical examples to get you started thinking of different ways you
can use these flexible features in your provisioning strategy.
Efficient provisioning over the network

Data stores for different operating systems

Efficient provisioning over the network

Suppose you have a network topology that looks like this:
You could start by creating two data store instances:
VLAN1 Data Storepoints to data store 1 on VLAN 1

VLAN2 Data Storepoints to data store 2 on VLAN 2
(For information on how to create a data store instance, see Configuring the data
store on page 903.)
When it comes time to provision target 1, you would run the provisioning wizard and
choose the VLAN1 Data Store instance as your data store. This way, the operating
system files do not have to get copied very far across the network and provisioning is
more efficient. Similarly, when you provision target 2, you would run the
provisioning wizard and choose VLAN2 Data Store.

Data stores for different operating systems

Continuing with the network topology from the previous section, now suppose that
you want to provision one Linux machine on VLAN 1 and a second Windows
machine, also on VLAN 1.
In this case, you could create two data store instances:
Linux Data Store VLAN1

Windows Data Store VLAN1
If you want, both of these data stores can reside on the same physical machinein
this example on machine 1.
The Linux Data Store VLAN1 instance would point to the directory on machine 1
that contains the Linux install files. Because Linux targets need the data store
property LOCATION to be set to the data stores IP address, you would set
LOCATION to machine 1s IP address.
The Windows Data Store VLAN1 instance would point to the directory on
machine 1 that contains the Windows install files. Because Windows targets need
the data store property LOCATION to be set to the data stores host name, you
would set LOCATION to machine 1s host name.

Appendix
A
A System authorizations
The following table provides a complete list of all BMC BladeLogic system
authorizations:
Name Description
ACLPolicy.* ACL policy management
ACLPolicy.Create Create new ACL policy
ACLPolicy.CreateACL Create ACL for ACL policy
ACLPolicy.Delete Delete ACL policy
ACLPolicy.Modify Update ACL policy information
ACLPolicy.ModifyACL Modify ACL for ACL policy
ACLPolicy.Read Read ACL policy information
ACLPushJob.* ACL Push Job management
ACLPushJob.Break Cancel ACL Push Job
ACLPushJob.Cancel Create new ACL Push Job
ACLPushJob.Create Create ACL for ACL Push Job
ACLPushJob.CreateACL Delete ACL Push Job
ACLPushJob.Delete Execute ACL Push Job
ACLPushJob.Execute Modify ACL Push Job
ACLPushJob.Modify Modify ACL for ACL Push Job
ACLPushJob.ModifyACL Modify ACL Push Job properties
ACLPushJob.ModifyProperties Modify ACL Push Job schedule
ACLPushJob.ModifySchedule Modify ACL Push Job targets
ACLPushJob.ModifyTargets Read ACL Push Job
ACLPushJob.Read Read ACL Push Job
ACLTemplate.* ACL template management
ACLTemplate.Create Create new ACL template
ACLTemplate.CreateACL Create ACL for ACL template
ACLTemplate.Delete Delete ACL template
ACLTemplate.Modify Update ACL template information

Name Description
ACLTemplate.ModifyACL Modify ACL for ACL template
ACLTemplate.Read Read ACL template information
AIXSoftware.* Software authorizations
AIXSoftware.Create Create new depot software
AIXSoftware.CreateACL Create ACL for depot software
AIXSoftware.Delete Delete depot software
AIXSoftware.Modify Modify depot software
AIXSoftware.ModifyACL Modify ACL for depot software
AIXSoftware.ModifyProperties Modify depot software properties
AIXSoftware.Read Open depot software
ApplicationServer.* Application Server management
ApplicationServer.Create Create new Application Server
ApplicationServer.CreateACL Create ACL for Application Server
ApplicationServer.Delete Delete Application Server
ApplicationServer.Modify Modify Application Server information
ApplicationServer.ModifyACL Modify ACL for Application Server
ApplicationServer.ModifyProperties Modify Application Server properties
ApplicationServer.Read Read Application Server information
ApprovalConfig.* Remedy approval configuration management
ApprovalType.* Remedy approval type
ApprovalType.Automatic Remedy automatic approval
ApprovalType.Emergency Remedy emergency approval
ApprovalType.Manual Remedy manual approval
ApprovalType.NoApproval No approval required
ApprovalType.PreApproved Pre-approved
Atrium2BlSyncConfig.Modify Atrium Import Job configuration
Atrium2BlSyncJob.* Atrium Import Job management
Atrium2BlSyncJob.Break Break Atrium Import Jobs dependencies
Atrium2BlSyncJob.Cancel Cancel Atrium Import Job
Atrium2BlSyncJob.Create Create new Atrium Import Job
Atrium2BlSyncJob.CreateACL Create ACL for Atrium Import Job
Atrium2BlSyncJob.Delete Delete Atrium Import Job
Atrium2BlSyncJob.Execute Execute Atrium Import Job
Atrium2BlSyncJob.Modify Modify Atrium Import Job
Atrium2BlSyncJob.ModifyACL Modify ACL for Atrium Import Job
Atrium2BlSyncJob.ModifyProperties Modify Atrium Import Job properties
Atrium2BlSyncJob.ModifySchedule Modify Atrium Import Job schedule
Atrium2BlSyncJob.ModifyTargets Modify Atrium Import Job targets
Atrium2BlSyncJob.Read Read Atrium Import Job

Name Description
AuditJob.* Audit Job management
AuditJob.Break Break Audit Jobs dependencies
AuditJob.Cancel Cancel Audit Job
AuditJob.Create Create Audit Job
AuditJob.CreateACL Create ACL for Audit Job
AuditJob.Delete Delete Audit Job
AuditJob.Execute Execute Audit Job
AuditJob.Modify Modify Audit Job
AuditJob.ModifyACL Modify ACL for Audit Job
AuditJob.ModifyProperties Modify Audit Job properties
AuditJob.ModifySchedule Modify Audit Job schedule
AuditJob.ModifyTargets Modify Audit Job targets
AuditJob.Read Read Audit Job
Authorization.* Authorization management
Authorization.Create Create new authorization
Authorization.Delete Delete authorization
Authorization.Modify Modify authorization
AuthProfile.* Authorization profile management
AuthProfile.Create Create new authorization profile
AuthProfile.CreateACL Create ACL for authorization profile
AuthProfile.Delete Delete authorization profile
AuthProfile.Modify Modify authorization profile information
AuthProfile.ModifyACL Modify ACL for authorization profile
AuthProfile.Read Read authorization profile information
AutomationPrincipal.* Automation principal management
AutomationPrincipal.Create Create new automation principals
AutomationPrincipal.CreateACL Create ACL for automation principals
AutomationPrincipal.Delete Delete automation principals
AutomationPrincipal.Modify Modify automation principal information
AutomationPrincipal.ModifyACL Modify ACL for automation principals
AutomationPrincipal.ModifyProperties Modify automation principal properties
AutomationPrincipal.Read Read automation principal information
BatchJob.* Batch Job management
BatchJob.Break Break Batch Jobs dependencies
BatchJob.Cancel Cancel Batch Job
BatchJob.Create Create new Batch Job
BatchJob.CreateACL Create ACL for Batch Job
BatchJob.Delete Delete Batch Job
BatchJob.Execute Execute Batch Job

Name Description
BatchJob.Modify Modify Batch Job
BatchJob.ModifyACL Modify ACL for Batch Job
BatchJob.ModifyProperties Modify Batch Job
BatchJob.ModifySchedule Modify Batch Job schedule
BatchJob.ModifyTargets Modify Batch Job targets
BatchJob.Read Read Batch Job
BL_Administration.* BMC BladeLogic administrative tasks
BL_Administration.Read Read general system status
BL_Administration.System_Cleanup Execute system level cleanup operations
BL_Administration.Write Write/modify general system properties
BLPackage.* BLPackage authorizations
BLPackage.Create Create new BLPackage
BLPackage.CreateACL Create ACL for BLPackage
BLPackage.Delete Delete BLPackage
BLPackage.Modify Modify BLPackage
BLPackage.ModifyACL Modify ACL for BLPackage
BLPackage.ModifyProperties Modify BLPackage properties
BLPackage.Read Open BLPackage
Component.* Component authorizations
Component.Audit Allow audits on this component
Component.Browse Browse component assets
Component.Create Create new component
Component.CreateACL Create ACL for component
Component.Delete Delete component
Component.FileCreate Create files on component
Component.FileDelete Delete files on component
Component.FileModify Modify files on component
Component.Modify Modify component information
Component.ModifyACL Modify ACL for component
Component.ModifyExceptions Modify component exceptions
Component.ModifyProperties Modify component properties
Component.Read Read server properties and other metadata
Component.Snapshot Allow snapshots on this component
Component.StartService Start component services
Component.StopService Stop component services
ComponentGroup.* Component group authorizations
ComponentGroup.Create Create new component group
ComponentGroup.CreateACL Create ACL for component group
ComponentGroup.Delete Delete component group

Name Description
ComponentGroup.Modify Modify component group information
ComponentGroup.ModifyACL Modify ACL for component group
ComponentGroup.Read Read contents of a component group
ComponentGroup.Write Add objects to component group
ComponentTemplate.* Component template authorizations
ComponentTemplate.Break Break component templates dependencies
ComponentTemplate.Create Create new component template
ComponentTemplate.CreateACL Create ACL for component template
ComponentTemplate.Delete Delete component template
ComponentTemplate.Modify Modify component template information
ComponentTemplate.ModifyACL Modify ACL for component template
ComponentTemplate.ModifyProperties Modify component template properties
ComponentTemplate.Read Read component template
ComponentTemplateFolder.* Component template authorizations
ComponentTemplateFolder.Create Create new component template folder
ComponentTemplateFolder.CreateACL Create ACL for component template folder
ComponentTemplateFolder.Delete Delete component template folder
ComponentTemplateFolder.Modify Modify component template folder information
ComponentTemplateFolder.ModifyACL Modify ACL for component template folder
ComponentTemplateFolder.Read Read contents of a component template folder
ComponentTemplateFolder.Write Add to a component template folder
ComponentTemplateGroup.* Component template group authorizations
ComponentTemplateGroup.Create Create new component template group
ComponentTemplateGroup.CreateACL Create ACL for component template group
ComponentTemplateGroup.Delete Delete component template group
ComponentTemplateGroup.Modify Modify component template group information
ComponentTemplateGroup.ModifyACL Modify ACL for component template group
ComponentTemplateGroup.Read Read contents of a component template group
ComponentTemplateGroup.Write Add to a component template group
ConfigFile.* Configuration file management
ConfigFile.Create Create configuration file
ConfigFile.CreateACL Create ACL for configuration file
ConfigFile.Delete Delete configuration file
ConfigFile.Modify Modify configuration file
ConfigFile.ModifyACL Modify ACL for configuration file
ConfigFile.Read Read/open configuration file
ConfigurationObjectClass.* Custom configuration object management
ConfigurationObjectClass.Create Create new custom configuration object
ConfigurationObjectClass.CreateACL Create ACL for new custom configuration object

Name Description
ConfigurationObjectClass.Delete Delete custom configuration object
ConfigurationObjectClass.Modify Modify custom configuration object
ConfigurationObjectClass.ModifyACL Modify ACL for custom configuration object
ConfigurationObjectClass.Read Read custom configuration object
CustomCommand.* Custom command management
CustomCommand.Create Create new custom command
CustomCommand.CreateACL Create ACL for custom command
CustomCommand.Delete Delete custom command
CustomCommand.Execute Execute custom command
CustomCommand.Modify Modify custom command
CustomCommand.ModifyACL Modify ACL for custom command
CustomCommand.Read Open custom command
CustomIcon.* Configuration file management
CustomIcon.Create Create configuration file
CustomIcon.Delete Delete configuration file
CustomIcon.Modify Modify configuration file
CustomSoftware.* Software authorizations
CustomSoftware.Create Create new depot software
CustomSoftware.CreateACL Create ACL for depot software
CustomSoftware.Delete Delete depot software
CustomSoftware.Modify Modify depot software
CustomSoftware.ModifyACL Modify ACL for depot software
CustomSoftware.ModifyProperties Modify software properties
CustomSoftware.Read Open depot software
DeployJob.* Deploy Job management
DeployJob.Break Break Deploy Jobs dependencies
DeployJob.Cancel Cancel Deploy Job
DeployJob.Create Create new Deploy Job
DeployJob.CreateACL Create ACL for Deploy Job
DeployJob.Delete Delete Deploy Job
DeployJob.Execute Execute Deploy Job
DeployJob.Modify Modify Deploy Job
DeployJob.ModifyACL Modify ACL for Deploy Job
DeployJob.ModifyProperties Modify Deploy Job properties
DeployJob.ModifySchedule Modify Deploy Job schedule
DeployJob.ModifyTargets Modify Deploy Job targets
DeployJob.Read Read Deploy Job
DeployJob.Undo Undo Deploy Job
DepotFile.* Depot file authorizations

Name Description
DepotFile.Create Create new depot file
DepotFile.CreateACL Create ACL for depot file
DepotFile.Delete Delete depot file
DepotFile.Modify Modify depot file
DepotFile.ModifyACL Modify ACL for depot file
DepotFile.ModifyProperties Modify depot file properties
DepotFile.Read Open depot file
DepotFolder.* Depot folder management
DepotFolder.Create Create new depot folder
DepotFolder.CreateACL Create ACL for depot folder
DepotFolder.Delete Delete depot folder
DepotFolder.Modify Modify depot folder
DepotFolder.ModifyACL Modify ACL for depot folder
DepotFolder.Read Open depot folder
DepotFolder.Write Add new objects into depot folder
DepotGroup.* Depot group management
DepotGroup.Create Create new depot group
DepotGroup.CreateACL Create ACL for depot group
DepotGroup.Delete Delete depot group
DepotGroup.Modify Modify depot group
DepotGroup.ModifyACL Modify ACL for depot group
DepotGroup.Read Open depot group
DepotGroup.Write Add new objects into depot group
DeregisterConfigurationObjects.* Deregister Configuration Objects Job management
DeregisterConfigurationObjects.Cancel Cancel Deregister Configuration Objects Job
DeregisterConfigurationObjects.Create Create Deregister Configuration Objects Job
DeregisterConfigurationObjects.CreateACL Create ACL for Deregister Configuration Objects Job
DeregisterConfigurationObjects.Delete Delete Deregister Configuration Objects Job
DeregisterConfigurationObjects.Execute Execute Deregister Configuration Objects Job
DeregisterConfigurationObjects.Modify Modify Deregister Configuration Objects Job
DeregisterConfigurationObjects.ModifyACL Modify ACL for Deregister Configuration Objects Job
DeregisterConfigurationObjects.ModifyProperties Modify Deregister Configuration Objects Job properties
DeregisterConfigurationObjects.ModifySchedule Modify Deregister Configuration Objects Job schedule
DeregisterConfigurationObjects.ModifyTargets Modify Deregister Configuration Objects Job targets
DeregisterConfigurationObjects.Read Read Deregister Configuration Objects Job
Device.* Devices
Device.Create Create device
Device.CreateACL Create ACL for device
Device.Delete Delete device from provisioning manager

Name Description
Device.Modify Modify a device
Device.ModifyACL Modify ACL for device
Device.ModifyProperties Modify the properties of a device
Device.Provision Provision devices
Device.Read Read devices
Device.ReProvision Re-provision devices
Device.SetAsProvisioned Set devices as provisioned
DeviceFolder.* Device folder management
DeviceFolder.Create Create new Device folder
DeviceFolder.CreateACL Create ACL for Device folder
DeviceFolder.Delete Delete device folder
DeviceFolder.Modify Modify device folder
DeviceFolder.ModifyACL Modify ACL for device folder
DeviceFolder.Read Open device folder
DeviceFolder.Write Add new objects into device folder
DeviceGroup.* Device group management
DeviceGroup.Create Create new device group
DeviceGroup.CreateACL Create ACL for device group
DeviceGroup.Delete Delete device group
DeviceGroup.Modify Modify device group
DeviceGroup.ModifyACL Modify ACL for device group
DeviceGroup.Read Open device group
DeviceGroup.Write Add new objects into device group
DiscoveryJob.* Discovery Job management
DiscoveryJob.Break Break Discovery Jobs dependencies
DiscoveryJob.Cancel Cancel Discovery Job
DiscoveryJob.Create Create new Discovery Job
DiscoveryJob.CreateACL Create ACL for Discovery Job
DiscoveryJob.Delete Delete Discovery Job
DiscoveryJob.Execute Execute Discovery Job
DiscoveryJob.Modify Modify Discovery Job
DiscoveryJob.ModifyACL Modify ACL for Discovery Job
DiscoveryJob.ModifyProperties Modify Discovery Job properties
DiscoveryJob.ModifySchedule Modify Discovery Job schedule
DiscoveryJob.ModifyTargets Modify Discovery Job targets
DiscoveryJob.Read Read Discovery Job
DistributeConfigurationObjects.* Distribute Configuration Objects Job management
DistributeConfigurationObjects.Cancel Cancel job
DistributeConfigurationObjects.Create Create Distribute Configuration Objects Job

Name Description
DistributeConfigurationObjects.CreateACL Create ACL for Distribute Configuration Objects Job
DistributeConfigurationObjects.Delete Delete Distribute Configuration Objects Job
DistributeConfigurationObjects.Execute Execute Distribute Configuration Objects Job
DistributeConfigurationObjects.Modify Modify Distribute Configuration Objects Job
DistributeConfigurationObjects.ModifyACL Modify ACL for Distribute Configuration Objects Job
DistributeConfigurationObjects.ModifyProperties Modify Distribute Configuration Objects Job properties
DistributeConfigurationObjects.ModifySchedule Modify Distribute Configuration Objects Job schedule
DistributeConfigurationObjects.ModifyTargets Modify Distribute Configuration Objects Job targets
DistributeConfigurationObjects.Read Read Distribute Configuration Objects Job
ExecutionTask.* Execution task management
ExecutionTask.Create Create new execution task
ExecutionTask.CreateACL Create ACL for execution task
ExecutionTask.Delete Delete execution task
ExecutionTask.Execute Execute execution task
ExecutionTask.Modify Modify execution task
ExecutionTask.ModifyACL Modify ACL for execution task
ExecutionTask.ModifyProperties Modify execution task properties
ExecutionTask.ModifySchedule Modify execution task schedule
ExecutionTask.ModifyTargets Modify execution task targets
ExecutionTask.Read Read execution task
ExtendedObject.* Extended object management
ExtendedObject.Create Create extended object definition
ExtendedObject.CreateACL Create ACL for extended object definition
ExtendedObject.Delete Delete extended object definition
ExtendedObject.Modify Modify extended object definition
ExtendedObject.ModifyACL Modify ACL for extended object definition
ExtendedObject.Read Read extended object definition
FileServer.* File server management
FileServer.Create Create new file server
FileServer.Delete Delete file server
FileServer.Modify Modify file server information
FileServer.Read Read file server information
HPUXSoftware.* Software authorizations
HPUXSoftware.Create Create new depot software
HPUXSoftware.CreateACL Create ACL for depot software
HPUXSoftware.Delete Delete depot software
HPUXSoftware.Modify Modify depot software
HPUXSoftware.ModifyACL Modify ACL for depot software
HPUXSoftware.ModifyProperties Modify depot software properties

Name Description
HPUXSoftware.Read Open depot software
JobFolder.* Job folder management
JobFolder.Create Create new job folder
JobFolder.CreateACL Create ACL for job folder
JobFolder.Delete Delete job folder
JobFolder.Modify Modify job folder
JobFolder.ModifyACL Modify ACL for job folder
JobFolder.Read Open job folder
JobFolder.Write Add objects to job folder
JobGroup.* Job group management
JobGroup.Create Create new job group
JobGroup.CreateACL Create ACL for job group
JobGroup.Delete Delete job group
JobGroup.Modify Modify job group
JobGroup.ModifyACL Modify ACL for job group
JobGroup.Read Open job group
JobGroup.Write Add objects to job group
LdapConnection.* LDAP connection management
LdapConnection.Create Create new LDAP connection
LdapConnection.CreateACL Create ACL for LDAP connection
LdapConnection.Delete Delete LDAP connection
LdapConnection.Modify Modify LDAP connection information
LdapConnection.ModifyACL Modify ACL for LDAP connection
LdapConnection.ModifyProperties Modify LDAP connection properties
LdapConnection.Read Read LDAP connection information
LinuxSoftware.* Software authorizations
LinuxSoftware.Create Create new depot software
LinuxSoftware.CreateACL Create ACL for depot software
LinuxSoftware.Delete Delete depot software
LinuxSoftware.Modify Modify depot software
LinuxSoftware.ModifyACL Modify ACL for depot software
LinuxSoftware.ModifyProperties Modify depot software properties
LinuxSoftware.Read Open depot software
MacPool.* MAC pool management
MacPool.Create Create MAC pool
MacPool.CreateACL Create ACL for Create MAC pool
MacPool.Delete Delete Create MAC pool
MacPool.Modify Modify Create MAC pool
MacPool.ModifyACL Modify ACL for Create MAC pool

Name Description
MacPool.ModifyProperties Modify Create MAC pool properties
MacPool.Read Read Create MAC pool
NSHScript.* NSH script management
NSHScript.Create Create NSH script
NSHScript.CreateACL Create ACL for NSH script
NSHScript.Delete Delete NSH script
NSHScript.Modify Modify NSH script
NSHScript.ModifyACL Modify ACL for NSH script
NSHScript.ModifyProperties Modify NSH script properties
NSHScript.Read Read NSH script
NSHScriptJob.* NSH Script Job management
NSHScriptJob.Break Break NSH Script Jobs dependencies
NSHScriptJob.Cancel Cancel NSH Script Job
NSHScriptJob.Create Create NSH Script Job
NSHScriptJob.CreateACL Create ACL for NSH Script Job
NSHScriptJob.Delete Delete NSH Script Job
NSHScriptJob.Execute Execute NSH Script Job
NSHScriptJob.Modify Modify NSH Script Job
NSHScriptJob.ModifyACL Modify ACL for NSH Script Job
NSHScriptJob.ModifyParameters Modify parameters for NSH Script Job
NSHScriptJob.ModifyProperties Modify NSH Script Job properties
NSHScriptJob.ModifySchedule Modify NSH Script Job schedule
NSHScriptJob.ModifyTargets Modify NSH Script Job targets
NSHScriptJob.Read Read NSH Script Job
PatchAnalysisConfig.Modify Patch analysis configuration management
PatchCatalog.Cancel Cancel job
PatchCatalog.Create Create new patch catalog
PatchCatalog.CreateACL Create ACL for patch catalog
PatchCatalog.Delete Delete patch catalog
PatchCatalog.Modify Modify patch catalog
PatchCatalog.ModifyACL Modify ACL for patch catalog
PatchCatalog.ModifyProperties Modify patch catalog update job properties
PatchCatalog.ModifySchedule Schedule patch catalog update job
PatchCatalog.Read Open patch catalog
PatchCatalog.Update Add new objects into patch catalog
PatchCatalog.Write Add new objects into patch catalog
PatchDownloadJob.* Patch download job management
PatchDownloadJob.Break Break patch download jobs dependencies

Name Description
PatchDownloadJob.Cancel Cancel job
PatchDownloadJob.Create Create patch download job
PatchDownloadJob.CreateACL Create ACL for patch download job
PatchDownloadJob.Delete Delete patch download job
PatchDownloadJob.Execute Execute patch download job
PatchDownloadJob.Modify Modify patch download job
PatchDownloadJob.ModifyACL Modify ACL for patch download job
PatchDownloadJob.ModifyProperties Modify patch download job properties
PatchDownloadJob.ModifySchedule Modify patch download job schedule
PatchDownloadJob.ModifyTargets Modify patch download job targets
PatchDownloadJob.Read Read patch download job
PatchingJob.* Patching job management
PatchingJob.Break Break patching job
PatchingJob.Cancel Cancel job
PatchingJob.Create Create patching job
PatchingJob.CreateACL Create ACL for patching job
PatchingJob.Delete Delete patching job
PatchingJob.Execute Execute patching job
PatchingJob.Modify Modify patching job
PatchingJob.ModifyACL Modify ACL for patching job
PatchingJob.ModifyProperties Modify patching job properties
PatchingJob.ModifySchedule Modify patching job schedule
PatchingJob.ModifyTargets Modify patching job targets
PatchingJob.Read Read patching job
PatchRemediationJob.* Patch remediation job management
PatchRemediationJob.Break Break patch remediation jobs dependencies
PatchRemediationJob.Cancel Cancel job
PatchRemediationJob.Create Create patch remediation job
PatchRemediationJob.CreateACL Create ACL for patch remediation job
PatchRemediationJob.Delete Delete patch remediation job
PatchRemediationJob.Execute Execute patch remediation job
PatchRemediationJob.Modify Modify patch remediation job
PatchRemediationJob.ModifyACL Modify ACL for patch remediation job
PatchRemediationJob.ModifyProperties Modify patch remediation job properties
PatchRemediationJob.ModifySchedule Modify patch remediation job schedule
PatchRemediationJob.ModifyTargets Modify patch remediation job targets
PatchRemediationJob.Read Read patch remediation job
PatchSmartGroup.Create Create patch smart group

Name Description
PatchSmartGroup.CreateACL Create ACL for patch smart group
PatchSmartGroup.Delete Delete patch smart group
PatchSmartGroup.Modify Modify patch smart group
PatchSmartGroup.ModifyACL Modify ACL for patch smart group
PatchSmartGroup.Read Open patch smart group
PatchSmartGroup.Write Add new objects into patch smart group
PropertyClass.* Property class management
PropertyClass.CreateACL Create ACL for property class
PropertyClass.CreateCustom Create new custom property class
PropertyClass.CreateInstance Create instance of property class
PropertyClass.CreateSubClass Create property sub-class
PropertyClass.Delete Delete property class
PropertyClass.ExportDictionary Export Property Dictionary
PropertyClass.ImportDictionary Import Property Dictionary
PropertyClass.Modify Modify property class
PropertyClass.ModifyACL Modify ACL for property class
PropertyInstance.* Property instance management
PropertyInstance.CreateACL Create ACL for property instance
PropertyInstance.Delete Delete property instance
PropertyInstance.Modify Modify property instance
PropertyInstance.ModifyACL Modify ACL for property instance
PropertyInstance.Read Read property instance
ProvisionConfig.* Provisioning Manager configurations
ProvisionConfig.Modify Modify Provisioning Manager configurations
ProvisionConfig.Read Access Provisioning Manager configurations
ProvisionJob.* Provisioning Job management
ProvisionJob.Break Break Provisioning Jobs dependencies
ProvisionJob.Cancel Cancel Provisioning Job
ProvisionJob.Create Create new Provisioning job
ProvisionJob.CreateACL Create ACL for Provisioning Job
ProvisionJob.Delete Delete Provisioning Job
ProvisionJob.Execute Execute Provisioning Job
ProvisionJob.Modify Modify Provisioning Job
ProvisionJob.ModifyACL Modify ACL for Provisioning Job
ProvisionJob.ModifyProperties Modify Provisioning Job properties
ProvisionJob.ModifySchedule Modify Provisioning Job schedule
ProvisionJob.ModifyTargets Modify Provisioning Job targets
ProvisionJob.Read Read Provisioning Job
Repeater.* Repeater management

Name Description
Repeater.Create Create new repeater server
Repeater.Delete Delete repeater server
Repeater.Modify Modify repeater information
Repeater.Read Read repeater information
Reports.Administration Reports management
Reports.QueryStudio Access to Query Studio
Reports.Studio Access to Reports Studio
Reports.Viewer Access to Cognos Connection
Role.* Role management
Role.Create Create new role
Role.CreateACL Create ACL for role
Role.Delete Delete role
Role.ManageUsers Manage users for role
Role.Modify Modify role information
Role.ModifyACL Modify ACL for role
Role.ModifyProperties Modify role properties
Role.Read Read role information
RoutingPolicy.* Routing policy management
RoutingPolicy.Create Create new routing policy
RoutingPolicy.CreateACL Create ACL for routing policy
RoutingPolicy.Delete Delete routing policy
RoutingPolicy.Modify Modify routing policy information
RoutingPolicy.ModifyACL Modify ACL for routing policy
RoutingPolicy.ModifyProperties Modify routing policy properties
RoutingPolicy.Read Read routing policy information
Server.* Server authorizations
Server.Audit Allow audits on this server
Server.Browse Browse server assets
Server.Create Add new server into system
Server.CreateACL Create ACL for server
Server.Decommission Decommission server
Server.Deploy Allow deploys on this server
Server.Discover Discover this server
Server.ExecuteNSHScript Execute NSH scripts on server
Server.FileCreate Create files on server
Server.FileDelete Delete files on server
Server.FileModify Modify files on server
Server.Modify Modify server metadata
Server.ModifyACL Modify ACL for server

Name Description
Server.ModifyProperties Modify server properties
Server.PushACL Push ACLs to agent
Server.Read Read server properties and other metadata
Server.Snapshot Allow snapshots on this server
Server.StartService Start server services
Server.StopService Stop server services
ServerGroup.* Server group management
ServerGroup.Create Create new server group
ServerGroup.CreateACL Create ACL for server group
ServerGroup.Delete Delete server group
ServerGroup.Modify Modify server group
ServerGroup.ModifyACL Modify ACL for server group
ServerGroup.Read Open server group
ServerGroup.Write Add objects to server group
SnapshotJob.* Snapshot Job management
SnapshotJob.Break Break Snapshot Jobs dependencies
SnapshotJob.Cancel Cancel Snapshot Job
SnapshotJob.Create Create new Snapshot Job
SnapshotJob.CreateACL Create ACL for Snapshot Job
SnapshotJob.Delete Delete Snapshot Job
SnapshotJob.Execute Execute Snapshot Job
SnapshotJob.Modify Modify Snapshot Job
SnapshotJob.ModifyACL Modify ACL for Snapshot Job
SnapshotJob.ModifyProperties Modify Snapshot Job properties
SnapshotJob.ModifySchedule Modify Snapshot Job schedule
SnapshotJob.ModifyTargets Modify Snapshot Job targets
SnapshotJob.Read Read Snapshot Job
SolarisSoftware.* Software authorizations
SolarisSoftware.Create Create new depot software
SolarisSoftware.CreateACL Create ACL for depot software
SolarisSoftware.Delete Delete depot software
SolarisSoftware.Modify Modify depot software
SolarisSoftware.ModifyACL Modify ACL for depot software
SolarisSoftware.ModifyProperties Modify depot software properties
SolarisSoftware.Read Open depot software
SystemPackage.* System package management
SystemPackage.Create Create new system package
SystemPackage.CreateACL Create ACL for system package
SystemPackage.Delete Delete system package

Name Description
SystemPackage.Modify Modify system package
SystemPackage.ModifyACL Set system package ACL
SystemPackage.ModifyProperties Modify system package properties
SystemPackage.Read Open system package
SystemPackageFolder.* System package folder management
SystemPackageFolder.Create Create new system package folder
SystemPackageFolder.CreateACL Create ACL for system package folder
SystemPackageFolder.Delete Delete system package folder
SystemPackageFolder.Modify Modify system package folder
SystemPackageFolder.ModifyACL Set system package folder ACL
SystemPackageFolder.Read Open system package folder
SystemPackageFolder.Write Add to a system package folder
SystemPackageType.* System package type management
SystemPackageType.Create Create new system package type
SystemPackageType.Delete Delete system package type
SystemPackageType.Modify Modify system package type
SystemPackageType.Read Open system package type
UCSProvisionJob.* UCS Provision Job management
UCSProvisionJob.Cancel Cancel job
UCSProvisionJob.Create Create new UCS Provision Job
UCSProvisionJob.CreateACL Create ACL for UCS Provision Job
UCSProvisionJob.Delete Delete UCS Provision Job
UCSProvisionJob.Execute Execute UCS Provision Job
UCSProvisionJob.Modify Modify UCS Provision Job
UCSProvisionJob.ModifyACL Modify ACL for UCS Provision Job
UCSProvisionJob.ModifyProperties Modify UCS Provision Job properties
UCSProvisionJob.ModifySchedule Modify UCS Provision Job schedule
UCSProvisionJob.ModifyTargets Modify UCS Provision Job targets
UCSProvisionJob.Read Read UCS Provision Job
UCSTemplate.* UCS template management
UCSTemplate.Create Create new UCS template
UCSTemplate.CreateACL Create ACL for UCS template
UCSTemplate.Delete Delete UCS template
UCSTemplate.Modify Modify UCS template
UCSTemplate.ModifyACL Modify ACL for UCS template
UCSTemplate.ModifyProperties Modify UCS template properties
UCSTemplate.Read Open UCS template
UpdatePropertiesJob.* Update Server Properties Job management
UpdatePropertiesJob.Break Break Update Server Properties Jobs dependencies

Name Description
UpdatePropertiesJob.Cancel Cancel Update Server Properties Job
UpdatePropertiesJob.Create Create new Update Server Properties Job
UpdatePropertiesJob.CreateACL Create ACL for Update Server Properties Job
UpdatePropertiesJob.Delete Delete Update Server Properties Job
UpdatePropertiesJob.Execute Execute Update Server Properties Job
UpdatePropertiesJob.Modify Modify Update Server Properties Job
UpdatePropertiesJob.ModifyACL Modify ACL for Update Server Properties Job
UpdatePropertiesJob.ModifyProperties Modify Update Server Properties Job properties
UpdatePropertiesJob.ModifySchedule Modify Update Server Properties Job schedule
UpdatePropertiesJob.ModifyTargets Modify Update Server Properties Job targets
UpdatePropertiesJob.Read Read Update Server Properties Job
UpgradeModelObjects.* Upgrade Model Objects Job management
UpgradeModelObjects.Break Break Upgrade Model Objects Jobs dependencies
UpgradeModelObjects.Cancel Cancel job
UpgradeModelObjects.Create Create Upgrade Model Objects Job
UpgradeModelObjects.CreateACL Create ACL for Upgrade Model Objects Job
UpgradeModelObjects.Delete Delete Upgrade Model Objects Job
UpgradeModelObjects.Execute Execute Upgrade Model Objects Job
UpgradeModelObjects.Modify Modify Upgrade Model Objects Job
UpgradeModelObjects.ModifyACL Modify ACL for Upgrade Model Objects Job
UpgradeModelObjects.ModifyProperties Modify Upgrade Model Objects Job properties
UpgradeModelObjects.ModifySchedule Modify Upgrade Model Objects Job schedule
UpgradeModelObjects.ModifyTargets Modify Upgrade Model Objects Job targets
UpgradeModelObjects.Read Read Upgrade Model Objects Job
User.* User management
User.Create Create new user
User.CreateACL Create ACL for user
User.Delete Delete user
User.Modify Modify user information
User.ModifyACL Modify ACL for user
User.ModifyProperties Modify user properties
User.Read Read user information
User.SetPassword Set user password
UuidPool.* Uuid pool management
UuidPool.Create Create new uuid pool
UuidPool.CreateACL Create ACL for uuid pool
UuidPool.Delete Delete uuid pool
UuidPool.Modify Modify uuid pool
UuidPool.ModifyACL Modify ACL for uuid pool

Name Description
UuidPool.ModifyProperties Modify uuid pool properties
UuidPool.Read Open uuid pool
VirtualGuestJob.* Virtual Guest Job management
VirtualGuestJob.Cancel Cancel job
VirtualGuestJob.Create Create Virtual Guest Job
VirtualGuestJob.CreateACL Create ACL for Virtual Guest Job
VirtualGuestJob.Delete Delete Virtual Guest Job
VirtualGuestJob.Execute Execute Virtual Guest Job
VirtualGuestJob.Modify Modify Virtual Guest Job
VirtualGuestJob.ModifyACL Modify ACL for Virtual Guest Job
VirtualGuestJob.ModifyProperties Modify Virtual Guest Job properties
VirtualGuestJob.ModifySchedule Modify Virtual Guest Job schedule
VirtualGuestJob.ModifyTargets Modify Virtual Guest Job targets
VirtualGuestJob.Read Read Virtual Guest Job
VirtualGuestPackage.* Virtual Guest Package management
VirtualGuestPackage.Create Create Virtual Guest Package
VirtualGuestPackage.CreateACL Create ACL for Virtual Guest Package
VirtualGuestPackage.Delete Delete Virtual Guest Package
VirtualGuestPackage.Modify Modify Virtual Guest Package
VirtualGuestPackage.ModifyACL Modify ACL for Virtual Guest Package
VirtualGuestPackage.ModifyProperties Modify Virtual Guest Package properties
VirtualGuestPackage.Read Read Virtual Guest Package
VSMDiscoveryJob.* VSM Discovery Job management
VSMDiscoveryJob.Break Break VSM Discovery Jobs dependencies
VSMDiscoveryJob.Cancel Cancel job
VSMDiscoveryJob.Create Create new VSM Discovery Job
VSMDiscoveryJob.CreateACL Create ACL for VSM Discovery Job
VSMDiscoveryJob.Delete Delete VSM Discovery Job
VSMDiscoveryJob.Execute Execute VSM Discovery Job
VSMDiscoveryJob.Modify Modify VSM Discovery Job
VSMDiscoveryJob.ModifyACL Modify ACL for VSM Discovery Job
VSMDiscoveryJob.ModifyProperties Modify VSM Discovery Job properties
VSMDiscoveryJob.ModifySchedule Modify VSM Discovery Job schedule
VSMDiscoveryJob.ModifyTargets Modify VSM Discovery Job targets
VSMDiscoveryJob.Read Read VSM Discovery job
WindowsSoftware.* Software authorizations
WindowsSoftware.Create Create new depot software
WindowsSoftware.CreateACL Create ACL for depot software
WindowsSoftware.Delete Delete depot software

Name Description
WindowsSoftware.Modify Modify depot software
WindowsSoftware.ModifyACL Modify ACL for depot software
WindowsSoftware.ModifyProperties Modify depot software properties
WindowsSoftware.Read Open depot software
WwnPool.* Wwn pool management
WwnPool.Create Create new wwn pool
WwnPool.CreateACL Create ACL for wwn pool
WwnPool.Delete Delete wwn pool
WwnPool.Modify Modify wwn pool
WwnPool.ModifyACL Modify ACL for wwn pool
WwnPool.ModifyProperties Modify wwn pool properties
WwnPool.Read Read wwn pool

Appendix
B
B Intrinsic properties
The following table provides a complete list of all intrinsic properties that can be
assigned to BMC BladeLogic system objects:
Property Name
ACTION_ON_FAILURE
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_QUEUE_WAIT_TIMEOUT
AGENT_STATUS
AIX_SECURITY
ALLOWED_OPERATIONS*
APAR
APPLICABLE_COMP_ID
APPLICATION_TYPE*
APPROVAL_TYPE_ID
APP_ML
APP_SERVER_IP
ARCHITECTURE
AUDIT
AUDITED_OBJECT
AUDIT_TRAILS*
AUTO_CLOSE
AUTO_GENERATED
BLSEPARATOR

Property Name
BL_ACL*
BL_AUTH
BL_AUTH_ENUM
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
CHANGED_ITEM_TOTAL
CHANGE_ID
CHANGE_TIMING
CHANGE_TYPE
CHARSET*
CLUSTER
COMMAND
COMMAND_ARGUMENT
COMMAND_INTERFACE
COMMAND_ORDER
COMMAND_TYPE
COMMENTS
COMPONENT
COMPONENT_HEADER_NAME
CONFIG_SERVER
CONFIG_SERVER_FULL_PATH
CONFIG_STORE
CONFLICTS
CONNECTION_DOMAIN
CONNECTION_PASSPHRASE
CONNECTION_PASSWORD
CONNECTION_URL

Property Name
CONNECTION_USER
COPY_LOCKED_FILES
CREATED_DATE
CREATION_CHANGE_REQUEST_ID
CREATION_SERVICE_REQUEST_ID
CREATION_TASK_ID
CREATION_TEMPLATE_TYPE
CURRENT_ROLE
CURRENT_ROLE_AUTH_NAMES
CUSTOMER
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*
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_OPTIONS_INSTANCE_FOR_REMEDIATION
DEPLOY_URL_TYPE
DEPOT_FILE_ID*
DESCRIPTION
DEVICE
DISABLED
DISPLAY_NAME

Property Name
DNS_SERVER
DNS_SERVER2
DOMAIN_NAME
DS_ACTION_ON_FAILURE*
ENABLE_SINGLE_JOB_MODE
END_ML
END_TIME
ENHANCEMENT
EQUIVALENT_PATCHES
ERRATA_ADVISORY*
ERRATA_SEVERITY*
ERRATA_TYPE*
EXECUTE_TYPE
EXECUTION_ROLE
EXECUTION_TASKS
EXECUTION_USER
EXPIRY_DATE
EXTRA_ITEM_TOTAL
FAILED_LOGINS*
FILESETS
FILESET_ID
FIXED_COMP_ID
FLOW_CONTROL
FOLLOW_SYMLINKS_ON_URL
FQ_HOST
FULL_PATH
GLOBAL_FLAGS*
GROUP*
GROUPS*
HAD_ERRORS
HAD_WARNINGS*
HIPER
HOME_DIR_PATH
HOST
HOSTIP_BITS
HOSTNAME
HOST_NAME
HOTFIX_TYPE*
IGNITE_SERVER

Property Name
IGNORE_COPY_ON_BOOT_FILES
IMPACT
IMPACT
INCLUDED_IN_MAINT_LEVEL
INCLUDED_IN_SP
INCLUDED_IN_UPDATE
INSTALL_COMMAND*
INSTALL_SERVER
INSTALL_SERVER*
INSTALL_SERVER_CGI_BIN_PATH*
INSTALL_SERVER_CGI_BIN_URL*
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_AUTH_PROFILE
IS_AUTO_ROLLBACK
IS_CANCELLED
IS_COMMIT_ENABLED
IS_COMPLETED
IS_COMPONENT_SPECIFIED*
IS_CONSISTENT
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*

Property Name
IS_PWD_EVER_EXPIRED*
IS_RECOMMENDED*
IS_RECONFIGURE_REBOOT
IS_REPEATER
IS_RESET
IS_RUNNING
IS_RUN_SUCCESSFUL
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_VALID*
IS_VIRTUAL*
ITEM_RECONFIGURE_REBOOT_OPTIONS
JOB
JOBRUN
JOB_NAME
JOB_PART_TIMEOUT
JOB_RESULT
JOB_RESULT
JOB_RUN
JOB_TIMEOUT
LANGUAGE_ID*
LAST_FAILED_LOGIN_DATE*
LAST_PWD_CHANGE_DATE*
LAST_UPDATED_DATE
LATE_BINDING_IP
LIFECYCLE*
LINUX_USERS_FILE_ENTRY
LOCATION*
LOGGING_LEVEL
LOG_DATE
MAC_ADDRESS_CD

Property Name
MAINTENANCE_LEVEL
MAXCACHESIZE
MAX_PACKAGE_SIZE
MAX_PARALLEL_PER_VM_HOST*
MESSAGE
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
NSH_SCRIPT_LOCATION*
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*
PATCH_LANGUAGE
PATCH_TYPE*

Property Name
PAYLOAD_LOCATION
PE
PLATFORM
PM_STATE*
POLICY_BL_ACL
POLICY_MODE*
POLICY_MODE*
PORT
PREREQUISITES
PRESERVE_STAGING_DIR_ON_FAILURE
PRINCIPAL
PRODUCT
PROMPT_RUNTIME_ARGUMENTS
PTF
PUSH_ACL_NO_USERS_FLAG
QNUMBER*
QNUMBER*
QUICK_LAUNCH
Q_NUMBER
RBAC_ACES
REBOOT_OPTIONS
REBOOT_TYPE
RECOMMENDED
RECONCILIATION_ID
REF_NUMBER
REGISTER_COM_COMPONENTS
RELEASE_DATE
RELEASE_DATE*
RELEASE_DATE*
REPEATER_MAX_CACHE_SIZE
REPEATER_NAME
REPEATER_STAGING_DIR
REQUIRED
REQUIRES_REBOOTS
RESET_JOB_ON_FAILURE
RESOLVES_HOSTNAME
RESULTS_RETENTION_TIME
RISK_LEVEL
ROLE

Property Name
ROLES*
ROLE_CREATED
ROLE_MODIFIED
ROLE_NAME
ROLLBACKPATH
ROOT_PASSWORD
RPM_BUILD_DATE*
RPM_LICENSE*
RSCD_DIR
RSCD_VERSION
SECURITY
SECURITY_LEVEL
SERIAL_NUMBER
SERVER_HEADER_NAME
SESSION_TYPE
SEVERITY_RATING
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
START_TIME
STATE
STATUS
STRING_DELIMITER
SUBNET_MASK
SUBSCRIPTIONS
SUCCESS
SUPERSEDED_BY*
SUPERSEDES
SYSTEMROOT
TARGET

Property Name
TASK_ID
TEMPLATE
TEMPLATE_BL_ACL
TEMPLATE_OBJECT_ID*
TRANSACTIONS_DIR
TYPE
TYPE*
UNBUNDLED
UNINSTALL_COMMAND*
UPDATE_LEVEL
URGENCY
URL
USERNAME
USER_CREATED
USER_MODE
USER_MODE_OPTIONS_UNIX_ONLY
USER_MODIFIED
USER_NAME
USER_RECOMMENDATION
USE_ALL_VERSIONS
USE_DELIM
USE_HEADERS
USE_LATEST_CLASSES
UUID
VENDOR
VENDOR_IDENTIFIER
VENDOR_IMPACT*
VENDOR_NAME*
VERSION
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_ID

Property Name
VIRTUAL_ENTITY_MANAGER
VIRTUAL_ENTITY_TYPE
VM_HOST
VM_VIRTUAL_MACHINE
VM_WS_PWD
VM_WS_URL
VM_WS_USERNAME
WINDIR
WINDOW_TYPE
WITHDRAWN

Appendix
C
Security settings for Windows 2008,
C
2003, and 2000

When auditing Security Settings, BMC BladeLogic 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 BladeLogic
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.
The following table provides a list of policy names that differ between Windows 2003
or 2008 and Windows 2000:
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 Audit the access of global system objects
objects
Audit: Audit the use of Backup and Restore Audit the use of Backup and Restore
privilege privilege
Audit: Shut down system immediately if Shut down system immediately if unable to
unable to log security audits log security audits
Devices: Allow undock without having to log Not available
on
Devices: Allowed to format and eject Allowed to eject removable NTFS media
removable media
Devices: Prevent users from installing printer Prevent users from installing printer drivers
drivers
Devices: Restrict CD-ROM access to locally Restrict CD-ROM access to locally logged-on
logged-on user only user only
Devices: Restrict floppy access to locally Restrict floppy access to locally logged-on
logged-on user only user only
Devices: Unsigned driver installation Unsigned driver installation behavior
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 Not available
requirements
Domain controller: Refuse machine account Not available
password changes
Domain member: Digitally encrypt or sign Secure channel: Digitally encrypt or sign
secure channel data (always) secure channel data (always)
Domain member: Digitally encrypt secure Secure channel: Digitally encrypt secure
channel data (when possible) channel data (when possible)
Domain member: Digitally sign secure Secure channel: Digitally sign secure channel
channel data (when possible) data (when possible)
Domain member: Disable machine account Prevent system maintenance of computer
password changes password
Domain member: Maximum machine Not available
account password age
Domain member: Require strong (Windows Secure channel: Require strong (Windows
2000 or later) session key 2000 or later) session key
Interactive logon: Display user information Not available
when the session is locked

Interactive logon: Do not display last user Do not display last user name in logon screen
name
Interactive logon: Do not require Disable CTRL+ALT+DEL requirement for
CTRL+ALT+DEL logon
Interactive logon: Message text for users Message text for users attempting to log on
attempting to log on
Interactive logon: Message title for users Message title for users attempting to log on
attempting to log on
Interactive logon: Number of previous logons Number of previous logons to cache (in case
to cache (in case domain controller is not domain controller is not available)
available)

Interactive logon: Prompt user to change Prompt user to change password before
password before expiration expiration
Interactive logon: Require Domain Controller Not available
authentication to unlock workstation
Interactive logon: Require smart card Not available
Interactive logon: Smart card removal Interactive logon: Smart card removal
behavior behavior
Microsoft network client: Digitally sign Digitally sign client communication (always)
communications (always)
Microsoft network client: Digitally sign Digitally sign client communication (when
communications (if server agrees) possible)
Microsoft network client: Send unencrypted Send unencrypted password to connect to
password to third-party SMB servers third-party SMB servers
Microsoft network server: Amount of idle Amount of idle time required before
time required before suspending session disconnecting session
Microsoft network server: Digitally sign Digitally sign server communications
communications (always)
Microsoft network server: Digitally sign Digitally sign server communication (when
communications (if client agrees) possible)
Microsoft network server: Disconnect clients Automatically logoff users when logon time
when logon hours expire expire (local)
Network access: Allow anonymous Not available
SID/Name translation
Network access: Do not allow anonymous Not available
enumeration of SAM accounts
Network access: Do not allow anonymous Additional restrictions for anonymous
enumeration of SAM accounts and shares accounts.
Note: Shows as Enabled and Disabled Note: In Windows the following options are
possible:
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 Not available
credentials or .NET Passports for network
authentication
Network access: Let Everyone permissions Not available
apply to anonymous users
Network access: Named Pipes that can be Not available
accessed anonymously
Network access: Remotely accessible registry Not available
paths and sub-paths
Network access: Restrict anonymous access Not available
to Named Pipes and Shares
Network access: Shares that can be accessed Not available
anonymously
Network access: Sharing and security model Not available
for local accounts
Network security: Do not store LAN Not available
Manager hash value on next password
change
Network security: Force logoff when logon Automatically log off users when logon time
hours expire expires
Network security: LAN Manager LAN Manager authentication level
authentication level
Network security: LDAP client signing Not available
requirements
Network security: Minimum session security Not available
for NTLM SSP based (including secure RPC)
clients
Network security: Minimum session security Not available
for NTLM SSP based (including secure RPC)
servers
Recovery console: Allow automatic Recovery console: Allow automatic
administrative logon administrative logon
Recovery console: Allow floppy copy and Recovery console: Allow floppy copy and
access to all drives and all folders access to all drives and all folders
Shutdown: Allow system to be shut down Allow system to be shut down without
without having to log on having to log on
Shutdown: Clear virtual memory page file Clear virtual memory page file when system
shuts down
System cryptography: Force strong key Not available
protection 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 Not available
created by members of the Administrators
group

System objects: Require case insensitivity for Not available
non-Windows subsystems

System objects: Strengthen default Strengthen default permissions of global
permissions of internal system objects (e.g. system objects (e.g. Symbolic Links)
Symbolic Links)
System settings: Optional subsystems Not available
System settings: Use Certificate Rules on Not available
Windows Executables for Software
Restriction Policies
Not available Unsigned non-driver installation behavior
Appendix
D
D Content format
This appendix describes the XML-based content format that you can use to author
BMC BladeLogic content. This content format is aimed primarily at enabling the
creation of rules and policies outside of the BMC BladeLogic product so that they are
available for import into BMC BladeLogic using the BLCLI.
Packaging content
All XML-based content format files adhere to the content.xsd XML schema provided
with BMC BladeLogic (and stored in the installation directories). A typical XML-
based content format file contains definitions of and references to a range of BMC
BladeLogic configuration objects, such as BLPackages and grammar files. When using
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 within a compressed ZIP file.
Overview of content format XML files

Content format files are structured hierarchically. At the top level, you can choose to
include root nodes for the following BladeLogic 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.

Overview of content format XML files
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 BMC BladeLogic GUI.
types Definitions for the following types of data used in BMC BladeLogic (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 BladeLogic GUI.

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>
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
Operators
Under the operators node in the content format file, you can list various operators
used in compliance rules or discovery signatures so that they are available for
reference from various data types under the types node or for specification under the
policies node (in the case of compliance rules) or from the signature node of a
service (in the case of a discovery signature).
NOTE
Inclusion of the operators node in the content format file is optional. Furthermore, 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 block of XML code presents an example of several operators listed
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>
For further details about the operators used in rules and signatures, see Operand
data types and operator compatibility on page 283.
Grammars
Under the grammars node in the content format file, you can list various grammar
files that are used to parse configuration objects (configuration files or extended
objects) so that they are available for referencing from within the specifications of
configuration objects elsewhere in the content format file.
NOTE
For built-in grammar files (with built-in="true"), grammar definitions merely reflect the
current configuration. For custom grammar files (with built-in="false"), you can also use
the content format file to define new grammar files or to modify existing grammar files.
The following block of XML code presents an example of several grammar files listed
under the grammars node.

Packages
<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>
For further details about grammar files and their association with configuration files,
see Grammar files on page 632. For the syntax of references to grammar files, see
the sample code on page 1115.
Packages
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 block of 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>
NOTE
The path attribute specifies the path to the BLPackage within the Depot folders in BMC
BladeLogic. The payload-path attribute specifies the physical location of the BLPackage
payload.

Types
For further details about BLPackages and their definitions, see Editing a BLPackage
on page 383. For the syntax of references to BLPackages, see the sample code on
page 1119.
Types
The types node presents various types of data used in BladeLogic (as accepted, for
example, by rules, properties, or configuration objects).
The types node branches off into the following nodes of data types:
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 merely 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.
The following table presents example blocks of XML code for the various data types:
XML code Description

<primitives> Primitives are the most basic data
<primitive name="Decimal" id="Primitive:Decimal"> forms, such as those based on simple
<operators>
<operator-ref id="greater than or equal to"/>
strings or numbers. For each primitive
<operator-ref rhs-type="Range:Primitive:Decimal you specify an ID and a name, as well
Range" id="between"/> as a list of operators supported by the
<operator-ref id="equals"/> primitivea.
<operator-ref id="does not equal"/>
<operator-ref rhs-backing-type="Primitive:Decimal"
rhs-type="List" id="is not one of"/>
The ID of a primitive always begins
<operator-ref rhs-backing-type="Primitive:Decimal" with the Primitive: prefix.
rhs-type="List" id="is one of"/>
<operator-ref id="greater than"/>
</operators>
</primitive>
</primitives>

Types

<enumerations> The enumeration data type enforces a
<enumeration name="ServiceErrorControlEnumeration" choice of values from a closed list.
id="Enumeration:ServiceErrorControlEnumeration"
type="Primitive:String" built-in="true">
<value name="IGNORE" id="IGNORE">IGNORE</value> The ID of an enumeration always
<value name="NORMAL" id="NORMAL">NORMAL</value> begins with the Enumeration: prefix.
<value name="SEVERE" id="SEVERE">SEVERE</value>
<value name="CRITICAL" id="CRITICAL">CRITICAL</value>
</enumeration>
</enumerations>
<ranges> A range defines values between two
<range name="Integer Range" id="Range:Primitive:Integer points. Supported operators are listed
Range" type="Primitive:Integer">
<operators>
for each range.
<operator-ref id="equals"/>
<operator-ref id="does not equal"/> Currently, BladeLogic supports only
</operators> the three ranges presented here.
</range>
<range name="Date Range" id="Range:Primitive:Date Range"
type="Primitive:Date">
The ID of a range always begins with
<operators> the Range: prefix.
</operators>
</range>
<range name="Decimal Range" id="Range:Primitive:Decimal
Range" type="Primitive:Decimal">
<operators>
</operators>
</range>
</ranges>
<lists> The list data type accepts multiple
<list type="Class://SystemObject/Device"> values provided by the user.
<operators>
<operator-ref rhs-type="Class://SystemObject/Device"
id="contains"/> For each list you specify the list type
<operator-ref id="equals"/> and provide a list of operators
<operator-ref id="does not equal"/> supported by the lista.
</operators>
</list>
<list type="Primitive:Encrypted String">
<operators>
<operator-ref rhs-type="Primitive:Encrypted String"
id="contains"/>
</operators>
</list>
</lists>

Types

<property-classes> Definitions of property classes as
<class visible="true" deprecated="false" configured in the Property Dictionary
name="Class://SystemObject/User" (see Using the Property Dictionary on
id="Class://SystemObject/User" built-in="true"> page 118).
<description>Every User is an Instance of this
Class</description>
<operators> For each property class you provide a
<operator-ref rhs-type="Primitive:String" id="not list of operators supported by the
instance of"/> property classa, as well as an optional
<operator-ref rhs-type="Primitive:String" list of properties included in the class.
id="instance of"/>
<operator-ref id="does not equal"/> The ID of a property class always
</operators> begins with the Class: prefix, and
<properties> includes the full path to the property
<property deprecated="false" editable="false" built- class within the Property Dictionary
in="true" required="true" used-in-report="false"
id="DEFAULT_ROLE" type="Class://SystemObject/Role">
(for example: //SystemObject/User).
<description>Default Role</description>
</property>
<property deprecated="false" editable="false" built-
in="true" required="true" used-in-report="false"
id="FAILED_LOGINS" type="Primitive:Integer">
<description>Number of failed logins</description>
<default>
<value>0</value>
</default>
</property>
<property deprecated="false" editable="true" built-
in="false" required="false" used-in-report="false"
id="MY_INTEGER_ENUM" type="enumeration">
<enumeration type="Primitive:Integer">
<value name="intvalue1" id="intvalue1">1</value>
</enumeration>
<default>
<value>1</value>
</default>
</property>
</properties>
</class>
</property-classes>

Data instances

<configuration-objects> Definitions of configuration objects
<extended-objects>
(extended objects, server objects, or
<extended-object id="Groups"> configuration files), as defined in the
<description></description> Configuration Object Dictionary (see
<grammar-data grammar-ref="ini.gm" os="Windows" Using the Configuration Object
encoding="Default"/> Dictionary on page 627).
<command remote-execution="false">blquery
$server:host$ -E "/C/Program Files/BMC Software/BladeLogic/
8.0/share/sensors/extended_objects/groups.blq"</command>
</extended-object>
</extended-objects>
<server-objects>
<class root="false" version="1" name="Extended
Object" id="Extended Object" built-in="true">
<properties>
<property name="Path" id="Path"
type="Primitive:String"/>
<property name="Name" id="Name"
type="Primitive:String"/>
</properties>
</class>
</server-objects>
<configuration-files>
<configuration-file
id="??TARGET.WINDIR??/desktop.ini">
<grammar-data grammar-ref="ini.gm" os="Windows"
encoding="Default"/>
<path>??TARGET.WINDIR??/desktop.ini</path>
</configuration-file>
</configuration-files>
</configuration-objects>
a
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).
Data instances
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 were defined for the instance.
The following block of XML code presents an example of a single data instance of one
property class under the data-instances node.

Rule library
<data-instances>
<class-ref id="Class://SystemObject/DataStore/Pxe DataStore/Local DataStore"/>
<instance id="LocalDataStoreInstance">
<description>OOB local Instance</description>
<property id="BROKEN_OBJECT">
<value>false</value>
</property>
<property id="NAME">
<value>LocalDataStoreInstance</value>
</property>
<property id="FULL_PATH">
<value>Non-Applicable</value>
</property>
<property id="LOCATION">
</property>
<property id="VIRTUAL_DIR">
</property>
</instance>
</class-ref>
</data-instances>
For further details about the definitions of property class instances, see Creating or
modifying an instance of a property class on page 129.
Rule library
The rule library is unique to the content format file, and does not correspond to any
existing entity in the BMC BladeLogic 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 block of XML code presents an example of two rules within the rule
librarya discovery signature and a compliance rule.

Services
<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 further details about the corresponding rule definitions, see Adding or editing a
compliance rule on page 273. For the syntax of references to rules in the rule library,
see the sample code on page 1119.
Services
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 BladeLogic GUI.
NOTE
The definitions of the compliance rules associated with a component template are represented
separately in the content format file as policy entities. For more information, see Policies on
page 1118.
Under the services node, individual services are grouped under folders, which
correspond to component template groups. For each service, you can choose to
include the following nodes of service definitions:
allowed-operations
configuration-objects
properties
local-properties
parts
signature
The following table presents example blocks of XML code under the Services node
for the various next-level definitions:

Services
Equivalent BladeLogic
XML code configuration
<services> The folder corresponds to a
<folder name="Component Template Group"> component template group.
<service id="internal_service_id">
<notes>notes for service</notes>
The service ID is used
</service> internally in the file for
</folder> associating other objects, such
</services>
as entities, to services.
<allowed-operations> Allowed operations for a
<operation id="Discover"/> component template, as
<operation id="Snapshot"/> defined on the General panel
<operation id="Audit"/> (see General on page 261)
<operation id="Deploy"/>
<operation id="Compliance"/>
<operation id="Allow_Remediation"/>
<operation id="Allow_Auto_Remediation"/>
</allowed-operations>
<configuration-objects> Local configuration objects for

<extended-objects>
a component template
<extended-object id="Groups"> (extended objects, server
<description></description> objects, or configuration files),
<grammar-data grammar-ref="ini.gm" os="Windows" as defined on the Local
encoding="Default"/> Configuration Objects panel
<command remote-execution="false">blquery $server:host$ -E
"/C/Program Files/BMC Software/BladeLogic/8.0/share/sensors/
(see Local configuration
extended_objects/groups.blq"</command> objects on page 293)
</extended-object>
</extended-objects>
<server-objects>
<class root="false" version="1" name="Extended Object"
id="Extended Object" built-in="false">
<properties>
<property name="Path" id="Path" type="Primitive:String"/>
<property name="Name" id="Name" type="Primitive:String"/>
</properties>
</class>
</server-objects>
<configuration-files>
<configuration-file id="??TARGET.WINDIR??/desktop.ini">
<grammar-data grammar-ref="ini.gm" os="Windows"
encoding="Default"/>
<path>??TARGET.WINDIR??/desktop.ini</path>
</configuration-file>
</configuration-files>
</configuration-objects>
Properties assigned to the
<properties>
<property id="AUTO_GENERATED">
component template, not
<value>true</value> including local properties.
</property>
</properties>

Services
<local-properties> Local properties assigned to
<property deprecated="false" editable="true" built-in="false" the component template, as
required="false" used-in-report="false" id="MY_INTEGER_ENUM" defined on the Local
type="enumeration"> Properties panel (see Local
<enumeration type="Primitive:Integer">
properties on page 291)
</enumeration>
<default>
<value>1</value>
</default>
</property>
<property deprecated="false" editable="true" built-in="false"
required="false" used-in-report="false" id="TEST_INTEGER"
type="Primitive:Integer">
<default>
<value>10</value>
</default>
</property>
</local-properties>
The server objects that make
<parts>
<part id="File:??EXTPROC_HOME??/extproc.exe">
up the component template,
<notes>My part notes</notes> as defined on the Parts panel
<item> (see Parts on page 262)
<type>File</type>
<path>??EXTPROC_HOME??/extproc.exe</path>
</item>
<allowed-operations>
<operation id="Discover"/>
<operation id="Snapshot"/>
<operation id="Audit"/>
<includes-excludes recurse-subfolders="true"/>
</part>
<part id="Windows Service:BladeLogic RSCD Agent">
<notes></notes>
<item>
<type>Windows Service</type>
<path>BladeLogic RSCD Agent</path>
</item>
<allowed-operations>
<operation id="Browse"/>
<operation id="Snapshot"/>
<operation id="Audit"/>
<includes-excludes recurse-subfolders="true"/>
</part>
</parts>

Service instances
The component signature
<signature>
<rule name="Template Signature" service="xml test service">
used in discovery, as defined
<expression><![CDATA[??TARGET.OS?? is one of ["AIX", "Linux", on the Discovery panel (see
"HP-UX", "Windows"]]]></expression> Discover on page 264)
</rule>
</signature> You can instead refer to a
signature defined in the rule
library.
Service instances
A service instance in the content format file represents an instance of a local property
set for a component template.
The following block of XML code presents an example of two service instances
associated with one service under the service-instances node.
For further details about the corresponding instances of local property sets in BMC
BladeLogic, see Adding or modifying instances of a local property set on page 292.
<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
Policies
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 within the
BMC BladeLogic.
NOTE
In the content format file, multiple policies can be associated with a single service. In BMC
BladeLogic, on the other hand, each component template has only one set of compliance rules.
Therefore, during an import to BMC BladeLogic, each policy is associated with a single
component template and the policy groups together all compliance rules defined for that
component template.
The following block of 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
<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">
<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>
For further details about the corresponding rule definitions, see Adding or editing a
compliance rule on page 273.

Policies

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 BladeLogic 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 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 policy
A list of roles that have been granted permissions in the form of system authorizations,
command authorizations, authorization profiles, and ACL templates. ACL policies can be
managed from a central location. Any changes made to the policy automatically take effect on
any objects where the policy has been applied. Like an ACL template, an ACL policy lets you
develop complex set of permissions that can be easily applied to system objects.
ACL template
A list of roles that have been granted permissions in the form of system authorizations,
command authorizations, and authorization profiles. By defining an ACL template, you can
grant a complex set of permissions that are not associated with any particular object. Then,
when defining permissions for a role or system object, you can add the ACL template to the
permissions for that role or system object.
Active Directory
Microsoft's directory service, which provides a centralized system for automating management
of networked entities, such as applications, files, printers, and users.
AD/Kerberos authentication
The approach BMC BladeLogic 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 BladeLogic 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.
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 BladeLogic.
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 BladeLogic client (BMC BladeLogic 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 BladeLogic user and issuing a session
credential to the user. Typically, an authentication service is implemented within the BMC
BladeLogic 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 BladeLogic, 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 BladeLogic. 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. Automation principals
can also be used for accessing Active Directory servers.
B
bare metal
A term describing a computer that has not yet been provisioned with an operating system.
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 BladeLogic 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. Once you have
created a BLPackage, you can use a Deploy Job to install it on remote servers.
built-in property class

A group of properties that are automatically associated with a type of object in BMC BladeLogic.
For example, all properties in the Jobs built-in property class are automatically associated with
all jobs.
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 displays in the content editor.
On the left side of the tab, you see a hierarchical tree that consists of multiple nodes. Each node
represents a different category of information for that server, including the servers live state,
which shows all server objects and components on the server.
C
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 BladeLogic command line interface. Using the CLI, you can perform most procedures
available in the BMC BladeLogic Console.
client
A machine running the BMC BladeLogic 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.
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.

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 BladeLogic configuration files also control how communication occurs between
Network Shell and the BMC BladeLogic Console and RSCD agents running on servers and
how logging is performed. The primary BMC BladeLogic configuration files are the users,
exports, and secure files.
content editor
The primary area of user interaction in the BMC BladeLogic 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 previous
releases BMC BladeLogic 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:
The decision to stop ongoing support for certain types of functionality. BMC BladeLogic
continues to support deprecated functions in limited contexts to allow for backward
compatibility. In a future release BMC BladeLogic 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 BladeLogic. A deprecated item still
exists but it is no longer displayed in the Property Dictionary. Once 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
BladeLogic. 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 in.
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 BladeLogic 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 BladeLogic. 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.
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 BladeLogic 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 BladeLogic 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
BladeLogic, 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 BladeLogic. 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-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.
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 BladeLogic 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.
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 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
BladeLogic 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 protocol for querying and modifying
directory entries that are arranged in a hierarchical, tree-like structure.
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 BladeLogic implementation of Kerberos is based on MITs Kerberos v5.
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 BladeLogic Console.

log4crc file
A BMC BladeLogic configuration file that controls logging so that all events are logged using
consistent formats.
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 BladeLogic 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 BladeLogic 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 BladeLogic 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.
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 BladeLogic deployment process.

P
parameter
A variable representing a property. 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
BladeLogic, permissions must be defined for all system objects.
perspective
A perspective represents a configuration of views, view tab groups, and editors. By default, the
BMC BladeLogic 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 BladeLogic 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
BladeLogic, 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 BladeLogic.
PropertySync export and import

The process of exporting a Property Dictionary or custom property class from one Application
Server and importing it into another so the properties on the importing system are synchronized
with the properties on the exporting system. Using a PropertySync, you can more easily export
and import system objects such as jobs or component templates because all the property
dependencies for those objects should be satisfied on an importing system.
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.
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 (CA), certificate repositories
(directories), and other mechanisms needed to authenticate, encrypt, and decrypt
communication using public key cryptography. BMC BladeLogic 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 BladeLogic 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
The BMC BladeLogic system of role-based access control. To implement role-based access
decisions, use the tools available in the RBAC Manager folder.
reconfiguration reboot
A type of reboot sometimes required for Solaris servers for some new hardware and software
patches.
remediation
The process of correcting a components configuration when a Compliance Job reveals that the
component does not satisfy the component templates compliance rules.
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.
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.
RBAC Manager 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
BladeLogic accesses.

S
secadmin utility
A BMC BladeLogic utility that allows you to configure the secure file on a particular machine.
secure file
A BMC BladeLogic configuration file that defines how client and server machines communicate.
securecert file
A BMC BladeLogic 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 BladeLogic can access those passwords without any need for user interaction.
secure remote password (SRP)

A protocol for integrating secure password authentication into networked applications. SRP is
the default approach to user authentication in BMC BladeLogic.
SecurID
RSAs authentication protocol based on two-factor authentication.
server
In the BMC BladeLogic context, a machine where an RSCD agent is installed.
server object
The files, software, packages, services, and other constituent elements of a server. BMC
BladeLogic presents all of these elements as objects you can browse, snapshot, audit, and
deploy.
service URL
The identity and address of a BMC BladeLogic Application Service or Network Shell Proxy
Service that can be accessed using a session credential.
session credential
A credential issued to a BMC BladeLogic client application after a successful user login. BMC
BladeLogic clients use session credentials to establish secure sessions with BMC BladeLogic
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.
single-job mode
A server state in which only one Deploy Job can run at a time. Once 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.
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.
simulate phase
An optional phase of a Deploy Job. During the simulate phase, the system performs a dry run of
a deployment.
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. Once 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 BladeLogic 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 BladeLogic 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 BladeLogic
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 BladeLogic 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.
undo
The act of rolling back a deployment to a server.
UNIX-style
All operating systems based on the UNIX paradigm that BMC BladeLogic supports. Currently
those operating systems are Solaris, Linux, HP-UX, and AIX.
users and users.local file

BMC BladeLogic 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.
Virtualization Manager
A BMC BladeLogic module that allows IT organizations to manage both physical and virtual
server and application environments with a consistent user experience. Virtualization Manager
also provides a one-to-many capability for managing virtual infrastructures.
W
Windows user mapping
The process of mapping a BMC BladeLogic 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
Symbols
%f macro 406 SNMP notification options 201
%h macro 406 Targets panel 197
ACL templates
creating 148, 161
general information 162
A modifying 164
access control permissions 164
enforcing 151 template contents 162
managing 145 ACLs
overview 145 avoiding common mistakes 191
system package sharing 1005 for files 235
understanding 145 for one or more system objects 190
access control list templates 161, 162, 164 for property classes 138
access control lists for registry keys 235
for ACL policies 166, 167 for system objects 99, 186, 191
for ACL templates 164 previewing 194
for authorization profiles 160 pushing to agents 192, 194, 195
for automation principals 171 pushing to servers 194
for files 235 setting up for roles 175
for one or more system objects 190 action on failure
for property classes 138 in BLPackages 391
for registry keys 235 Active Directory
for roles 178 browsing 231
for system objects 99, 186, 191 custom configuration objects 237
for users 183 defined 1121
Accessibility objects 239
general preference setting 78 synchronizing with RBAC 184, 185
accessing views 63 activity view
ACL policies of jobs 438
access control list 166 AD/Kerberos authentication
adding a maintenance window 168 defined 1121
creating 149, 165 Add Depot Software wizard
general information 166 Add Software panel 354, 366
modifying 167 Permissions panel 365, 372
permissions 167 Properties panel 364, 372
ACL Push Jobs Add File to Depot wizard
creating 195 General panel 410
Default Notifications panel 198 Permissions panel 411
email notification options 201 Properties panel 410
General panel 196 Add Install Client script
modifying 203 Solaris system package 980
Permissions panel 203 Add NSH Script to Depot wizard
Properties panel 202 Parameters panel 406
schedule options 200 Permissions panel 408
Schedules panel 199 Properties panel 408
Script Options panel 405
Index 1139
Script panel 409 setting change request parameters 422

Add Software panel Using existing Change Ticket option 426
for Add Depot Software wizard 354, 366 architecture
add_install_client command of BMC BladeLogic 30
customizing 980 assets
administrative tools 623 importing into BLPackages 402
configuration files 629 Associated Compliance Rules panel
Configuration Object Dictionary 627 for component exception wizard 311
custom commands 623, 624, 627 asymmetric encryption
custom configuration objects 628, 640, 641 defined 1122
custom icons 639 Audit Jobs
extended objects 636 Component Templates for Filtering panel 478
server objects 628, 641 creating 475
SOCKS proxy servers 667 Default Notifications panel 485
Advanced Options panel email notification options 489
File Deploy Job 513 General panel 477
AES includes and excludes 480
defined 1121 master 479
agent ACLs Masters panel 478
pushing during provisioning 946, 958, 969, 982, 992, modifying 491
1003 options list 482
pushing to agents 192, 194, 195, 197 Permissions panel 491
setting up for roles 175 Properties panel 490
understanding 192 Schedules panel 487
agents 29 server objects list 479
AIX Server Objects panel 479
packages 353 SNMP notification options 489
patches 353 Targets panel 484
AIX system package wizard 475
basic configuration 987 audit options
control flow 995 for component templates 257
firstboot script/agent install 992 audit results 492
local properties 994 exporting 472
localization settings 989 packaging 502
network settings 991 using to group servers 498
NIM scripts 994 using to sync servers 499
optional Bosinst attributes 996 viewing by object 493
Post bos_inst script 997 viewing by server 495
Pre bos_inst script 996 viewing text file differences 497
Pre machine definition scripts 996 Audit Trail view 98, 99
preview 997 audit trails
target disk 989 for system authorizations 156, 158
All perspective 61 managing 152
Annotations viewing 99
general preference setting 78 auditing
Appearance 76 and symbolic links 450
Application Automation components 268, 269, 475, 477
described 24 configuration files 498
Application Servers exporting results 472
connecting to BMC BladeLogic console 40 master 492
information about 665 schedule options 487
introduced 31 snapshots 475
limiting configuration file records 627 understanding 450
reporting information about 666 viewing results 492, 493, 495
tier 30 viewing text file differences 497
Approval Information panel Authentication Profiles
setting approval type 424 setting up 38

authorization profiles email notification options 587

assigning to roles 174 including in Provision Jobs 924
creating 148, 159 Permissions panel 584
modifying 160 Properties panel 584
permissions 160 schedule options 586
selecting authorizations 160 Schedules panel 585
authorizations 151 SNMP notification options 587
command 156, 157, 158 begin script
complete list 1067 Solaris system package 981
creating policies for managing 165 when provisioning servers 1030
creating profiles of 159 BL Editor
effective 147 editing text files 69
enforcing 151 viewing text files 69
managing 147 bladduser utility 204, 205
modifying profiles of 160, 167 BLAdmin user 153, 156
object-based 146 adding 204
resource-based 147 BLAdmins role 153
role 146, 174 BLPackage Deploy Jobs
selecting for authorization profiles 160 creating 527
setting up 148, 156 Default Notifications panel 535
system 156, 158 deploying security settings 556
understanding 145 General panel 529
automation principals Job Options panel 543
creating 149, 169, 172 Package panel 530
general information 170 Permissions panel 555
modifying 171 Phase Options panel 551
permissions for 171 Phases and Schedules panel 536
properties 171 Properties panel 554
auto-remediation BLPackages 349
for Compliance Jobs 316 adding custom actions 401
Auto-remediation panel adding external commands 403
for Compliance Jobs 316 adding local properties 396
AutoYaST entries adding to Depot 375
Linux system package 956 caveats 528
closing an edited package 404
commenting out assets 403
B creating from audit results 499, 502
creating from components 343
backgrounding operations 67 creating from snapshot results 469
backup options creating RPM groups 402
for deploying files 511 deleting objects while editing 398
basic conditions deploying 521, 528
in compliance rules 275, 276, 277 deploying to multiple components 532
in signatures 264, 265, 277 deploying to remediate compliance results 316, 340,
basic configuration 342
AIX system package 987 editing 383, 385, 387, 388, 389, 391, 393, 395, 396, 397
HP-UX system package 998 exporting 101, 102
Linux system package 951 finding and replacing text in instruction file 399
Solaris system package 974 importing 101, 104
VMware system package 964 importing assets into 401, 402
when provisioning servers 1028 includes and excludes 379
Windows system package 931 Map Missing 112
Batch Job Options panel opening for edit 385
for Batch Jobs 581 overview 351
Batch Jobs 579 packaging a component 343
Batch Job Options panel 581 setting action on failure 391
creating 579 verifying 404
Index 1141
BMC BladeLogic copy of WinPE 2.x image to a location for

administrative tools 623 provisioning 884
architecture 30, 31, 32 creating 868
BLPackages 349 for booting from local media 1045
component templates 243 for booting from PXE server with local data store 1048
components 243 placeholders for 869
deploying BLPackages 521 broken dependencies
deploying files 505 finding 98
deploying packages 521 browsing virtual machines 593
deploying software 521
described 23
exporting 101, 102
folder 73
C
folders 84 canceling
getting started 37 jobs 428
importing 101, 104 cardinality conditions
managing access 145 in compliance rules 275, 278
managing jobs 413 in signatures 264
managing properties 117 catalogs
managing servers 207 for patches 697, 701, 707, 711, 712, 732, 736, 742, 743,
managing the console 73 747, 748, 764, 769, 778, 782, 783, 800, 806, 811, 812,
overview 29, 29, 33 828, 834, 839, 840
snapshots 449 certificate authority
software packages 349 defined 1123
starting 40 certificates
Tasks in Progress view 67, 427 defined 1124
viewing dependencies 68, 99 untrusted 43
BMC BladeLogic console 84 viewing or deleting 45
content editor 57 viewing untrusted 43
customizing preferences 73 change a perspective 63
editor 57 change tracking 459, 463
elements 51 changes
global menu bar 54 removing 468
global tool bar 54 tracking internal and external 468
managing 73 using the compare editor 469
menus 58 Changing perspectives 59
perspective 55 changing the sort order of a column 83
perspectives 58 character encoding
provisioning 72 for text files 69, 70
Quick Access 57 Child Explorer tables
quick tour 57 customizing 81
tab group 56 choosing editors 71
title bar description 54 Classic perspective 61
tool bars 58 perspectives
view 56 Classic 61
views 58 Classic2 perspective 61
BMC Preferences clearing filters 67
Display Options 75 client tier 30
File Deploy Options 75 of BMC BladeLogic 31
Live Browse Results Option 76 Colors and Fonts
Paging Options 76 general preference setting 76
BMC Software, contacting 2 columns
boot image files changing sort order 83
assigning to a device 1008 customizing 81
configuring 919 formatting 83
copy of WinPE 1.6 image to TFTP server 897 commands
adding 157

authorizing for roles 174 elements within 275

deleting 158 operand data types 283
modifying 157 operators 283
commit options viewing as part of Compliance Job results 334
for deploying packages 552 Component Discovery Jobs 248
Compare Editor Component Templates panel 296
for viewing changes 469 creating 294
Compare/Patch Default Notifications panel 298
general preference setting 77 email notification options 301
compliance General panel 295
and remediation 289 modifying 302
exceptions 305, 307 Permissions panel 302
of components 273, 290, 312, 330 Properties panel 302
Compliance Exceptions panel schedule options 300
for New Component wizard 305 Schedules panel 299
Compliance Job results 331, 340, 342, 344 SNMP notification options 301
acting on remediation results 338 Targets panel 298
defining exceptions 337 Component folder 85
undoing remediation 339 component groups 90, 91
using to edit compliance rule 336 adding components 312
viewing by rule 332 smart 92
viewing by server 333 Component Template folder 85
viewing for compliance rules 334 component templates 243
viewing remediation results 338 adding local properties 291, 292
Compliance Jobs adding parts 253
and component templates 271 and Compliance Jobs 271
automatically remediating results 316 auto-remediation 289
Component Templates for Filtering panel 315 compliance 290
component templates list 315 compliance rule groups 273
Components panel 315 compliance rules 273, 274, 275, 290
creating 312 creating 251
Default Notifications panel 324 defining a signature 264
email notification options 328 defining in a content format file 1114
exporting results 344 discovering 264, 296, 298
General panel 314 editing 260
manually remediating results 340 editing compliance rules 336
modifying 330 includes and excludes 255
Permissions panel 330 list of snapshot and audit options 257
Properties panel 329 local properties 291
remediating results 342 modifying parts 255, 262
results 331, 340, 344 parts 252, 253, 262
schedule options 326 remediation options 289
Schedules panel 326 snapshots and audits 268, 269
setting deploy values for remediation jobs 318 testing a signature 266
SNMP notification options 328 Component Templates folder 34, 85, 86, 250
viewing and using results 331 adding folders 90, 91
Compliance Rule Editor adding smart groups 250
General panel 274 copying, cutting, and pasting 250
Remediation Options panel 289 creating component templates 251
Rule Definition panel 275 deleting 250
compliance rules editing component templates 260
commenting and uncommenting 290 organizing contents 250
copying, cutting, and pasting 290 smart component template groups 92
creating or editing 273, 276 Component Templates for Filtering panel
defining exceptions 309, 310, 311, 312, 337 for Audit Jobs 478
editing 274, 275 for Compliance Jobs 315
editing from compliance results 336 for Snapshot Jobs 454
Index 1143
component templates list configuration for provisioning

for Audit Jobs 478 custom system package types 907
for Compliance Jobs 315 image files 919
for Snapshot Jobs 454 installation file locations 913
Component Templates panel PXE server 915
for Component Discovery Jobs 296 TFTP server 916
components 230, 243 configuration for provisioning servers 902
adding manually 303 Configuration Object Dictionary 627, 639
adding to component groups 312 adding custom configuration objects 628
auditing 475, 477, 478 configuration files 629
browsing 268 deleting custom configuration objects 640
checking compliance 312, 315, 330 extended objects 636
compliance exceptions 307 grammar files 632
compliance of 315 server objects 628
defining exceptions to compliance rules 309, 310, 311, configuration objects 236
312, 337 deregistering 656
discovering 248, 294, 302 distributing 642
exporting 101, 102 in content format files 1109
importing 101, 104 local 293
modifying 307 updating 649
packaging and deploying 343 console
process for using 245, 248 BMC BladeLogic 84
running audits on 268, 269 Component Templates folder 85
snapshots of 268, 269, 452, 454 Components folder 85
templates for 251, 260 content editor 57
Components folder 34, 85, 250 customizing preference settings 73
adding groups 90, 91 Depot folder 85
adding smart groups 250 Devices folder 86
copying, cutting, and pasting 250 editor 57
deleting 250 elements 51
organizing contents 250 global menu bar 54
smart component groups 92 global tool bar 54
Components panel Jobs folder 86
for Compliance Jobs 315 managing 73
for component exception wizard 312 menus 58
for Create BLPackage wizard 378 perspective 55
computer settings perspectives 58
HP-UX system package 999 Quick Access 57
Linux system package 952 quick tour 57
Solaris system package 975 RBAC Manager folder 87
VMware system package 966 Search 88
Windows system package 933 Servers folder 88
conditional constructs tab group 56
defining for compliance rule or signature 281 Tasks in Progress view 67, 427
in compliance rules 275, 276, 280 title bar description 54
in signatures 264, 265 tool bars 58
conditions view 56
in compliance rules 275, 276, 277 views 58
in signatures 264, 265 content editor 57
configuration files content editors
auditing 498 BL Editor 69
exporting 101, 102 selecting 71
grammars for creating 632 setting preferences 71
identifying 627, 629 ShellEd 70
importing 101, 104 working with 68
limiting records processed 627 content format 1105
paths to 48 Content Types

general preference setting 77 refreshing 84

conventions data store 1027
documentation 26 configuring 903
Create BLPackage wizard data store instances
Components panel 378 local data store 1044
Depot Files panel 378 properties 1064
Master Snapshot panel 379 provisioning strategies 1064
Package Contents panel 377 databases
Package Options panel 381 connecting to Application Server 31
Package Types panel 376 information about 667
Permissions panel 382 decommissioning
Properties panel 382 servers 228
Select Server Objects panel 377 Default Notifications panel
Snapshots panel 378 for ACL Push Jobs 198
Software panel 378 for Audit Jobs 485
creating a maintenance window 168 for BLPackage Deploy Jobs 535
creating folders or groups 91 for Compliance Jobs 324
creating new objects 88 for Component Discovery Jobs 298
custom actions for Deregister Configuration Object Jobs 658
for BLPackage assets 401 for Distribute Configuration Objects Jobs 644
custom commands for File Deploy Jobs 514
administering 623 for Network Shell Script Jobs 571
creating and modifying 624 for Snapshot Jobs 459, 584
defining 623 for Software Deploy Jobs 535
deleting 627 for Update Server Properties Jobs 215
executing 240 for Upgrade Model Objects Jobs 651
custom configuration object tables deleting
customizing 82 groups and folders 96
custom configuration objects 236, 238, 239 system objects 96
adding 628 dependencies
deleting 640 between properties 126
using jobs to manage 641 broken 98
versioning 237 viewing 99
custom icons deploy activity
defining 639 and internal changes 469
custom property classes showing 469
adding 123 Deploy Jobs 521
deprecating 131 commit options 552
removing 131 controlling 561
custom software controlling for servers 564
adding to Depot 353 deploying to multiple components 532
custom system package types 907 email notification options 542
customer support 3 modifying 556
customize a perspective 63 phase scheduling 538
customizing phase selection 538
Child Explorer tables 81 pre/post commands 553
columns from a pop-up menu 83 Properties panel 554, 555
fixed-column tables 81 rebooting servers 563
tables and columns 81 running after packaging component 343
customizing custom configuration object tables 82 schedule options 541
customizing keystroke combinations 79 servers not targeted by 564
customizing preferences 73 setting options 318
simulate and stage options 551
SNMP notification options 542
D states 559, 562
taking action on 561
data taking actions on 560
Index 1145
Targets panel 535 Display Options for BMC Preferences 75

undoing 562 Distribute Configuration Object Jobs
using for uninstalling 557 General panel 642
using results 559 Permissions panel 648
DEPLOY_ALLOW_NFS_DURING_SUM server property Properties panel 648
565 schedule options 646
Depot Selected Configuration Objects panel 643
adding BLPackages 375 Targets panel 644
adding custom software 353 Distribute Configuration Objects Jobs 642
adding files 409, 410 Default Notifications panel 644
adding folders 90, 91, 350 Distribute Configuration Update Jobs
adding hotfixes 365, 366, 372 email notification options 647
adding Network Shell scripts 404 docking a view 63
adding smart groups 350 domain controller
adding software packages 353 defined 1126
copying, cutting, and pasting 350 DOS scripting
deleting 350 in system package 928
folder 34, 85
modifying Network Shell scripts 408
organizing contents 350
smart depot groups 92
E
Depot Files panel editing BLPackages 383
for Create BLPackage wizard 378 adding custom actions 401
Depot folder adding external commands 403
Folders view 85 adding local properties 396
depot objects changing file ownership attributes 395
adding depot files 409 changing network-based software deploy options 391
creating 349 changing object attributes 385
Deregister Configuration Object Jobs 656 changing object properties 393, 396
Default Notifications panel 658 closing a package 404
email notification options 661 commenting out assets 403
General panel 657 creating RPM groups 402
Permissions panel 663 defining action on failure 391
Properties panel 662 deleting an object 398
schedule options 660 finding text 399
Selected Configuration Objects panel 658 importing assets 402
Targets panel 658 moving objects within 397
detaching a view from the perspective 64 opening a BLPackage 385
device ordering by dependency 397
permissions 1020 providing password information 398
properties 1020, 1057 replacing text 399
settings 1020 setting a reboot 389
Devices folder setting single user mode 388
Folders view 86 verifying an object 404
directories working with soft links 387
backup options when deploying 511 editing component templates 260
copying and pasting 233 browsing 268
deleting 234 compliance 271
discovery discovery 264
of components 264, 294, 302 general information 261
testing for component templates 266 local configuration objects 293
disk partition local properties 291
HP-UX system package 999 parts 262
Linux system package 949 snapshots and audits 268
Solaris system package 972 editor
VMware system package 962 content editor 57
Windows system package 929 Editors

general preference setting 78 importing 101, 104

editors limiting records processed 627
BL Editor 69 external changes
selecting 71 removing 468
setting preferences 71 tracking 468
ShellEd 70
working with 68
email notification options
for ACL Push Jobs 201
F
for Audit Jobs 489 fdisk partitions 984
for Batch Jobs 587 File Associations
for Compliance Jobs 328 general preference setting 78
for Component Discovery Jobs 301 File Deploy Jobs 505
for Deploy Jobs 542 Advanced Options panel 513
for Execution Tasks 433 Default Notifications panel 514
for File Deploy Jobs 517 email notification options 517
for Network Shell Script Jobs 574 General panel 507
for Snapshot Jobs 463 global deployment options 512
for Update Server Properties Jobs 218, 647, 654, 661 modifying 519
encoding Options panel 509
of characters 69, 70 Permissions panel 519
entries pre/post commands 513
in configuration files 48 Properties panel 518
ESX schedule options 516
provisioning 960 Schedules panel 515
ESX servers Targets panel 508
configuring properties 211 File Deploy Options 75
exceptions File Deploy Options for BMC Preferences 75
to compliance rules 309, 310, 311, 312, 337 file deploys 506
excludes list backup options 511
for Audit Jobs 480 global deployment options 512
for BLPackages 379 indirect push 510
for component templates 255 pre/post commands 513
for Snapshot Jobs 455 synchronized push 509
Execution Tasks file ownership attributes
creating and fully defining 430 changing in BLPackage 395
creating through jobs 429 file paths
deleting job runs 437 rules for entering 47
email notification options 433 file properties
executing 436 security 235
for managing job runs 429 viewing 234
modifying 435 file servers 451
schedule options 432 files
viewing history 436 adding to Depot 409, 410
Explorer perspective 61 backup options when deploying 511
export copying and pasting 233
of Audit Job results 472 deleting 234
of Compliance Job results 344 editing 69, 70
of Snapshot Job results 472 exporting 101, 102
of system packages 1006 grammar 632
exporting 102 importing 101, 104
exporting objects 101 filter 57
extended objects 230 filters 66, 67
creating icons 639 finding system objects with broken dependencies 98
creating or modifying 627, 636 fixed-column tables
exporting 101, 102 customizing 81
grammars for creating 632 folder content
Index 1147
organizing 89 Compare/Patch 77
folders Content Types 77
adding 250 Editors 78
adding groups or folders 89 File Associations 78
adding smart groups 89 Hyperlinking 78
Component Templates 34, 85 Keys 79
Components 34, 85 Label Decorations 76
copying, cutting, and pasting within 89 Quick Diff 78
creating 89, 91 Text Editors 78
cutting and pasting 95, 96 General preferences
deleting 96 Colors and Fonts 76
Depot 34, 85 general preferences
Devices 86 Appearance 76
in BMC BladeLogic 84 Gentoo pre-installation image
Jobs 34, 86 skipping during provisioning 901
organizing content 89 getting started 37
RBAC Manager 35, 87 Authentication Profiles 38
Servers 33, 88 BMC BladeLogic 40
Folders view 85 changing passwords 47
Depot folder 85 logging in 40
Devices folder 86 session credentials 44, 45
Jobs folder 86 stored certificates 45
RBAC Manager folder 87 switching roles 46
Search 88 global configuration parameters
Servers folder 88 for patching 693, 727, 761, 797, 825
formatting columns 83 global deployment options
for deploying files 512
global menu bar
G description 54
global preference settings 76
General panel global tool bar 54
for ACL Policy wizard 166 grammar files 632
for ACL Push Jobs 196 importing 106
for ACL Template wizard 162 in content format files 1107
for Add File to Depot wizard 410 groups
for Audit Jobs 477 copying, cutting, and pasting 95, 96
for Compliance Jobs 314 creating 89, 90, 91
for Compliance Rule Editor 274 deleting 96
for Component Discovery Jobs 295
for component exception wizard 310
for Deploy Jobs 529
for Deregister Configuration Object Jobs 657
H
for Distribute Configuration Objects Jobs 642 Help Desk perspective 61
for Execution Tasks 431 history
for File Deploy Job 507 viewing for jobs 438
for Network Shell 568 hotfixes
for New Component wizard 304 adding to Depot 365, 366, 372
for Role wizard 174 deploying 525
for Snapshot Jobs 452 modifying 372
for Update Server Properties Jobs 213 HP-UX
for Upgrade Model Objects Jobs 650 bundles 353
General Preference 76 patches 353
general preference setting products 353
Spelling 78 provisioning 860
general preference settings 78 HP-UX system package
Accessibility 78 basic configuration 998
Annotations 78 boot script 1003

computer settings 999 Map Missing Compliance Jobs 114

disk partition settings 999 Map Missing Component Discovery Jobs 114
Ignite commands/scripts 1001 Map Missing Component Templates 113
Ignite parameters 1002 Map Missing Deploy Jobs 115
local properties 1004 Map Missing Depot Objects 113
network settings 1000 Map Missing Network Shell Scripts 115
post-install script/agent install 1003 map missing properties 109
preview 1004 Map Missing Servers and Server Groups 108
software selection 1002 Map Missing System Packages 112
hung jobs 443 Property Values Mapping 111
Hyperlinking remediation group 107
general preference setting 78 servers 223
Hyper-V system packages 112, 1006
specifying in Windows system package 941 importing objects 101, 104
includes list
for Audit Jobs 480
I for BLPackages 379
for component templates 255
IBM Frame for Snapshot Jobs 455
browsing 611 indirect push
managing 610, 612 for Deploy Jobs 536
icons for File Deploy Jobs 510
defining 639 information
Import Contents panel for users in RBAC 180
for Import wizard 106 infrastructure management
Import wizard Application Servers 665
Import Contents panel 106 database 667
Map Existing System Package Types panel 112 job execution 683
Map Missing BLPackages panel 112 PXE servers 666
Map Missing Compliance Jobs panel 114 routing rules 688
Map Missing Component Discovery Jobs panel 114 SOCKS proxy servers 667, 668
Map Missing Component Templates panel 113 Infrastructure Management window 663, 673
Map Missing Deploy Jobs panel 115 InstallShield packages
Map Missing Depot Files panel 113 adding to Depot 353
Map Missing Network Shell Scripts panel 115 installing 525
Map Missing Properties panel 109 instances
Map Missing Servers and Server Groups panel 108 deprecating property class 131
Property Values Mapping panel 111 of component template local properties 292
Select Destination Group panel 106, 107 of property classes 120, 129
Select Import Source Directory panel 106 removing property class 131
imported devices internal changes
adding 1007 removing 468
importing a list of devices 1011 tracking 468
overview 1006 intrinsic properties 208, 1056
viewing 1019 complete list 1087
imported servers IS_DEPLOYABLE server property 564
deleting 1023
importing 101, 109, 111
contents 106
destination grammars 106
J
destination group 107 Job Options panel
file format for servers 225 for Deploy Jobs 543
import source directory 106 job parts
MAC address file 1017 canceling 445
MAC address list 1011 time-outs for 444, 445
MAC address list and configuration values 1012 job schedule log for change management approval jobs
Map Missing BLPackages 112 425
Index 1149
job schedules customizing 79

viewing 443 Kickstart entries
jobs 413 VMware system package 967
and properties 416, 421 kickstart entries
avoiding hung 443 Linux system package 955
canceling 428 VMware system package 967
executing 418, 683, 684
executing a job with change management approval
422
executing against failed targets 419
L
executing against specific targets 418 Label Decorations
executing as specific role and user 421 general preference setting 76
exporting 101, 102 limiting objects displayed in smart groups 95
exporting logs 442 limiting objects using a text filter 66
for managing custom configuration objects 641 Linked Mode 78
for managing custom server objects 641 general preference setting 78
importing 101, 104 Linux system package 948
in progress 67, 427, 428 AutoYaST entries 956
managing 413, 417 basic configuration 951
opening 417 computer settings 952
setting approval type 424 disk partition settings 949
time-outs for 444, 445 kickstart entries 955
updating server status before running 446 local properties 959
viewing activity 438 network settings 954
viewing definitions 417, 441 OS components 953
viewing history 438 OS components for Red Hat Linux 953
viewing logs 441 OS components for SUSE Linux 954
viewing schedules 443 post-install configuration settings 958
Jobs folder 34, 86 Live Browse Results Option 76
adding folders 90, 91, 416 Live node
adding smart groups 416 contents for virtual environments 593
copying, cutting, and pasting 416 local boot 1045
deleting 416 local configuration objects
Folder view 86 adding to component templates 293
managing jobs 413 local data store 1044
organizing jobs 416 local groups
smart job groups 92 viewing properties 234
JumpStart provisioning 851, 856 local properties
Jumpstart rules file adding to BLPackages 396
customizing 980 adding to component templates 291, 292
AIX system package 994
creating in system package 1014
K HP-UX system package 1004
Linux system package 959
Kerberos Solaris system package 986
defined 1129 VMware system package 971
kernel parameters Windows system package 948
x86 985 local users
key bindings viewing properties 234
customizing 79 localization settings
keyboard combinations AIX system package 989
customizing 79 login 40
keyboard shortcuts logs
viewing 79 exporting for jobs 442
Keys viewing for jobs 441
general preference setting 79 loops
keystroke combinations defining for compliance rule 282

in compliance rules 275, 276, 282 minimum disk space

for deploying files 512
mistakes
M when defining permissions 191
moving a Tab Group 63
MAC addresses moving and docking a view 63
creating file of 1015 MSI packages
importing file of 1017 adding to Depot 353
importing list of 1011 deploying 525
macros multiple objects
%f 406 paging 67
%h 406
maintenance window 429, 564
creating 168
specifying the time window 168
N
managing virtual environments 591 navigating perspectives 62
managing with the BMC BladeLogic console 73 navigating views 62
Map 109 network configuration
Map Existing System Package Types panel Linux system package 954
for Import wizard 112 Solaris system package 976
Map Missing BLPackages panel VMware system package 966
for Import wizard 112 when provisioning servers 1029
Map Missing Compliance Jobs panel Windows system package 942
for Import wizard 114 network definition
Map Missing Component Discovery Jobs panel AIX system package 991
for Import wizard 114 HP-UX system package 1000
Map Missing Component Templates panel Network Routing Wizard 669
for Import wizard 113 Network Shell 29
Map Missing Deploy Jobs panel creating scripts 567
for Import wizard 115 modifying scripts 576
Map Missing Depot Files panel Network Shell Script Jobs 567
for Import wizard 113 Default Notifications panel 571
Map Missing Network Shell Scripts panel email notification options 574
for Import wizard 115 General panel 568
Map Missing Properties panel Parameters panel 570
for Import wizard 109 permissions 576
Map Missing Servers and Server Groups panel Permissions panel 576
for Import wizard 108 properties 576
master 475 Properties panel 576
for Audit Jobs 478, 479, 492 schedule options 573
Master Snapshot panel Schedules panel 572
for Create BLPackage wizard 379 SNMP notification options 574
Masters panel Targets panel 569
for Audit Jobs 478 Network Shell scripts
matching patterns 629 adding to Depot 404
maximize a view or tab group 64 modifying 408
menus New Component wizard 303
quick tour 58 Compliance Exceptions panel 305
Microsoft Hyper-V General panel 304, 310
browsing 613 Permissions panel 304
managing 613, 614 Properties panel 304
middle tier nexec commands
of BladeLogic 30 adding 157
of BMC BladeLogic 31 deleting 158
minimize a view or tab group modifying 157
views NIM provisioning 858
minimizing 64 no access nodes 152
Index 1151
notifications Package Options panel 503

for BLPackage Jobs 535 Package Type panel 503
for Compliance Job results 324 Package Options panel
for Compliance Jobs 324 for bundling snapshot results 470
for Component Discovery Jobs 298 for Create BLPackage wizard 381
for Software Deploy Jobs 535 for Package Delta wizard 503
nouser option 192 for Sync wizard 501
Package panel
for BLPackage Deploy Jobs 530
O package specifications
Solaris system package 978
object view Package Type panel
of audit results 493 for Create BLPackage wizard 376, 470
object-based permissions 146, 186 of Package Delta wizard 503
objects packages 349
assigning permissions 151 adding BLPackages 375
creating new 88 adding software 353
custom 636 adding to Depot 353
exporting 102 creating 349
extended 636 deploying 521
importing and exporting 101 in content format files 1108
limiting 95 modifying software 372
refreshing 84 overview 350
searching for 90 Paging Options 76
user-defined 636 paging through multiple objects 67
opening a new view 63 Parameter panel
opening a perspective 62 for Add NSH Script to Depot wizard 406
operating systems parameters 208
supported by provisioning 852 adding to BLPackages 385
operations inserting 142
running in background 67 using for extended objects 638
operators using in provisioning 1056, 1059
in content format files 1107 using to reference scripts 1063
options list Parameters panel
for Audit Jobs 482 for Network Shell Script Jobs 570
for component templates 257 parts
for Snapshot Jobs 457 component template 252, 253, 262
Options panel modifying component template 255, 262
for File Deploy Jobs 509 specifying for compliance 272
Oracle Enterprise Linux patching 823 passwords
organizing folder content 89 changing 47
OS components defining 179
Linux system package 953 providing for BLPackages 398
Linux system package for Red Hat Linux 953 patch management
Linux system package for SUSE Linux 954 creating patch catalog 707, 743, 778, 806, 834
Windows system package 940 creating patching jobs 715, 750, 785, 813, 841
overview defining catalog 800, 828
of access control 145 defining offline catalog 701, 736, 742, 769
of BMC BladeLogic 29, 33 defining online catalog 697, 732, 764
of this guide 24 deploying patches 723, 758, 792, 820, 848
for Microsoft Office 723
global configuration parameters 693, 727, 761, 797, 825
P grouping catalog contents 712, 747, 783, 811, 839
maintaining catalogs 712, 748, 783, 812, 840
Package Contents panel Oracle Enterprise Linux 823
for Create BLPackage wizard 377 permission for patch catalogs 692
Package Delta wizard 502 permissions for patch catalogs 726, 760, 796, 824

Red Hat Enterprise Linux 759 for component templates 260

remediating servers 720, 755, 790, 817, 846 for files 411
reporting 724, 758, 793, 821, 849 for jobs 219, 576, 648, 655, 663
Solaris 725 for manual components 304
SUSE Linux Enterprise 795 for system objects 152
viewing catalog 711, 747, 782, 811, 839 granting access to users 183
viewing patching job results 717, 787, 815, 843 managing 147
viewing published patches 696, 731, 763, 799, 827 modifying 99
viewing remediation results 722, 757, 792, 820, 848 object-based 146, 186
Windows 691 pushing to servers 194, 195
patches resource-based 147
adding to Depot 365, 366, 372 role-based 146
creating patch catalog 707, 743, 778, 806, 834 understanding 145
creating patching jobs 715, 750, 785, 813, 841 updating for groups 151
defining catalog 800, 828 updating for objects 151
defining offline catalog 701, 736, 742, 769 viewing 99
defining online catalog 697, 732, 764 Permissions panel
deploying 723, 758, 792, 820, 848 for ACL Policy wizard 167
for Microsoft Office 723 for ACL Push Jobs 203
global configuration parameters 693, 727, 761, 797, 825 for Add Depot Software wizard 365, 372
grouping catalog contents 712, 747, 783, 811, 839 for Add File to Depot wizard 411
maintaining catalogs 712, 748, 783, 812, 840 for Add NSH Script to Depot wizard 408
Oracle Enterprise Linux 823 for Audit Jobs 491
permissions for patch catalogs 692, 726, 760, 796, 824 for Batch Jobs 584
Red Hat Enterprise Linux 759 for Compliance Jobs 330
remediating servers 720, 755, 790, 817, 846 for Component Discovery Jobs 302
reporting for 724, 758, 793, 821, 849 for Create BLPackage wizard 382
Solaris 725 for Deploy Jobs 555
SUSE Linux Enterprise 795 for Deregister Configuration Object Jobs 663
viewing catalog 711, 747, 782, 811, 839 for Distribute Configuration Objects Jobs 648
viewing patching job results 717, 787, 815, 843 for Execution Tasks 432
viewing published 696, 731, 763, 799, 827 for File Deploy Jobs 519
viewing remediation results 722, 757, 792, 820, 848 for Network Shell Script Jobs 576
Windows 691 for New Component wizard 304
patching jobs for Snapshot Jobs 465
creating 715, 750, 785, 813, 841 for Update Server Properties Jobs 219
viewing results 717, 787, 815, 843 for Upgrade Model Objects Jobs 655
paths Permissions view 98, 99
rules for entering 47 Perspectives 58
Perl scripts 405 perspectives 55, 60
permissions 99 All 61
assigned when cutting and pasting 96 changing 59
assigning to automation principals 171 Classic 61
assigning to multiple objects 151, 190 Classic2 61
assigning to objects 99, 151, 186, 191 customizing 63
assigning to property classes 138 detaching a view 64
assigning to roles 178 Explorer 61
avoiding mistakes 191 Help Desk 61
default 96 navigating 62
delegating authority 186 opening 62
enforcing 151 preconfigured 61
for ACL policies 167 reattaching a view 64
for ACL Push Jobs 203 resetting defaults 62
for ACL templates 164 saving a customized 63
for authorization profiles 160 working with 62
for Compliance Jobs 330 Phase Options panel
for Component Discovery Jobs 302 for Deploy Jobs 551
Index 1153
phases profile entries

for deploying packages 538, 561 Solaris system package 979
Phases and Schedules panel profiles
for Deploy Jobs 536 creating authorization 148
PKI properties 98, 117, 208, 212, 1056
defined 1132 adding or modifying 125
platforms and jobs 416
supported by provisioning 852 and parameters 142
Policy Access Control List panel assigning when provisioning servers 1027
for ACL Policy wizard 166 changing for one or more objects 141
post-disk partition creating instances of property classes 129
Windows system package 931 defining for automation principals 171
post-install configuration defining for roles 178
AIX system package 992 defining for users 183
HP-UX system package 1003 dependencies 126
Linux system package 958 deprecating 131
Solaris system package 982 for ACL Push Jobs 202
VMware system package 969 for Compliance Jobs 329
when provisioning servers 1030 for Component Discovery Jobs 302
Windows system package 946 for component templates 259
Pre Install script for files 410
VMware system package 961 for jobs 464, 576
pre/post commands for manual components 304
for Deploy Jobs 553 for Network Shell scripts 408
for File Deploy Jobs 513 importing 109, 111
preconfigured 61 intrinsic 208, 1056, 1087
preferences local 291, 396
Accessibility 78 modifying 140
Annotations 78 overview 117
BMC Display Options 75 property class 126
BMC File Deploy Options 75 referencing scripts 1063
BMC Live Browse Results Option 76 removing 131
BMC Paging Options 76 server 210, 211, 212
Colors and Fonts 76 setting values 140
Compare/Patch 77 using in provisioning 1056
Content Types 77 using to access data store 1027
customizing 73 using to rename servers 212
Editors 78 viewing 98, 140
File Associations 78 Properties panel
general appearance settings 76 for ACL Push Jobs 202
global settings 76 for Add Depot Software wizard 364, 372
Hyperlinking 78 for Add File to Depot wizard 410
Keys 79 for Add NSH Script to Depot wizard 408
Label Decorations 76 for Audit Jobs 490
Linked Mode 78 for Batch Jobs 584
Quick Diff 78 for Compliance Jobs 329
Spelling 78 for Component Discovery Jobs 302
Text Editors 78 for Create BLPackage wizard 382
Pre-install scripts for Deploy Jobs 554, 555
Windows system package 928 for Deregister Configuration Object Jobs 662
preview for Distribute Configuration Objects Jobs 648
Solaris system package 986 for Execution Tasks 432
private keys for File Deploy Jobs 518
defined 1132 for Network Shell Script Jobs 576
process for New Component wizard 304
for using components 245, 248 for Snapshot Jobs 464
product support 3 for Update Server Properties Jobs 219

for Upgrade Model Objects Jobs 654 post-install configuration 1030

Properties view 98 preparing jobs for 924
property class properties 126 re-provisioning servers 1042
property classes server ACL 1032
adding custom 123, 132, 133, 134 server properties 1032
built-in 118 starting and stopping provisioning jobs 1031
creating instances of 129 strategies for 1064
custom 118, 120 supported operating systems 852
defining permissions for 138 system package properties for 1057
example 120 system package selection 1027
importing and exporting 132, 133, 134 understanding process 852
in content format files 1109 using parameterized properties in wizard 1058
removing custom 131 viewing history of 1022
synchronizing 138 viewing provisioning history 1022
Property Dictionary viewing system package history 1023
adding custom property classes 123 provisioning strategies
adding properties 125 using data store instances 1064
deprecating custom classes 131 provisioning with BMC BladeLogic 72
deprecating instances 131 provisioning wizard
deprecating properties 131 using 1024
importing and exporting 132, 133, 134 public key cryptography
modifying properties 125 defined 1132
removing custom classes 131 public key infrastructure
removing instances 131 defined 1132
removing properties 131 public keys
using 118 defined 1132
using custom property classes 120 PXE protocol 851
Property Values Mapping panel PXE server
for Import wizard 111 configuring 915
PropertySync information about 666
importing and exporting properties 132 starting and stopping 917
provisioned servers
classifying 1023
deleting 1023
viewing 1020
Q
provisioning Quick Access 57
device properties for 1057 Quick Diff
properties for 1056 general preference setting 78
provisioning history quick tour
viewing 1022 changing perspectives 59
viewing system package history 1023 content editor 57
provisioning servers 867, 1024 menus 58
assigning properties 1027 tool bars 58
basic configuration 1028 views 58
basics 851 quick tour of console 57
begin script 1030
classifying servers as provisioned 1023
configuration for 902, 907, 913, 915, 916, 919
configuring data store for 903
R
creating custom system package type 907 RAID controller drivers
creating system packages 925 unattended entries for 943
data store instances 1064 RBAC 32, 151
integration with server management 862 audit trails 152
monitoring provisioning status 1019 authorizations 145, 146, 147, 1067
network configuration 1029 automation principals 169, 171
organizing system packages 1005 built-in roles 153
overview 862 built-in users 153, 156
Index 1155
creating ACL templates 161 status of 682

creating authorization profiles 159, 165 viewing 680
creating roles 173 re-provisioned servers 1042
creating users 179 resetting perspective defaults 62
Manager folder 35, 87, 147 resizing a view 64
managing 145 resources
modifying ACL templates 164 creating 88
modifying authorization profiles 160, 167 restoring a view 64
modifying roles 179 restoring perspective settings 62
modifying users 183 results
overview 145 of Audit Jobs 472, 492, 498
pushing agent ACLs 192 of change tracking 466
setting up authorizations 156 of Compliance Jobs 331, 340, 342, 344
synchronizing users with Active Directory 184, 185 of Deploy Jobs 559
RBAC Manager folder 87 of Snapshot Jobs 466, 472
RBACAdmin user 153, 156 role-based access control 32
adding 204 roles
RBACAdmins role 153 agent ACLs 175
reattaching a view to the perspective 64 assigning to users 182
reboot script assigning users 178
Solaris 983 authorizations for 146, 174
reboots creating 150, 173
for servers 563 general information 174
setting in BLPackages 389 modifying 179
Red Hat permissions for 146, 178
adding RPMs to Depot 353 pre-packaged 153
provisioning 948 properties 178
Red Hat Enterprise Linux summary information 178
patching 759 rollback files 523, 545, 552, 564
refreshing the data 84 routing rules 687
registry assigning SOCKS proxy servers to 674
editing multi-value 396 creating 669
viewing properties 234 creating complex rules 685
viewing security 235 deleting 689
remediation evaluating job execution rules 684
creating packages for 342 evaluating repeater rules 682
of Compliance Job results 316, 318, 340, 342 evaluation of 688
of patch configurations 720, 722, 755, 757, 790, 792, for determining repeater server 677
817, 820, 846, 848 for job execution 683
remediation jobs re-ordering 689
setting values for 318 viewing 688
undoing 339 RPM groups
Remediation Options panel in BLPackages 402
for Compliance Rule Editor 289 RSCD agents 29
remediation view installing during provisioning 946, 958, 969, 982, 992,
of Compliance Job results 338 1003
remote servers 667 Rule Definition panel
rename for Compliance Rule Editor 275
of servers 212 rule groups
repeaters for component compliance 273
deleting 681 rules
for indirect pushes 510, 536 creating or editing 276
for indirect staging 675 defining in a content format file 1113, 1118
managing 680 elements within 275
routing rules for 677 for component compliance 273, 274, 275, 290
rule evaluation for 682 for routing to remote servers 669
server objects for 676 operand data types 283

operators 283 secure remote password

rules view defined 1134
of Compliance Job results 332 security
running operations in background 67 BMC BladeLogic 33
for files 235
security settings
S editing 393
effective 375
saving a customized perspective 63 in BLPackages 375, 556
schedule options limitations when deploying 556
for ACL Push Jobs 199, 200 local 375
for Audit Jobs 487 viewing 234
for Batch Jobs 586 Select Destination Grammars panel
for Compliance Jobs 326 for Import wizard 106
for Component Discovery Jobs 299, 300 Select Destination Group panel
for Deploy Jobs 541 for Import wizard 107
for Deregister Configuration Object Jobs 659 Select Import Source Directory panel
for Distribute Configuration Objects Jobs 645, 652 for Import wizard 106
for Execution Tasks 432 Select Remediation Groups panel
for File Deploy Jobs 516 for Import wizard 107
for Network Shell Script Jobs 572 Select Server Objects panel
for Snapshot Jobs 461 for Create BLPackage wizard 377
for Update Server Properties Jobs 216 Selected Configuration Objects panel
schedules for Deregister Configuration Object Jobs 658
viewing for jobs 443 for Distribute Configuration Objects Jobs 643
Schedules panel Selected Objects panel
for ACL Push Jobs 199 for Upgrade Model Objects Jobs 650
for Audit Jobs 487 selecting editors 71
for Batch Jobs 585 server ACL
for Compliance Jobs 326 when provisioning servers 1032
for Component Discovery Jobs 299 server groups
for Deregister Configuration Object Jobs 659 creating from audit results 498
for Distribute Configuration Objects Jobs 645 smart 92
for Execution Tasks 431 server objects 230
for File Deploy Jobs 515 adding to component templates 253
for Network Shell Script Jobs 572 copying and pasting files and directories 233
for Snapshot Jobs 461 creating for repeaters 676
for Update Server Properties Jobs 216 creating for SOCKS proxy servers 668
for Upgrade Model Objects Jobs 652 deleting files and directories 234
Script Options panel for snapshots and audits 450
for Add NSH Script to Depot wizard 405 included in Audit Jobs 479
Script panel included in Snapshot Jobs 454
for Add NSH Script to Depot wizard 409 listing 627
scripts managing 232
adding to Depot 404 modifying in component templates 255, 262
creating 567 starting and stopping services 234
defining parameters 406 using jobs to manage custom 641
exporting 101, 102 viewing 234
importing 101, 104 Server Objects panel
modifying 408, 576 for Audit Jobs 479
using properties to reference 1063 for Snapshot Jobs 454
viewing 409 server properties
SCSI controller drivers when provisioning servers 1032
unattended entries for 943 server tier
Search of BladeLogic 30
Folders view 88 of BMC BladeLogic 32
searching for objects 90 server view
Index 1157
of audit results 495 viewing services 234

of Compliance Job results 333 service packs
servers adding to Depot 365, 366
and properties 208 deploying 525
assigning to a server group 226 modifying 372
browsing 229 services
communicating through SOCKS proxy server 667 starting and stopping 234
configuring for use of repeater servers 675 viewing properties 234
decommissioning 228 session credentials
defining properties for VMware servers 211 deleting 44
deleting 1023 viewing 45
executing custom commands on 240 session key
import file format 225 defined 1134
importing 223 setting preferences for text editors 71
limiting access 32 sharing
master 475 objects 186
monitoring provisioning status 1019 ShellEd
mounting with NFS 565 editing Network Shell Scripts 70
moving and copying between server groups 227 viewing Network Shell Scripts 70
obtaining status before running jobs 446 showing deploy activity 469
organizing 220 signatures
provisioned 1023 creating or editing 265
provisioning 1024 elements within 264
provisioning history 1022 for components 248, 264, 266
rebooting 563 operand data types 283
receiving agent ACLs 197 operators 283
removing from system 228 testing 266
renaming 212 simulate options
re-provisioned 1042 for deploying packages 551
system package history 1023 single-user mode 546, 565
taking snapshots of 452 setting in BLPackages 388
updating properties 210, 211, 212 Skip Linux Pre-Install image 901
Servers folder 33, 88, 207 smart groups
adding a new virtual machine 601 and properties 118, 208
adding remote servers 671 component 92
adding servers 221, 222 component template 92
assigning servers to server groups 226 copying, cutting, and pasting 95, 96
browsing servers 229 defining 92
components 230 deleting 96
copying, cutting, and pasting 220 depot 92
deleting 220 exporting 101, 102
extended objects 230 importing 101, 104
Folders view 88 job 92
importing servers 223 limiting contents 95
managing jobs 417 limiting objects displayed 95
managing server objects 232 server 92
organizing servers 220 Snapshot Jobs 452
saving a virtual servers state 599 Component Templates for Filtering panel 454
server objects 230 component templates list 454
smart server groups 92 creating 452
starting and stopping services 234 Default Notifications panel 459, 584
viewing file properties 234 email notification options 463
viewing local groups 234 General panel 452
viewing local user properties 234 includes and excludes 455
viewing registry properties 234 modifying 465
viewing security settings 234 options list 457
viewing server objects 234 Permissions panel 465

properties 464 overview of packaging 350

Properties panel 464 uninstalling 557
schedule options 461 Software Deploy Jobs
Schedules panel 461 creating 525
server objects list 454 Default Notifications panel 535
Server Objects panel 454 General panel 529
SNMP notification options 463 Job Options panel 543
Targets panel 458 Permissions panel 555
snapshot jobs Phase Options panel 551
viewing changes using Compare Editor 469 Phases and Schedules panel 536
snapshot options Properties panel 554
for component templates 257 Software panel 534
snapshots 449 Software panel
adding results to Depot 471 for Create BLPackage wizard 378
and symbolic links 450 for Software Deploy Jobs 534
auditing 475 for uninstall jobs 559
bundling results into BLPackages 469 Solaris
change tracking 466 packages 353
contents of 451 patch clusters 353
exporting results 472 patches 353
location of contents 451 patching 725
of components 268, 269, 452, 454 provisioning 971, 1052
storing 451 rules file customization 980
understanding 450 WAN boot installation of 1052
viewing results 466 Solaris system package 971
Snapshots panel Add Install Client script 980
for Create BLPackage wizard 378 additional profile entries 979
SNMP notification options additional sysidcfg entries 979
for ACL Push Jobs 201 basic configuration 974
for Audit Jobs 489 begin script 981
for Batch Jobs 587 computer settings 975
for Compliance Jobs 328 disk partition settings 972
for Component Discovery Jobs 301 local properties 986
for Deploy Jobs 542 network settings 976
for Execution Tasks 433 package specifications 978
for File Deploy Jobs 517 post-install configuration settings 982
for Network Shell Script Jobs 574 preview 986
for Snapshot Jobs 463 reboot script 983
for Update Server Properties Jobs 218, 647, 654, 661 rules file 980
SOCKS proxy servers x86 parameters 984
assigning to routing rules 674 Solaris Zones
creating objects for 668 browsing 609
deleting 674 managing 610
setting up 667 sort order
status of 674 changing 83
viewing properties of 673 specifying parts
soft links compliance 272
using in BLPackages 387 Spelling
software general preference settings 78
adding to Depot 67, 353, 471 SQL Server
changing network deploy options 391 installing 525
deploying 521, 525, 565 SRP
exporting 101, 102 defined 1134
importing 101, 104 staging directory 523
matching with depot item 373 staging options
modifying packages 372 for deploying packages 551
ordering by dependency in BLPackage 397 states
Index 1159
of Deploy Jobs 559, 561, 562 VMware settings 961, 962, 964, 966, 967, 969, 971
status Windows settings 927, 928, 931, 933, 940, 942, 943, 946,
applicable status types for jobs requiring approval 439 948
of servers 446
support, customer 3
SuSE
provisioning 948
T
SUSE Linux Enterprise tab group 98
patching 795 moving 63
switching roles 46 Properties, Permissions, and Audit Trail 98
symbolic links tab groups 56
in BLPackages 375 maximizing 64
in snapshots and audits 450 minimizing 64
Sync Details panel tables
of Sync wizard 501 customizing 81
Sync wizard 499 customizing Child Explorer 81
Package Options panel 501 customizing columns from a pop-up menu 83
Sync Details panel 501 customizing custom configuration object 82
synchronized customizing fixed-column 81
pushes for files and directories 509 tailor a perspective 63
syntax Targets panel 535
for network data transmission 362 for ACL Push Jobs 197
sysidcfg entries for Audit Jobs 484
Solaris system package 979 for BLPackage Deploy Jobs 535
system authorizations 156 for Component Discovery Jobs 298
audit trails 156, 158 for Deregister Configuration Object Jobs 658
system objects for Distribute Configuration Objects Jobs 644
assigning permissions 151 for Execution Tasks 431
copying, cutting, and pasting 95, 96 for File Deploy Jobs 508
defining permissions for 99, 186, 190, 191 for Network Shell Script Jobs 569
deleting 96 for Snapshot Jobs 458
permissions for 146, 147 for Software Deploy Jobs 535
setting property values 140 for Update Server Properties Jobs 214
system packages tasks
AIX settings 987, 989, 991, 992, 994, 995, 996, 997 in progress 67
creating 925 Tasks in Progress view 67, 427
creating custom system package type 907 closing 428
defining ESX settings 960 hiding 428
defining Linux settings 948 technical support 3
defining Solaris settings 971 templates
defining Windows settings 927 ACL 161, 164
disk partition 929 for components 251, 260
exporting 1006 testing
fields that accept property references 1059 compliance 290
HP-UX settings 998, 999, 1000, 1001, 1002, 1003, 1004 compliance rules 287
importing 112, 1006 component discovery 266
inserting parameters 1059 Text Editors
Linux settings 949, 951, 952, 953, 954, 956, 958, 959 general preference setting 78
organizing 1005 text files
properties 1057 adding to Depot 409
Red Hat 948 viewing and editing 69, 70
selecting when provisioning servers 1027 text filters 66
setting access control on folders 1005 TFTP server
Solaris 983 configuring 916
Solaris settings 972, 974, 975, 976, 978, 979, 980, 981, starting and stopping 918
982, 984, 986 three-tier architecture 30
SuSE 948 time-outs

for Deploy Jobs 555 general information 180

for jobs 444, 445 modifying 183
job part 444, 445 permissions to access 183
job-level 444, 445 pre-packaged 153, 156
tool bars properties 183
quick tour 58 RBACAdmin 156, 204
tracking internal and external changes 468 users.local file 192
Transactions directory 523, 564, 565 using filters to limit objects 66
TRANSACTIONS_DIR server property 564
types of preconfigured perspectives 61
V
U validation, of components 308
values
unattended entries for properties 141
Windows system package 943 viewing dependencies 99
undo viewing keyboard shortcuts 79
files 552 views 56, 58, 60
for a Deploy Job 562 accessing 63
for a remediation job 339 detaching from perspective 64
uninstall jobs 557 maximizing 64
Software panel 559 moving and docking 63
UNIX navigating 62
objects 236 opening 63
UNIX objects 238 preconfigured 61
Update Server Properties Jobs 212 reattaching to the perspective 64
Default Notifications panel 215 restoring 64
email notification options 218 tab group 63
General panel 213 working with 62
permissions 219, 648, 655, 663 virtual environments
Permissions panel 219, 648, 655, 663 contents of the Live node 593
Properties panel 219 IBM Frame 610
schedule options 217 managing Solaris Zones 608
Schedules panel 216, 645, 652, 659 Microsoft Hyper-V 613
SNMP notification options 218, 647, 654, 661 supported platforms 592
Targets panel 214 Virtual Guest Job
Upgrade Model Objects Jobs 649 creating 606
Default Notifications panel 651 Virtual Guest Package
email notification options 654 creating 604
General panel 650 editing 605
Permissions panel 655 overview 604
Properties panel 654 Virtual Infrastructure Discovery Job
schedule options 652 Auto-register discovered ESX Hosts/Virtual Systems
Selected Objects panel 650 617
URL syntax creating 616
for network data transmission 362 Discover Unregistered Virtual Systems 617
user Import Lifecycle Properties 618, 620
synchronizing with Active Directory 184, 185 overview 596
user impersonation 149 viewing results 620
user mapping 149 virtual machines
user privilege mapping 149 adding 601
users browsing 593
assigning roles 178, 182 cloning 384
BLAdmin 156, 204 saving a virtual servers state 599
creating 150, 179, 205 virtualization sprawl
creating without RBAC 204 identifying 615
file 192, 194 managing 615
Index 1161
overview 615 Snapshot Job 452

VMware Software Deploy Job 525
browsing virtual machines 596 Update Server Properties Job 212
creating a Virtual Guest Job 606 working with content editors 68
discovering virtual machines 596 working with perspectives 62
managing 596, 598
saving a virtual servers state 599
viewing server properties 600
VMware system package
X
basic configuration 964 x86 kernel parameters 985
computer settings 966 x86 parameters 984
disk partition settings 962 XML content format files 1105
Kickstart entries 967 XML instruction file 351
kickstart entries 967 editing 383
local properties 971
network settings 966
post-install configuration settings 969
Pre Install script 961
W
WAN boot installation 1052
wild cards 379, 455, 480, 629
Windows
patching 691
Windows Hyper-V
specifying in Windows system package 941
Windows registry
editing multi-value 396
Windows security settings 1099
editing 393
Windows system package 927
basic configuration settings 931
computer settings 933
disk partition 929
DOS scripting 928
local properties 948
network settings 942
OS components 940
post-disk partition 931
post-install configuration 946
pre-install scripts in 928
settings for 927
unattended entries 943
Windows user mapping 149
automation principals 169, 172
wizard
ACL Push Job 195
Audit Job 475
BLPackage Deploy Job 527
Compliance Job 312
Component Discovery Job 294
Deregister Configuration Object Job 656
Distribute Configuration Objects Job 642, 649
File Deploy Job 506
Network Shell Script Job 567

*107213*
*107213*
*107213*
*107213*
*107213*

BMCBladeLogicUserGuide v800 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

BMCBladeLogicUserGuide v800 PDF

Загружено:

Авторское право:

Доступные форматы

BMC BladeLogic Server

Automation User Guide

Copyright 20022009 BladeLogic, Inc.

Restricted rights legend

Support by telephone or e-mail

Before contacting BMC

4 BMC BladeLogic User Guide

Chapter 2 Overview of BMC BladeLogic Server Automation 29

Chapter 3 Getting started 37

Chapter 4 Using the BMC BladeLogic Server Automation console 51

Chapter 5 Properties 117

6 BMC BladeLogic User Guide

Chapter 6 Managing access 145

Chapter 7 Using the Servers folder 207

8 BMC BladeLogic User Guide

Chapter 8 Components and component templates 243

Chapter 9 Creating packages and other depot objects 349

10 BMC BladeLogic User Guide

Chapter 10 Managing jobs 413

Chapter 11 Snapshot Jobs 449

Chapter 12 Audit Jobs 475

12 BMC BladeLogic User Guide

Chapter 13 File Deploy Jobs 505

Chapter 14 Software and BLPackage Deploy Jobs 521

Chapter 15 Network Shell Script Jobs 567

Chapter 16 Batch Jobs 579

Chapter 17 Managing virtual environments 591

14 BMC BladeLogic User Guide

Chapter 18 Administrative tools 623

Chapter 19 Patch management for Microsoft Windows 691

16 BMC BladeLogic User Guide

Chapter 20 Patch management for Solaris 725

Chapter 21 Patch management for Red Hat Enterprise Linux 759

Chapter 22 Patch management for SUSE Linux Enterprise 795

Chapter 23 Patch management for Oracle Enterprise Linux 823

Chapter 24 Provisioning basics 851

Chapter 25 Provisioning servers 867

18 BMC BladeLogic User Guide

20 BMC BladeLogic User Guide

Appendix B Intrinsic properties 1087

Appendix D Content format 1105

BMC BladeLogic Glossary 1121

22 BMC BladeLogic User Guide

BMC BladeLogic lets system administrators provision operating systems onto

System administrators can also take advantage of many virtualization features in

All BMC BladeLogic capabilities are available on multiple operating systems.

Overview of this guide

Chapter 2, Overview of BMC BladeLogic Server AutomationProvides a

Chapter 3, Getting startedDescribes the tasks necessary to start the BMC

Chapter 4, Using the BMC BladeLogic Server Automation consoleIntroduces

Chapter 5, PropertiesDescribes the Property Dictionary and how properties

Chapter 6, Managing accessExplains how to use authorizations to control

Chapter 8, Components and component templatesDescribes how to create and

24 BMC BladeLogic User Guide

Chapter 10, Managing jobsExplains how to perform a variety of job-related

Chapter 12, Audit JobsExplains how to compare server configurations using

Chapter 17, Managing virtual environmentsExplains how to perform basic ad-

Chapter 18, Administrative toolsDescribes how to define commands that can

Chapter 19, Patch management for Microsoft WindowsExplains how to

Chapter 20, Patch management for SolarisExplains how to monitor and

Chapter 22, Patch management for SUSE Linux EnterpriseExplains how to

Chapter 23, Patch management for Oracle Enterprise LinuxExplains how to

Chapter 24, Provisioning basicsProvides a general description of how the