BMCBladeLogicUserGuide v800

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 2101 CITYWEST BLVD HOUSTON TX 77042-2827 USA Telephone 713 918 8800 or 800 841 2031 Fax 713 918 8000
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
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.
BMC BladeLogic User Guide
Contents
Chapter 1 Introduction 23 24 24 26 26 26 26 27 29 30 31 31 32 32 33 33 33 34 34 34 34 35 37 38 38 40 43 44 45 45 46 47 47 48 48 48
5
Application Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Documentation conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Procedural descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Windows and UNIX paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiple approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 2 Overview of BMC BladeLogic Server Automation
System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Middle tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Server tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using BMC BladeLogic A brief overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Depot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RBAC Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 3 Getting started
Preparing for user logins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up an authentication profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting the BMC BladeLogic console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing an untrusted certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting cached session credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing cached session credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing or deleting stored certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Switching roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rules for entering paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration file entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
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

6 BMC BladeLogic User Guide
Understanding custom property classes and instances. . . . . . . . . . . . . . . . . . . . . Adding a custom property class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding or modifying properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating or modifying an instance of a property class . . . . . . . . . . . . . . . . . . . . . Removing or deprecating a property, custom property class, or instance . . . . . Using PropertySync to import and export properties . . . . . . . . . . . . . . . . . . . . . . Viewing and modifying properties for property classes . . . . . . . . . . . . . . . . . . . . Setting values for system object properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing property values for one or more system objects . . . . . . . . . . . . . . . . . . . . . Inserting a parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 6 Managing access
120 123 125 129 131 132 137 140 141 142 145 145 146 146 147 147 147 148 148 148 149 149 150 150 151 151 151 152 152 153 156 156 157 158 158 159 160 160 160 161 162 162 164 164 165 166 166 167
7
Understanding authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Role-based authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object-based authorizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resource-based authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Effective authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Set up authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create authorization profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create ACL templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create ACL policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create automation principals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assign object-based permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Update permissions for multiple objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enforcing authorizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . No access nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing audit trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Built-in roles and users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RBACAdmin and BLAdmin users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding or modifying an nexec command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting an nexec command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining audit trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating an authorization profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying authorization profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating an ACL template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Template Access Control List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying ACL templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating an ACL policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy Access Control List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
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
Default Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying Update Server Properties Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organizing servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a server using the BMC BladeLogic console . . . . . . . . . . . . . . . . . . . . . . . Importing servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning servers to server groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assigning a server to a server group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Moving or copying a server between server groups . . . . . . . . . . . . . . . . . . . . . . . Removing a server: decommissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Browsing servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contents of the Live node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing server objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Copying and pasting files and directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting files and directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting and stopping services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing server objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using custom configuration objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Executing custom commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 8 Components and component templates
215 216 219 219 220 221 222 223 226 226 227 228 229 230 232 233 234 234 234 236 240 243 245 245 245 248 248 250 251 251 252 259 260 260 261 262 264 268 268 271 291 293 294 295 296 298 298 299
9
Process for using components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component usage implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organizing components and component templates . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a component template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing a component template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Discover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Browse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Snapshot/Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Local properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Local configuration objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Component Discovery Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Component Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Add Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying a software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Matching software with depot items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a BLPackage to the Depot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Package Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Package Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Package Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Opening a BLPackage to edit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a custom action to an asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing assets into a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating an RPM group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding an external command to a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commenting out assets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying assets in a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Closing the BLPackage editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a Network Shell script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Script Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying a Network Shell script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding files to the Depot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 10 Managing jobs
365 366 372 372 372 373 375 376 377 381 382 382 383 385 385 396 397 397 398 398 399 401 402 402 403 403 404 404 404 405 406 408 408 408 409 409 410 410 411 413 416 416 417 417 418 418 419 421
11
Organizing jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties and jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing jobs from the Jobs or Servers folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . .
Contents
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 Default Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Server Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying Audit Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing audit results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing audit results by object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing audit results by server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing differences between text files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding audit results for configuration files. . . . . . . . . . . . . . . . . . . . . . . . Grouping non-compliant servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using audit results to synchronize servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sync Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Package Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packaging audit results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Package Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Package Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 13 File Deploy Jobs
478 479 484 485 487 490 491 491 492 493 495 497 498 498 499 501 501 502 503 503 505 506 507 508 509 513 514 515 518 519 519 521 522 522 522 523 524 525 525 527 528 529 530 534 535 535
13
Deploying files and directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying File Deploy Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 14 Software and BLPackage Deploy Jobs
Phases of a Deploy Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulate phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Staging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commit phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploy Job states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic and advanced BLPackage Deploy Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying a software package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying a BLPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caveats for deploying BLPackages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
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 Default Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571 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 Default Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
14
Browsing VMware Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing VMware Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing vCenter server properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a new Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remediating a Virtual Machine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing a Solaris Zones environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Browsing Solaris Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Solaris Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing an IBM Frame environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Browsing IBM Frame Virtual Machines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing IBM LPARs on the frame. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing a Microsoft Hyper-V environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Browsing Hyper-V Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Microsoft Virtual Machines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing virtualization sprawl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifying virtual sprawl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating the server lifecycle properties mapping file . . . . . . . . . . . . . . . . . . . . . . Chapter 18 Administrative tools
596 598 600 601 608 608 609 610 610 611 612 613 613 614 615 615 620 623 623 624 627 627 628 629 636 640 641 642 642 643 644 644 645 648 648 648 649 650 650 651 652 654 655 655 656 657 658 658
15
Administering custom commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating or modifying a custom command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting a custom command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Configuration Object Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a custom configuration object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifying configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating extended objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting a custom configuration object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using jobs to manage custom configuration objects . . . . . . . . . . . . . . . . . . . . . . . Creating a Distribute Configuration Objects Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selected Configuration Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying Distribute Configuration Objects Jobs . . . . . . . . . . . . . . . . . . . . . . . . . Creating an Upgrade Model Objects Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selected Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modifying Upgrade Model Objects Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Deregister Configuration Object Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selected Configuration Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
Default Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remediating servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing remediation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying patches for Microsoft Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patch reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 20 Patch management for Solaris
717 720 722 723 723 724 725 726 726 727 731 732 736 742 743 747 747 748 750 753 755 757 758 758 759 760 761 763 764 769 782 783 783 785 787 790 792 792 793 795 796 797 799 800
Best Practice Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining permissions for the patch catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining global configuration parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing published patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining an online patch catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining an offline patch catalog for Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining an offline catalog for Fujitsu Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating the patch catalog on the BMC BladeLogic Console . . . . . . . . . . . . . . . . Viewing the catalog on the BMC BladeLogic Console. . . . . . . . . . . . . . . . . . . . . . Grouping catalog contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintaining an existing catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a patching job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing results of a patching job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remediating servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing remediation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patch Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 21 Patch management for Red Hat Enterprise Linux
Defining permissions for the patch catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining global configuration parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing published patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining an online patch catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining an offline patch catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing the catalog on the BMC BladeLogic Console. . . . . . . . . . . . . . . . . . . . . . Grouping catalog contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintaining an existing catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a patching job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing results of a patching job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remediating servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing remediation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patch reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 22 Patch management for SUSE Linux Enterprise
Defining permissions for the patch catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining global configuration parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing published patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining a patch catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
17
Viewing the catalog on the BMC BladeLogic Console . . . . . . . . . . . . . . . . . . . . . . 811 Grouping catalog contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811 Maintaining an existing catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812 Creating a patching job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813 Viewing analysis results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815 Viewing remediation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817 Remediating servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817 Viewing remediation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820 Deploying patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820 Patch Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821 Chapter 23 Patch management for Oracle Enterprise Linux 823
Defining permissions for the patch catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824 Defining global configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825 Viewing published patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827 Defining a patch catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828 Viewing the catalog on the BMC BladeLogic Console . . . . . . . . . . . . . . . . . . . . . . 839 Grouping catalog contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839 Maintaining an existing catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 840 Creating a patching job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 841 Viewing results of a patching job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843 Remediating servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846 Viewing remediation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848 Deploying patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848 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
18
Configuring provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the data store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating custom system package types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the location of installation files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the PXE server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the TFTP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting and stopping the PXE server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting and stopping the TFTP server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring boot image files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Including a Batch Job in a system package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a system package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining settings for Windows servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining settings for Linux servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining settings for ESX servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining settings for Solaris servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disk partition Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic configuration Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Computer settings Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Package specifications Solaris. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Additional sysidcfg entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
902 903 907 913 915 916 917 918 919 924 925 927 928 929 931 931 933 940 942 943 946 948 948 949 949 951 952 953 954 955 956 958 959 960 961 962 964 966 966 967 969 971 971 972 974 975 976 978 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
20
Classifying servers as provisioned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Provision Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Choose Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Package Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Select Image (PXE only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Package Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Provisioning Summary (multiple servers only) . . . . . . . . . . . . . . . . . . . . . . . . . . Optional Bosinst Attributes (NIM only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Begin Script (JumpStart only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Post-install Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Provisioning Job Settings (PXE only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Server ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Server Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Provision Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Executing a Provision Job. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing the results of a Provision Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Canceling a Provision Job in progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing and editing a Provision Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the devices for a Provision Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scheduling a Provision Job for execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up default notification of job completion . . . . . . . . . . . . . . . . . . . . . . . . . Viewing the log for a Provision Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exporting the log for a Provision Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Re-provisioning servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Provisioning Windows 2003 or 2008 servers from a local data store . . . . . . . . . . . . Creating the WinPE 2.x image for booting from local media . . . . . . . . . . . . . . . Creating the WinPE 2.x image for booting from the PXE server . . . . . . . . . . . . Creating a system package for use with a local data store . . . . . . . . . . . . . . . . . Associating the LocalDataStore instance with the system package. . . . . . . . . . The CONFIG_STORE property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Provisioning Solaris servers using a WAN boot installation . . . . . . . . . . . . . . . . . . Provisioning target servers with ESXi 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Properties and provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Device Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System package properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data store instance properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Store Instances and provisioning strategies . . . . . . . . . . . . . . . . . . . . . . . . .
1023 1023 1024 1025 1026 1027 1027 1027 1028 1029 1029 1030 1030 1030 1031 1032 1032 1032 1032 1033 1035 1035 1036 1037 1038 1040 1041 1041 1042 1044 1045 1048 1048 1051 1052 1052 1055 1056 1057 1057 1058 1059 1059 1063 1064 1064
Contents
21
Appendix A Appendix B Appendix C Appendix D
System authorizations Intrinsic properties Security settings for Windows 2008, 2003, and 2000 Content format
1067 1087 1099 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 Index 1121 1139
22
Chapter
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.
Chapter 1
Introduction
23
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.
24
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 adhoc 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.
Chapter 1
Introduction
25
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.
26
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.
Chapter 1
Introduction
27
System text
28
Chapter
Overview of BMC BladeLogic Server Automation

2
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.
Chapter 2
29
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 console
BLCLI
reports client (web browser)
Network Shell
Client Tier
PXE / TFTP Server
Application Server(s)
reports server
Network Shell Proxy Server
(optional) BMC BladeLogic core database reporting data warehouse
Middle Tier
Agent File Server
Server Tier
Remote Server Remote Server Agent Server Agent Server Agent Server Agent Server Agent Server
30
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.
Chapter 2
31
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 finegrained 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.
32
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.
Chapter 2
33
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.
34
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
Chapter 2
35
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.
36
Chapter
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 selfsigned 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).
Chapter 3
Getting started
37
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.
38
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.
Chapter 3
Getting started
39
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 BladeLogic Server Automation Administration Guide. Select RSA SecurID Authentication. Select Public Key InfrastructureAuthentication.
6 Click OK.
Starting the BMC BladeLogic console

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.
40
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.
3 Do one of the following:
If you have a valid cached session credential, skip this step.
Chapter 3
Getting started
41
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 BladeLogic Server Automation Administration Guide.
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. between sessions.
B Check Save credential for this session if you want to save a session credential
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.
42
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.
Chapter 3 Getting started 43
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.
44
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.
Chapter 3 Getting started 45
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.
46
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.
Chapter 3
Getting started
47
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:
48
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\
Chapter 3
Getting started
49
Trailing slashes
50
Chapter
Using the BMC BladeLogic Server Automation console

4
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).
Chapter 4
51
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
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
Chapter 4
53
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.
54
Element Perspective
Description 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 preconfigured perspective, is designed for navigating objects in your enterprise. You can open additional perspectives from the drop down list of perspectives in the Perspective title bar or by choosing Window => Open Perspective => perspectiveName. Perspective names appear on tabs 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 rightclick 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.
Chapter 4
55
Element View
Description 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.
56
Quick tour of the BMC BladeLogic Console interface
Element content editor
Description 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).
Chapter 4 Using the BMC BladeLogic Server Automation console 57
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.
Window => Open Perspective => perspectiveName.
As you work within the console, you can select different perspectives by selecting
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.
58
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 twoheaded 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.
Chapter 4
59
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.
60
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
Perspective All
Preconfigured perspectives
Views Folders, Child Explorer, Properties, Permissions, Audit Trail, Property Dictionary, Error Log, Custom Commands, Tasks in Progress Folders, Properties, Permissions, Audit Trail, Tasks in Progress Folders, Tasks in Progress Child Explorer, Properties, Permissions, Audit Trail Folders, Properties, Permissions, Audit Trail, Custom Commands
Classic - the default perspective Classic2 Explorer Help Desk
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.
Chapter 4
61
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
Action
Perspective and View Behavior

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.
62
Table 2
Action
Perspective and View Behavior (continued)

Procedures 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 customize a perspective
To save a customized perspective Views To open a new view To move and dock a view
1. Choose Windows => Save Perspective As. 2. Enter a name for the new perspective and click OK. Choose Window => Show View => viewName. 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.
Chapter 4
63
Table 2
Action
Perspective and View Behavior (continued)

Procedures 1. Right-click in the view tab. 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 detach a view from the perspective grid
To reattach a view to the perspective grid
Do one of the following:
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 view or tab group
1. Do one of the following:
Use the minimize and maximize view or Tab Group.
buttons on a
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.
64
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.
Chapter 4
65
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.
66
Running operations in the background
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.
Running operations in the background

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.
Chapter 4
67
Working with content editors
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.
Working with content editors

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.
68
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.
Chapter 4
69
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. in the file title tab.
6 To close the tab representing the file, click Close
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. in the file title tab.
6 To close the tab representing the file, click Close
70
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.
Chapter 4
71
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.
72
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
Customizing preferences
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.
Chapter 4
73
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.
74
Table 3
Preference
Preference Settings - BMC Category

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 dropdown lists. To set this value you must restart the BMC BladeLogic console. 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.
File Deploy Options
Chapter 4
75
Table 3
Preference
Preference Settings - BMC Category

Setting Options/ Default The maximum number of items that can be displayed when you select a node 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:
Live Browse Results Option
Paging Options
Page Size: a value between 1 and 1000. For more information, see Paging through multiple objects on page 67.
Table 4
Preference
Preference Settings - General Category

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 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 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
Appearance
Colors and Fonts
Label Decorations
Clear the default settings that display additional information about items using label decorations.
76
Table 4
Preference
Preference Settings - General Category (continued)

Setting Options/Default 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, 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.
Compare/Patch
Content Types
Chapter 4
77
Table 4
Preference Editors

Setting Options/Default

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 Use custom caret Enable thick caret Use characters to show changes in vertical ruler
Accessibility
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
78
Viewing keyboard shortcuts
Table 4
Preference Keys

Setting Options/Default Add, edit, remove key bindings for the system. For more information, see Customizing keystroke combinations on page 79.
Viewing keyboard shortcuts

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.
Customizing keystroke combinations

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.
Chapter 4
79
Customizing keystroke combinations
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 clear the filter.
To see all commands again, click Clear
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.
80
Customizing tables and columns

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). columns in the table.
6 Select a row and use the up and down arrows on the right to reposition the 7 Click
beside Format to expand the Column Customization window. See Formatting columns on page 83.
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.
4 Select a row and use the up and down arrows on the right to reposition the
columns in the table.
82
5 Click
beside Format to expand the Column Customization window. See Formatting columns on page 83.
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

Column Customization window.
beside Format to expand the
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.
Reset to return to the original value.
3 Change the display name of the object that appears in the column header. Choose 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
84
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.
Chapter 4
85
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.
86
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 templates, BLPackages, and server object-based Snapshot and Audit Jobsso they 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.
Chapter 4
87
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. Rightclick the ACL Template object. Choose New =>ACL Template to open the Create New ACL Template wizard.
88
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 Jobs, Depot, Devices, Component Template Devices Servers, Components RBAC Manager Folders Yes No No No Groups No No Yes No Smart Groups Yes Yes Yes No
Use the following procedures to define folders, groups, and smart groups: Searching for objects Creating a folder or group Defining a smart group
Chapter 4
89
Searching for objects
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.
Searching for 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).
90
Creating a folder or group
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.
begins with, is one of, or is before.
B In the next drop-down box to the right, select a comparison-operator, such as 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 dropdown, 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.
Creating a folder or group

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.
Chapter 4
91
Defining a smart 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:
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.
92
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:

To add a new smart group, select New => objectType Smart Group from the popup 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).
Chapter 4
93
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.
begins with, is one of, or is before.
C In the next drop-down box to the right, select a comparison-operator, such as 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.
94
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 BladeLogic Server Automation Administration Guide. 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.
Chapter 4
95
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
96 BMC BladeLogic Server Automation User Guide
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.
Chapter 4
97
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.
Chapter 4
99
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.
You can only go to an object if you have permission to access the path to that object and to read the object itself.
NOTE
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.
100
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.
Chapter 4
101
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.
102
Exporting objects
4 Specify objects you want to exclude from the export by selecting any of the
following:
Exclude Option Exclude BLPackages
Displays When You Export: Audit Jobs Batch Jobs Compliance Jobs Component Templates Deploy Jobs Snapshot Jobs Audit Jobs Batch Jobs Audit Jobs Batch Jobs Compliance Jobs Component Discovery Jobs Deploy Jobs Snapshot Jobs Audit Jobs Batch Jobs Audit Jobs Batch Jobs BLPackages Compliance Jobs Component Templates Deploy Jobs Snapshot Jobs Audit Jobs Batch Jobs Batch Jobs Network Shell Script Jobs Batch Jobs Audit Jobs Batch Jobs Compliance Jobs Component Templates Deploy Jobs Snapshot Jobs Audit Jobs
Exclude Compliance Jobs Exclude Component Templates
Exclude Deploy Jobs Exclude Depot Files
Exclude Discovery Jobs Exclude NSH Scripts Exclude NSH Script Jobs Exclude Software
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.
Chapter 4
103
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.
104
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
Chapter 4
105
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
106
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. defined for every grammar file in the list.
3 Repeat the previous two steps for each grammar file so that the correct grammar is
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.
Chapter 4
107
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.
108
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 Matching type not found Detailed Explanation 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.
Chapter 4
109
Importing objects
Reason Matching enumeration with same element not found
Detailed Explanation 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, but the property is defined to use a different type of enumerated data. 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.
Matching enumeration values not found
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 BladeLogic Server Automation Administration Guide.
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.
110
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.
112
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
The Select Depot Object dialog opens.
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.
Chapter 4
113
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. The Import wizard only displays this panel when the object 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. The Import wizard only displays this panel when the object 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
. The Select Depot Object dialog opens.
Chapter 4
115
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.
116
Chapter
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 subclass 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.
Chapter 5
Properties
117
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: Using the Property Dictionary 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 subclass 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 subclass 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
Chapter 5
Properties
119
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.
120
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 211
Version 212
Version 301
Version 302
DEV
QA
DEV
QA
DEV
QA
DEV
QA
1 2 3
1 2 3
1 2 3
1 2 3
1 2 3
1 2 3
1 2 3
1 2 3 instances
Chapter 5
Properties
121
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.
Eastern Division
Properties ROOT_DIR
Inherited From <not inherited>
Default Value /c
Local Value
Application A
ROOT_DIR APP_DIR
Eastern Division <not inherited>
/c apps/a
Version 211
ROOT_DIR APP_DIR VER_DIR
Eastern Division Application A <not inherited>
/c apps/a 211
DEV
ROOT_DIR APP_DIR VER_DIR LEVEL_DIR
Eastern Division Application A Version 211 <not inherited>
/c apps/a 211 <no default>
dev1
apps/sandbox/a dev2
apps/experimental/a dev3
122
Adding a custom property class
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
Chapter 5
Properties
123
for the parent-class. The JuniorAdmin role cannot delete the properties that the subclass inherits, nor can the JuniorAdmin role change enumerated values for any inherited property. However, the JuniorAdmin role can change default values for properties and add properties to the 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. optionally provide descriptive text.
3 For Name, enter the name of a custom property class. For Description, you can 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.
124
Adding or modifying properties
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 Alphanumeric strings Integers Limitations 2,000 characters. 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. True, false, or null. A double-precision 64-bit IEEE 754 floating point number. A day/month/year value, designating a point in time under the Gregorian calendar.
Boolean Decimal numbers Dates
Chapter 5
Properties
125
Data Type Encrypted string
Limitations A string that is encrypted. Encrypted strings are often used to define values for passwords. A user-defined list. A user-defined list. 2,000 characters, displayed in a text editor format so new lines can be easily seen. This data type is typically used for provisioning.
Enumerated list of strings Enumerated list of integers Long blocks of text
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 class User-defined custom property classes or 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.
126
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 opens. to the right of Possible values. The Edit Enumeration dialog . The Enumeration Editor dialog opens.
B. Click Add New Value
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.
Chapter 5
Properties
127
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.
128
Creating or modifying an instance of a property class

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.
Chapter 5
Properties
129
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. 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 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. panel to define an ACL for the instance.
8 Click Next or select the Permissions tab to display the Permissions panel. Use this
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 Defining permissions for a system object on page 186.
9 Click Finish.
130
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 undeprecate the item. If you do, the property, custom property class, or instance is returned to the Properties Dictionary.
1 Choose Configuration => Property Dictionary View. 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.
Chapter 5
Properties
131
Using PropertySync to import and export properties
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
132
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. To perform this procedure, your role must have, at minimum, a PropertyClass.ExportDictionary authorization. For information on granting authorizations to roles, see Creating roles on page 173.
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 Server Automation Administration Guide.
1 Choose Configuration => Property Dictionary View. 2 Do one of the following:
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.
Chapter 5
Properties
133
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. To perform this procedure, your role must have, at minimum, a PropertyClass.ImportDictionary authorization. For information on granting authorizations to roles, see Creating roles on page 173.
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 Server Automation Administration Guide.
1 Choose Configuration => Property Dictionary View. 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. Dictionary object is being imported.
4 Click Next to display the Import Contents panel, which shows that a Property 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.
134
Problem Scenario You have removed a property, property class, or property set instance on the exporting system. On the importing system an object or a property class or property set instance that is not being synchronized references the missing property.
Solution Do one of the following:
On the importing system, remove all references to the missing property, property class, or property set instance. 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 rerun the export. Then, on the importing system, re-run the PropertySync import.
Do one of the following: An import is adding a property class or 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.
Do one of the following: A property exists on the importing system 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. Rerun 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.
Chapter 5
Properties
135
Problem Scenario
Solution
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 nonproperty 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 PropertySync import.
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 exported, but that exported subset refers to one or more properties from a parent class that is not exported, and those properties do not exist in the parent class on the importing system. For example, suppose the exporting system has a hierarchy in which property class A is the parent of B, and B is the parent of C. Property class A includes a property A1. The user exports the Property Dictionary starting at property class B, including a property set instance of B that contains a value for property A1. In this situation, property class A on the importing system must include a property A1. Do one of the following:
On the importing system, manually add the missing properties. Then, re-run the PropertySync import. On the exporting system, export a larger subset of the Property Dictionary, including the property classes where the missing properties are defined. Then, on the importing system, re-run the PropertySync import. On the exporting system, remove all references to properties that are missing on the importing system from the subset of property data that must be exported. Re-run the export. Then, on the importing system, re-run the PropertySync import.
136
Viewing and modifying properties for property classes
Problem Scenario
Solution
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 nonpreviously 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 requires enumerated values exists in a property class that is being synchronized. This property already exists on both the importing and exporting systems. On the exporting system, one or more of the enumerated values for this property are deleted, but those values are still in use by that property on the importing system. Do one of the following:
On the importing system, remove any uses of the deleted enumerated values. Then, re-run the PropertySync import. On the exporting system, re-create the enumerated values that were previously 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
Chapter 5
Properties
137
3 Click OK.
Choosing to synchronize custom property classes

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. By clearing the Synchronize option, you can exclude custom property classes that should not be exported and thus should not be included in a PropertySync import. 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 Automation Administration Guide.
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.
138
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.
Chapter 5
Properties
139
Setting values for system object properties
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 particularly useful when promoting a system object between roles. D. Click OK.
To delete an entry, select the entry and then click Delete Entry
Setting values for system object properties

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
140
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 Inserting a parameter on page 142.
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:
The value of the property is reset to the value it inherits from a built-in property class.
Chapter 5 Properties 141
Inserting a parameter
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.
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. 3 Do one of the following:
Type the parameter delimited by pairs of question marks.
142
Click Select Property following:
. A list of properties displays. Use the list to do one of the
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 5
Properties
143
144
Chapter
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.
Chapter 6
Managing access
145
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:

Role-based authorizations 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.
Role-based authorizations
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.
146
Resource-based authorizations
To perform some actions in BMC BladeLogic, role-based authorization and objectbased authorization are sufficient. However, if you are taking action on any server object that functions as a resource, such as a server, device, or component, you must also be authorized for that particular resource.
Resource-based authorizations
Authorizations at the resource level are granted in the same manner as object-based authorizations. Resources are system objects. For each resource, you must define an access control list. However, the permissions you can set on resources are different than permissions on other system objects. For a server, device, or component, you can grant special-purpose permissions such as Browse, Snapshot, and Audit. To perform actions on resources, you typically need three levels of authorization. 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 resourcebased 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.
Chapter 6
Managing access
147
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.
148
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.
Chapter 6
Managing access
149
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 Automation Administration Guide. 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.
150
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.
Chapter 6 Managing access 151
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.
152
Built-in roles and users

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 outof-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 builtin 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.
Chapter 6
Managing access
153
Built-in roles and users 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 RBACAdmins Built-in Authorizations
Out-of-box Authorizations
Granted Read authorization on all objects in BMC BladeLogic (for example, BLPackage.Read). Granted ModifyACL authorization on all objects in BMC BladeLogic (for example, BLPackage.ModifyACL). The above authorizations are built-in and cannot be modified.
Granted * authorization for all system objects relating to RBAC (for example, Role.* and ACLTemplate.*). Granted Server.PushACL to push ACLs to servers. The above authorizations can be modified as necessary.
154
Default Role BLAdmins
Built-in Authorizations
Out-of-box Authorizations
Granted Read authorization on all system objects within BMC BladeLogic. The Read authorization is built-in and cannot be modified.
Granted * authorization on all classes of system objects within BMC BladeLogic except the following: Role.Read (grants readonly 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. Granted all reports-related authorizations in RBAC except Reports.Administration.
GlobalReportViewers
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 permissions for a system object on page 186.
Chapter 6
Managing access
155
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 Postinstall 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:

Adding or modifying an nexec command Deleting an nexec command Defining audit trails
Adding or modifying an nexec command

Use this procedure to add an nexec command to those managed with RBAC or to modify an existing nexec command. To perform this procedure, you must have, at minimum, the Authorization.Create system authorization.
1 In the RBAC Manager folder, expand Authorizations. 2 Under Authorizations, select Commands. 3 Do one of the following:
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.
Chapter 6
Managing access
157
Deleting an nexec command
Deleting an nexec command

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.
1 In the RBAC Manager folder, expand Authorizations. 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.
1 In the RBAC Manager folder, expand Authorizations. 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.
158
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 and use the Select Server dialog success. Alternatively, you can click Browse 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
Creation wizard displays.
New => Authorization Profile from the pop-up menu. The Authorization Profile
Chapter 6
Managing access
159
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.
160
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.
Chapter 6
Managing access
161
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
Template Access Control List

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.
162
Template Access Control List
Action To add a set of authorizations for a role
Procedure 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.
Chapter 6
Managing access
163
Permissions
Action To use an ACL template to add a predefined set of permissions to one or more roles
Procedure 1. Click Use ACL Template opens. . The Select ACL Template dialog
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 permissions that are centrally managed)
1. Click Use ACL Policy
. The Select ACL Policy dialog opens.
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.
164
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, rightclick the ACL template and select Open from the pop-up menu. The following tabs appear in the content editor: General Template Access Control List These tabs correspond to panels in the New ACL Template wizard. Use these tabs to modify the ACL template.
Select the Properties, Permissions, or Audit Trail tab group to see or modify any of properties, permissions, or audit trail information that apply to this ACL template. For more information, see Properties, Permissions, and Audit Trail tab group on page 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
Chapter 6
Managing access
165
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,
Policy Access Control List

The Policy Access Control List panel provides a list of roles that are granted a particular system or command authorization, and enables you to specify time periods or maintenance windows. If you use an authorization profile to define an ACL profile, the system uses the role/authorization pairings listed in the authorization profile and inserts them into the list of permissions for the ACL profile.
Action To add a set of authorizations for a role Procedure 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.
166
Permissions
Action To use an ACL template to add a predefined set of permissions to one or more role
Procedure 1. Click Use ACL Template . The Select ACL Template dialog opens.
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 define or update a See Creating and modifying maintenance windows on page 168. maintenance window for a server Select the entry and click Delete Entry . To delete an 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 Policy Access Control List
Chapter 6
Managing access
167
Creating and modifying maintenance windows
These tabs correspond to panels in the New ACL Policy wizard. Use these tabs to modify the ACL policy.
Select the Properties, Permissions, or Audit Trail tab group to see or modify any of properties, permissions, or audit trail information that apply to this ACL policy. 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 Name Description Valid period Time window Description Enter the name you want to assign to the ACL policy. Optionally provide descriptive text. Select the start and end dates for the time period. 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 Select your time zone from the drop-down list.
Time zone
168
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. example SnapshotJobExecute.
C Under Available Authorizations, grant the desired authorizations for the role, for 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.
Chapter 6
Managing access
169
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
Creation wizard displays. in the following sections: General Properties Permissions
New => Automation Principal from the pop-up menu. The Automation Principal
4 Provide information for different aspects of the automation principal, as described
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.
170
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 properties on page 140.
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.) Select the Properties, Permissions, or Audit Trail tab group to see or modify any of properties, permissions, or audit trail information that apply to this automation principal. For more information, see Properties, Permissions, and Audit Trail tab group on page 98.
Chapter 6
Managing access
171
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.
172
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:
Chapter 6
Managing access
173
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
optionally provide descriptive text.
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.
174
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.
Chapter 6
Managing access
175
Agent ACL
Optionally, do any of the following:

Field or Option User must exist on agent Allowed Hosts Read Only and Read/Write Description
Map to user name
Check to instruct a server to allow a connection from a user only when an account with the same user name exists on the server. This option is analogous to the exists option in the users configuration file. Specify the hosts from which a user can connect to a server. Separate host names with a colon, such as host1:host2:host3. Specify whether all users in the role are granted either read-only or 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 Automation Administration Guide. Check to force a user connecting to a server to have the same permissions as a user 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.
176
Agent ACL
Field or Option Platform Related
Description Define permissions that vary by platform. Click the UNIX tab and enter the following 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 displays a list of server properties. , which
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.
Chapter 6
Managing access
177
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, see Setting values for system object properties on page 140.
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.
178
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.
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 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.
Chapter 6
Managing access
179
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. sections:
3 Provide information for different aspects of the user, as described in the following
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 % , : # space tab Encoding %25 %2c %3a %23 %20 %09
180
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
participates in directory synchronization.
RBAC database with external user databases such as Active Directory, clear User
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.
infrastructure.
Allow PKI AuthenticationEnables the user to authenticate using public key
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. logs on, check User must change password at next logon.
B To specify that a user must change his or her password the next time he or she
Chapter 6
Managing access
181
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.
182
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, see Setting values for system object properties on page 140.
Permissions
The Permissions panel is an access control list granting roles access to this system 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 information on defining an ACL, see Defining permissions for a system object on 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.
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 user. For more information, see Properties, Permissions, and Audit Trail tab group on page 98.
Chapter 6
Managing access
183
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.
184
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 Required for Active Directory synchronization. Currently, you can only manage LDAP connection objects using the BLCLI.
LDAP connection object LdapConnection.read
Automation Principal
AutomationPrincipal.read Required for Active Directory synchronization.
Chapter 6
Managing access
185
Using object-based permissions
Type of object Role
Authorization required Role.Read Role.Modify Role.ManageUsers User.*
Comments Required for Active Directory synchronization. Required for ongoing maintenance of each user created by the Active Directory synchronization process.
User
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.
186
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
Chapter 6
Managing access
187
Action Select a system object, right-click, and select Update Permissions.
Minimum permission required objectType.ModifyACL 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 To add a set of authorizations for a role
Procedure 1. Click Add to open a dialog for defining permissions.
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.
188
Action To use an ACL template to add a predefined set of permissions to one or more roles
Procedure 1. If you are using the Permissions view to perform this procedure, make sure the Access Control List tab is selected. It should be selected by default. If you are using a wizard to perform this procedure, skip this step. 2. Click ACL template ACL templates. to open a dialog for specifying
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 (sets of permissions that are centrally managed) 1. If you are using the Permissions view to perform this procedure, click the ACL Policy tab. If you are using a wizard to perform this procedure, skip this step. 2. Click ACL Policy policies. to open a dialog for selecting ACL
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 Access Control List To delete an ACL policy 1. Click Delete 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. Chapter 6 Managing access 189
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.
190
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).
Chapter 6
Managing access
191
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.
192
Using agent ACLs
# DBAdmins ACLs entries for DBAdmins role DBAdmins:george DBAdmins:betty rw,map=root rw,map=root
# NSH-only ACLs entries for default Network Shell role george betty rw,map=root 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.
Chapter 6
Managing access
193
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.
194
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.
Chapter 6
Managing access
195
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.
196
Targets
1 For Name, enter an identifying name for the ACL Push Job. For Description, you
can optionally provide descriptive text. clicking Browse click OK.
2 For Save in, identify the Job folder where you want to store this ACL Push Job by
. The Select Folder dialog opens. Use it to select a folder and
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:
Chapter 6
Managing access
197
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. 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. 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.
198
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. Separate multiple email addresses with semicolons, such as
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.
Chapter 6
Managing access
199
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
modify an existing schedule by selecting it and clicking Edit Schedule
or .
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. 2 Do one of the following:
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).
200
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 clock format (00:00 to 23:59). 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 24hour 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.
Scheduled Job Notifications

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:
A Check Send email to and enter the email address of the accounts that should be
Chapter 6
Managing access
201
Properties
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.
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.
202
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 Default Notifications 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 more information, see Properties, Permissions, and Audit Trail tab group on page 98.
Chapter 6
Managing access
203
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
204
Creating users in bulk

Rather than creating users one by one in the RBAC Manager folder, you can use the bladduser utility to create multiple users by importing a file containing a list of user names and passwords. 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 6
Managing access
205
206
Chapter
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.
Chapter 7
207
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.
208
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 DEPLOY_ALLOW_NFS_DURING_SUM
Meaning 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. 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. Indicates that the server is available for use within the system. Indicates a Solaris server should be remediated using Live Upgrade. By default this is set to False. 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. 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. 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. Provides the name of a server and allows you to rename servers. For more information on renaming, see Renaming a server using its properties on page 212. Restricts server access to only those users listed in the servers users file. See Using agent ACLs on page 192. 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.
IS_DEPLOYABLE
IS_ONLINE IS_SOLARIS_LIVE_UPGRADE
MS_OFFICE_INSTALL_LOCATION
MS_OFFICE_INSTALL_USERNAME
MS_OFFICE_INSTALL_PWD
NAME
PUSH_ACL_NO_USERS_FLAG
REPEATER_MAX_CACHE_SIZE
Chapter 7
209
Updating server properties
Property REPEATER_NAME
Meaning 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. 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. 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. Identifies the Alternate Boot Environment present on the server. This property should only be used when IS_SOLARIS_LIVE_UPGRADE is set to True. 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. 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.
REPEATER_STAGING_DIR
REPEATER_STAGING_DIR
SOLARIS_ALTERNATIVE_BOOT_ENV
STAGING_DIR
TRANSACTION_DIR

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 properties on page 211.
210
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
Chapter 7
211
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.
212
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 Default Notifications 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
provide descriptive text. .
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.
Chapter 7
213
Targets
An Update Server Properties Job always updates the status of a target servers RSCD agent.
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.
214
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. 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.
2 To send SNMP trap notifications, under Job Run Notifications, do the following:
Chapter 7
215
Schedules
A Check Send SNMP trap to and enter the name or IP address of the server that
Schedules
Execute job now.
or .
information:
216
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
Select Daily. For At, enter the time when the job should occur. Use a 24-hour clock format (00:00 to 23:59).
Chapter 7
217
Schedules
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 clock format (00:00 to 23:59). B. For On the following days, check the days of the week when the job should occur. You can select multiple days.
Schedule Job Notifications

218
Permissions
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). 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 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 defining an ACL, see Defining permissions for a system object on page 186.
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.
Chapter 7
219
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 Default Notifications Schedules These tabs correspond to panels in the New Update Server Properties Job wizard. Use them to modify the job definition.
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 Server Automation Administration Guide.
Chapter 7
221
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.
1 Open the Servers folder. 2 Right-click the Servers node (the top node in the Servers folder) or any server
group. Then select Add Server from the pop-up menu. The Add New Server wizard opens.
3 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
this server.
. BMC BladeLogic displays the properties already associated with
6 If necessary, edit the properties associated with this server, as described in Setting
values for system object properties on page 140. 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.
222
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 defining an ACL, see Defining permissions for a system object on page 186.
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.
Chapter 7
223
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.
224
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 permissions for a system object on page 186.
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
Chapter 7
225
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.
1 Open the Servers folder. 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.
226
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.
1 Open the Servers folder. 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.
Chapter 7
227
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.
228
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.
Chapter 7
229
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 AIX Server Objects

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

Components Configuration Daemons Extended Objects File System Hardware Information Packages Patches Processes System Info UNIX Groups UNIX Users .NET Global Assemblies Active Directory Applications Complus Components Configuration Event Logs Extended Objects File System Hardware Information 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
Windows
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.
Chapter 7
231
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 Compliance Jobs on page 312.
232
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:

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

From the Servers folder you can copy and paste files and directories within a server or between servers. This utility does not allow you to copy and paste symbolic links or drives.
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.
Chapter 7
233
Deleting files and directories
Deleting files and directories

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.
Viewing server objects

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.
234
Viewing 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.
Chapter 7
235
Using custom configuration objects
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. 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).
3 To view audit settings, click the Auditing side tab. A dialog displays setup
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).
236
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.
Chapter 7
237
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 UNIX User Daemon
Action Update Password Set Password State Stop Start Start with dependencies (for Solaris 10) Restart Reload
238
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.
Chapter 7 Using the Servers folder 239
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:
240
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.
6 Click the right arrow to move your selections to the right panel. 7 Do one of the following:
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 7
241
242
Chapter
Components and component templates

8
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.
Chapter 8
243
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.
244
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.
Chapter 8
245
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. For example, template parts can be collections of files, properties, and registry values or a group of security settings.
Template PartsDefines the collection of configurations on which you can operate.
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.
component has been associated with a server.
BrowseSpecifies the individual template parts that can be browsed once a
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.
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.
ComplianceSpecifies a subset of the component template parts and defines
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 PropertiesSpecify properties you can assign directly to a component
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.
Chapter 8
247
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.
248
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.
Chapter 8 Components and component templates 249
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 component templates. Cut and paste component template folders. Delete components, component templates, folders, groups, and smart groups.
For a description of any of the procedures listed above, see Managing BMC BladeLogic resources on page 84.
250
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 to select a group and click OK.
. The Select Folder dialog opens. Use it
Chapter 8
251
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. template.
BrowseBrowse components that have been discovered using this component
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.
component template. If you do not check this option, you cannot use Deploy Jobs to target components.
DeployDeploy packages to components that have been discovered using this
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.
Chapter 8
253
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.
254
Parts
Updating a template part

Use this procedure to update a part included in a component template.
1 On the Parts list, select a part and then click Update

opens.
. The Update Part window
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. Selecting this option instructs the system to include all folders subordinate to the 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 zerolength 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].
? []
Chapter 8
255
Parts
The following table shows examples of wildcard matches:

Matching Pattern *.html ??? foo.[ch] *.[a-z] web [Ww]eb Explanation Match server objects ending in .html in the current directory Match server objects that contain exactly three characters Match a server object called foo.c or foo.h Match all server objects in the current directory that have a one-letter lowercase extension Match server objects called web 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.
256
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. Chapter 8 Components and component templates 257
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.
258
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.
Chapter 8
259
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 controlled through ACLs. For more information on defining an ACL, see Defining permissions for a system object on page 186.
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 revalidate 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:
260
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.
Chapter 8
261
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.
Updating a template part

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.
262
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. been discovered using this component template.
ComplianceRun Compliance Jobs on this part in any components that have
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 6 If you are adding hierarchical server objects such as directories, and you want
Parts list. The list also shows the operations that you have allowed for the part.
those server objects to include all subfolders, select those server objects in the All Parts list. Then check Recurse subfolders at the bottom of the Includes/Excludes list. Selecting this option instructs the system to include all folders subordinate to the server object that you have selected in the All Parts list.
Chapter 8
263
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.
264
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
Chapter 8
265
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
the right.
button on
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.
266
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. or
Discovered components appear under the servers, each with a green success red failure icon beside it. server, select the discovered component.
7 For more details about the success or failure of component discovery on a specific
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 Noncompliant 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 for false). The actual value detected on the target (either for true or 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.
Chapter 8
267
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
268
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. 2 Click Add Parts
audit. . The Select Parts window opens.
3 From the All Parts list, select the parts that should be available for snapshots and
The All Parts list shows all the component templates parts. To move a part between lists, select the part and click the left or right arrow. Use Shift-click or Control-click to select multiple parts. To move all parts from the Parts Included in Snapshots and Audits list, click the double-left arrow. Alternatively, you can add a part to the component template by clicking Add New . The Add Part window opens. Use this window to add a part, just as you would add a part in the Create New Component Template wizard (see Adding template 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.
Account Disabled - Compare the status of user accounts. ACL Owner - Snapshot or compare the owner of a file or registry key.
Chapter 8
269
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 circumstances trigger an audit, identifies a group or user to monitor, and lists operations to audit.
Checksum - Calculate a unique key (an MD5 checksum) based on all the data in a
file and 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.
270
Compliance Max Size - Compare the maximum size of event logs. Member of - Compare the groups to which users belong. 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 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.
Chapter 8
271
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. 2 Click Add Parts
Jobs. . The Select Parts window opens.
3 From the All Parts list, select the parts that should be available for Compliance
272
Compliance
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 Compliance 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, 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.
1 On the content editor, click the Compliance tab. 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
1 On the content editor, click the Compliance tab. 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. to save the
6 Switch back to the component template editor and click Save

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
can optionally provide descriptive text.
2 For Reference Number, enter any identifier needed to synchronize this rule with
some external system.
3 To temporarily disable this compliance rule, check Comment Out.

For more information 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.
274
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.
Chapter 8
275
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 button for a basic condition, or click the appear. Then click the New Condition 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 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 basic condition on page 277 To define a conditional construct on page 281 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.
276
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.
Chapter 8
277
Compliance
Branch Component Properties Configuration Objects
How to use Expand this branch to select a component property from a hierarchical list of component properties. 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 configuration object.
To select a configuration object or configuration object property that was recently used in the rule, either click the branch of the specific configuration object or expand that branch and click one of the properties listed below it. 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??).
278
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:
Explanation Match multiple characters. This pattern does not match a path separator character, such as /. Consequently, a path using this wild card does not recurse through lower directories. Match multiple characters, including path separator characters. Using this wild card allows a path to recurse through lower directories. Match any single character
Wildcard *
** ?
[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:
not exist, and the various count operators.
For a configuration object, only cardinality operators are availableexists, does 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.
Chapter 8
279
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.
The following simple if-then-else conditional construct contains several basic
EXAMPLE
conditions:
if
??TARGET.OS?? = "Windows" then "File:/C/a.log".size does not equal 3 elsif ??TARGET.OS?? = "LINUX" then "File:/C/a.log".size does not equal 4 else "File:/C/a.log".size does not equal 5 end
280
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 following manner: 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 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.
Basic Condition for a basic condition 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 basic condition on page 277 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 element after the else line. button, and then insert one rule
Chapter 8
281
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 Foreach Loop Typical example
foreach "File:/C/temp/*.log" Name starts with "a" end exists "File:/C/temp/*.log" where Name starts with "a" end count "File:/C/temp/*.log" = 5 where Name starts with "a" end
Expression returns TRUE if...
all configuration objects in the specified
group fulfill the conditions defined in the loop body
Exists Loop
at least one configuration object from the specified group fulfills the conditions defined in the loop body the number of configuration objects in the specified group that fulfill the conditions defined in the loop body complies with the count condition in the count loop line
Count Loop
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 following element in the loop line: button, specify the
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:
one of, greater than, or between)
a comparison operator for Integer-type data (such as equals, does not equal, is a constant value or values to which to compare, or, alternatively, a parameterized, Integer-type configuration object property or component property
282
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. Basic Condition for a basic condition If Then End for a conditional construct
C In the displayed fields, define the rule element as discussed in one of the
following sections: To define a basic condition on page 277 To define a conditional construct on page 281 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 after Operand data type Date Expression returns TRUE if... the date property of the LHS operand is chronologically after the date specified by the RHS operand the date property of the LHS operand is chronologically before the date specified by the RHS operand the LHS operand value falls within the range defined by two RHS operands the LHS operand contains the string defined by the RHS operand
before
Date
between
Date Decimal Integer Long Text String
contains
Chapter 8
283
Compliance
Operator contains (case sensitive) count between
Operand data type

Expression returns TRUE if... the LHS operand contains the casesensitive string defined by the RHS operand the number of occurrences of the configuration object falls within the range defined by two RHS operands the number of occurrences of the configuration object specified in the LHS operand does not equal the value defined by the RHS operand the number of occurrences of the configuration object specified in the LHS operand equals the value defined by the RHS operand the number of occurrences of the configuration object specified in the LHS operand is greater than the value defined by the RHS operand the number of occurrences of the configuration object in the LHS operand is greater than or equal to the value defined by the RHS operand the number of occurrences of the configuration object specified in the LHS operand is not one of the values defined by the RHS operand the number of occurrences of the configuration object specified in the LHS operand is one of the values defined by the RHS operand the number of occurrences of the configuration object specified in the LHS operand is less than the value defined by the RHS operand the number of occurrences of the configuration object specified in the LHS operand is less than or equal to the value defined by the RHS operand the LHS operand does not contain the string defined by the RHS operand the LHS operand does not contain the case-sensitive string defined by the RHS operand
Long Text String
not relevant (cardinality condition)
count does not equal
count equals
count greater than not relevant (cardinality condition)
count greater than not relevant (cardinality condition) or equal to
count is not one of not relevant (cardinality condition)
count is one of
count less than
count less than or not relevant (cardinality condition) equal to
does not contain
Long Text String Long Text String
does not contain (case sensitive)
284
Compliance
Operator does not end with
Operand data type

Expression returns TRUE if... the LHS operand does not end with the string defined by the RHS operand the LHS operand does not end with the case-sensitive string defined by the RHS operand the LHS operand does not equal the string or number defined by the RHS operand the LHS operand does not equal the case-sensitive string defined by the RHS operand the configuration object specified in the LHS operand is not present (the number of occurrences equals zero) the LHS operand does not have any flag matching any of the multiple UNIX permissions defined by the RHS operand the LHS operand does not have a flag matching the UNIX permission defined by the RHS operand the LHS operand does not match the string defined by the RHS operand the LHS operand does not match the mask defined by the RHS operand the LHS operand does not start with the string defined by the RHS operand the LHS operand does not start with the case-sensitive string defined by the RHS operand the LHS operand ends with the string defined by the RHS operand the LHS operand ends with the casesensitive string defined by the RHS operand the LHS operand equals the string or number defined by the RHS operand the LHS operand equals the casesensitive string defined by the RHS operand the configuration object specified in the LHS operand is present at least once (the number of occurrences is one or more) 285
does not end with (case sensitive) does not equal
all data types
does not equal (case sensitive) does not exist
Long Text String
does not have any UNIX Permission flag
does not have flag UNIX Permission
does not match does not match mask does not start with does not start with (case sensitive) ends with ends with (case sensitive) equals
Long Text String
FilePermission ACE

Long Text String Long Text String Long Text String Long Text String
all data types
equals (case sensitive) exists
Long Text String
Chapter 8
Compliance
Operator greater than
Operand data type

Expression returns TRUE if... the LHS operand value is greater than the value defined by the RHS operand the LHS operand value is greater than or equal to the value defined by the RHS operand the LHS operand has an ACE mask matching the one defined by the RHS operand the LHS operand does not have a flag matching the UNIX permission defined by the RHS operand the LHS operand has any flag matching the UNIX permission defined by the RHS operand the LHS operand have a flag matching the UNIX permission defined by the RHS operand the LHS operand has no ACE mask matching the one defined by the RHS operand the LHS operand has no flags matching the UNIX permission defined by the RHS operand the LHS operand has only ACE masks matching the ones defined by the RHS operand the LHS operand has an instance of the string defined by the RHS operand the LHS operand is not one of the items defined by the RHS operand the LHS operand is not a substring of the string defined by the RHS operand the LHS operand is not a case sensitive substring of the string defined by the RHS operand the LHS operand is one of the items defined by the RHS operand the LHS operand is a substring of the string defined by the RHS operand
Decimal Integer Decimal Integer FileAudit ACE FilePermission ACE RegistryAudit ACE RegistryPermission ACE
greater than or equal to has ACE matching mask
has all flags
UNIX Permission
has any flag
UNIX Permission
has flag
UNIX Permission
has no ACE matching mask
FileAudit ACE FilePermission ACE RegistryAudit ACE RegistryPermission ACE
has no flags
UNIX Permission
has only ACEs matching masks
FileAudit ACE FilePermission ACE RegistryAudit ACE RegistryPermission ACE
instance of
String
is not one of is not substring of
all data types

is not substring of (case sensitive) is one of is substring of
all data types

Long Text String
286
Compliance
Operator is substring of (case sensitive) less than
Operand data type

Expression returns TRUE if... the LHS operand is a case sensitive substring of the string defined by the RHS operand the LHS operand value is less than the value defined by the RHS operand the LHS operand value is less than or equal to the value defined by the RHS operand the LHS operand matches the string defined by the RHS operand the LHS operand matches the ACE file permission defined by the RHS operand the date property of the LHS operand is chronologically newer than the number of days specified by the RHS operand the LHS operand is not an instance of the string defined by the RHS operand the date property of the LHS operand is chronologically older than the number of days specified by the RHS operand the LHS operand starts with the string defined by the RHS operand the LHS operand starts with the case sensitive string defined by the RHS operand
Long Text String Decimal Integer Decimal Integer Long Text String
less than or equal to matches matches mask
FilePermission ACE
newer than days
Date
not instance of
String
older than days
Date
starts with starts with (case sensitive)
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.
Chapter 8
287
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.

In the bottom pane, the condition is parsed into columns for the left-hand-side (LHS) operand, comparison operator, and right-hand-side (RHS) operand. An additional Success column indicates whether the component satisfied the condition (either true or false). The actual value detected on the target component appears in brackets after the LHS operand so that you can see how it compares to the value in the RHS operand.
NOTE
Cardinality conditions are not parsed in the bottom pane. A basic condition is not parsed if it contains wild cards and was satisfied by the component. If a basic condition is preceded by a NOT logical operator, the Success column in the bottom pane shows a value of true when the condition appears in red in the top pane. Lines that were not analyzed appear in gray in the rule in the top pane. For example: if, then, or else blocks in a conditional construct that were skipped or not reached. In a conditional construct only one then line, or the last else line, may appear in red. All if and elseif lines always appear in black font. In a Foreach loop, details are displayed in the bottom pane only for the non-compliant configuration objects. In a Count loop, details are displayed for all relevant configuration objects (whether compliant or not), but only if the entire loop was non-compliant.
288
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
correct this rule failure. to navigate to the BLPackage you want to deploy to
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).
Chapter 8
289
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.
1 On the content editor, click the Compliance tab. 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.
1 On the content editor, click the Compliance tab. 2 Navigate to the compliance rule or rules you want to copy and paste or cut and
paste.
290
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.
Chapter 8
291
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.
The value of the property is reset to the value it inherits from a built-in property class. The Value Source column shows the property class from which the value is inherited.
292
Local configuration objects
Depending on the type of property you are editing, you can take different actions to set a new value, such as entering an alphanumeric string, choosing from an enumerated list, or selecting a date. To insert a parameter, click Select Property . For more information, see Inserting a parameter on page 142.
6 Click OK.
Local configuration objects

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.
Chapter 8
293
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. Rightclick and select Discover from the pop-up menu.
294
General
The New Component Discovery Job wizard opens.
2 Define the Component Discovery Job, as described in the following sections:

General Component Templates Targets Default Notifications 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 a folder and click OK.
. The Select Folder dialog opens. Use it to select
Chapter 8
295
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
296
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.
Chapter 8
297
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.
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.
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. 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.
298
Schedules
Schedules
Execute job now.
or .
Chapter 8
299
Schedules
Schedule
NOTE
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).
300
Schedules
Select Interval. and do the following: A. For Start At, enter the date and time when the job should first occur. Use a 24hour clock format (00:00 to 23:59) for specifying the time. B. For Repeat Every, enter the interval for subsequent occurrences.

Chapter 8
301
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 Setting values for system object properties on page 140. 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. 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 Component Discovery 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 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 Default Notifications Schedules
302
Adding components to servers manually
These tabs correspond to panels in the New Component Discovery Job wizard. Use them to modify the job definition.
Select the Properties, Permissions, or Audit Trail tab group to see or modify any of the properties, permissions, or audit trail information that apply to this job. For more information, see Properties, Permissions, and Audit Trail tab group on 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.
Chapter 8
303
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 provide descriptive text. and navigate to the component template
2 For Component Template, click Browse
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

component.
and navigate to the server where you want to create this
Properties
The Properties panel shows a list of properties automatically assigned to a 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
The Permissions panel is an access control list granting roles access to this component. 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.
304
Compliance exceptions
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.
Chapter 8
305
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
doing the following: . 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.
306
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 Compliance exceptions 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.
Chapter 8
307
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.

In the bottom pane, the condition is parsed into columns for the left-hand-side (LHS) operand, comparison operator, and right-hand-side (RHS) operand. An additional Result column indicates whether the component satisfied the condition for false). The actual value detected on the target (either for true or 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.
308
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.
Chapter 8
309
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. Rightclick 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.
310
Associated compliance rules
Associated compliance rules

The Associated Compliance Rules panel lets you specify compliance rules that the selected components do not have to satisfy.
1 Click Add Compliance Rule

doing the following:
. 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.
Chapter 8
311
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.
312
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:
Open the Jobs folder and select a job folder. Right-click and select 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, rightclick, 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
Chapter 8
313
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
can optionally provide descriptive text.
2 For Save in, identify the Job folder where you want to store this Compliance Job by
clicking Browse click OK. . The Select Folder dialog opens. Use it to select a folder and
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.
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.
Component templates for filtering
Component templates for filtering

The Component Templates for Filtering panel lets you identify component templates that form the basis of a Compliance Job. Any components based on 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.
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 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.
Chapter 8
315
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.
316
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 autogenerated 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. and navigate to the job group where you want to store any Deploy Jobs (and potentially a Batch Job) that this procedure generates. remediated. This list only displays component templates for which autoremediation has been enabled at the template level. For more information on that procedure, see General on page 261.
4 For Save remediation/deploy job in, click Browse
5 In the Template list, select the component templates that should be automatically
Chapter 8
317
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.
318
Auto-remediation
Property Name
Type of Data
Description Enter a maximum period of time in minutes that the Deploy Job 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_CONNECTION Integer _TIMEOUT
AGENT_QUEUE_WAIT_ Integer TIMEOUT
Enter a maximum period of time in minutes that the Deploy Job 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 MUST_PASS_COMMIT
Enter True to instruct the job to undo the Commit phase for all 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. 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.
COPY_LOCKED_FILES
Boolean
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.
Chapter 8
319
Auto-remediation
Property Name ENABLE_SINGLE_JOB_ MODE
Type of Data Boolean
Description Enter True to instruct the Deploy Job to run in single-job 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_ ON_URL
Boolean
Enter True if a Deploy Job should copy the target of a symbolic 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. Enter True to instruct a server to begin the Commit phase of the 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.
IGNORE_COPY_ON_ BOOT_FILES
Boolean
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. Enter True to instruct the Deploy Job to leave the destination host unchanged should the Commit phase fail. When you set this option to True and the Commit phase fails for any reason, the Deploy Job is automatically rolled back, leaving the destination host unchanged. If you set this option to False and the Commit phase fails, the deployment aborts and does not roll back any transactions that are part of the deployment.
IS_AUTO_ROLLBACK
Boolean
320
Auto-remediation
Property Name
Type of Data
Description Enter True to enable the Commit phase of the Deploy Job. During the Commit phase, packages are applied to target servers. Enter True if any end-of-job reboots specified in REBOOT_OPTIONS should be Solaris reconfiguration reboots. Enter True to enable the Simulate phase of the Deploy Job. The 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). 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.
IS_COMMIT_ENABLED Boolean IS_RECONFIGURE_ REBOOT IS_SIMULATE_ ENABLED Boolean Boolean
IS_STAGING_INDIRECT Boolean
ITEM_RECONFIGURE_ REBOOT_OPTIONS
Enumerated
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 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_ READONLY_FILES
Boolean
Enter True to instruct a server to overwrite read-only files when read-only files are encountered during the Commit phase.
Chapter 8
321
Auto-remediation
Property Name PRESERVE_STAGING_ DIR_ON_FAILURE
Description Enter True to retain data copied to a staging area on a target server even though the Deploy Job fails. By default a Deploy Job deletes the staging directory on a target server when a failure occurs during any phase of the job. Preserving a staging area can potentially leave large files on a target directory after a job failure.
REBOOT_OPTIONS
Enumerated
Specify reboot behavior by choosing one of the following:
Use item defined reboot settingCauses a target to reboot after an object in the BLPackage is processed if the instructions for that object call for a reboot. If the reboot setting for an object is By end of job, and a reboot is not scheduled for this job, then a reboot occurs at the end of the job. Ignore item defined reboot settingPrevents a server from rebooting no matter how a package is defined unless the object being deployed includes an out-of-band reboot (that is, a reboot that is built into the object and is not part of the BLPackage instructions). Use item defined reboot settings and reboot at end of job Causes a target to reboot after each object in the BLPackage is processed if the instructions for that object call for a reboot. In addition, at the end of the job a final reboot occurs if the last item in the job is not defined to reboot. If the last item is defined to reboot, only one final reboot occurs at the end of the job. Ignore item defined reboot settings and reboot at end of 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-ofband 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.
322
Auto-remediation
Property Name REGISTER_COM_ COMPONENTS
Description Enter True to register 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.
RESET_JOB_ON_ FAILURE
Boolean
Setting this option to True allows a job to be run again even 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_ OPTIONS_UNIX_ONLY
Enumerated
Specify user mode behavior (only applicable to UNIX-style target 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
Chapter 8
323
Default notifications
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.
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. 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. 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.
324
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.
email.
C To include compliance results in the email, check Append compliance results to 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. should be generated by checking Consistent, Inconsistent, or both.
6 Specify the compliance result statuses that determine whether an SNMP trap
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.
Chapter 8
325
Schedules
Schedules
Execute job now.
or .
information: Schedule Scheduled job notifications
Schedule
Schedules
NOTE
Chapter 8
327
Schedules
Scheduled job notifications

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. 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 configurations, or both. 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.
4 To send email based on results of the Compliance Job, do the following:
328
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.
email.
C To include compliance results in the email, check Append compliance results to 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. should be generated by checking Consistent, Inconsistent, or both.
6 Specify the compliance result statuses that determine whether an SNMP trap
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.
Properties
The Properties panel shows a list of properties automatically assigned to a Compliance 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 a Compliance 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. 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.
Chapter 8
329
Permissions
Permissions
The Permissions panel is an access control list granting roles access to this Compliance Job. 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.
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 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 for filtering Components Auto-remediation Default notifications Schedules These tabs correspond to panels in the New Compliance Job wizard. Use them to modify the job definition.
Select the Properties, Permissions, or Audit Trail tab group to see or modify any of properties, permissions, or audit trail information that apply to this job. For more information, see Properties, Permissions, and Audit Trail tab group on page 98.
330
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:

Viewing and using auto-remediation results 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).
Chapter 8
331
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 BladeLogic Server Automation Administration Guide.
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.
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.
EXAMPLE
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.
332
Viewing compliance results by server
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.
Viewing compliance results by server

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.
Chapter 8
333
Viewing the results of a compliance rule

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.

In the bottom pane, the condition is parsed into columns for the left-hand-side (LHS) operand, comparison operator, and right-hand-side (RHS) operand. An additional Success column indicates whether the component satisfied the condition (either true or false). The actual value detected on the target component appears in brackets after the LHS operand so that you can see how it compares to the value in the RHS operand.
334
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. 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 Compliance Exception dialog opens. . The View
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
permissions.
. A details window opens. It provides a list of applicable
B Select a name in the Access Control List, and then click View ACL Details C Click Close and then click Close again to close both detail windows.
. Another detail window shows permissions granted to the name you selected.
Chapter 8
335
Editing a compliance rule
Editing a compliance rule

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.
336
Defining exceptions for components
Defining exceptions for components

In some situations it is useful to define one or more components as exceptions to certain compliance rules. For example, a Compliance Job may identify a particular component that does not satisfy compliance rules for a component template but you are certain that the component should be allowed in this context. For example, you may know that the server will soon be modified so that it satisfies the compliance rule in the future. 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. Component dialog opens, and the Compliance Exceptions tab is automatically selected.
3 Right-click the component and select Exceptions from the pop-up menu. The Edit
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.
Chapter 8
337
Viewing and using auto-remediation results
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.
Viewing and using auto-remediation results

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, rightclicking, and selecting Retry. The job immediately runs the phase of the job that did not complete previously.
338
Undoing auto-remediation
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.
Undoing auto-remediation
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.
Chapter 8
339
Manually remediating compliance results

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 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.
340
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.
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.
NOTE
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.
and navigate to the depot folder where you want to store the BLPackage generated by this procedure. where you want to store any Deploy Jobs (and potentially a Batch Job) that this procedure generates.
6 For Save remediation/deploy job in, click Browse and navigate to the job group
Chapter 8
341
Creating a remediation package
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.
Creating a remediation package

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).
342
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 properties are renamed and all references to each renamed property are updated.
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.
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.
NOTE
4 For Package name, enter a name for the BLPackage created for remediation. 5 For Save package in, click Browse 6 Click OK.
BMC BladeLogic creates a remediation package for the targeted component and stores it in the Depot. and navigate to the depot folder where you want to store the remediation package generated by this procedure.
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. displays.
3 Right-click and select Export Compliance Results. The Export Results dialog 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:
344
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. 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.
Analysis version (CSV format)Save results in a comma-separated value format
5 From File encoding, select the type of character encoding that should be used for
the exported data, such as UTF8 or UTF16.
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.
Chapter 8
345
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: define the path to the two Oracle instances. The property should be called ORACLE_PATH.
A In the component template definition, create a local property that can be used to
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.
346
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: appropriate listening port. This port can be anything other than port 1521. BLPackage.
A Identify a version of the listener.ora configuration file that contains the B Add this version of the listener.ora configuration file to the Depot as a 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.
Chapter 8
347
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.
348
Chapter
Creating packages and other depot objects

9
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.
Chapter 9
349
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.
350
Overview of BLPackages
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 Files and directories 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
Chapter 9
351
For UNIX-style systems, a BLPackage can include the following: AIX packages and patches Configuration files Files and directories 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.
352
Adding software to the Depot
Adding software to the Depot

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 Windows Supported Software Types

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 RPMs Packages Patches Products Patches Bundles
Linux AIX HP-UX
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.
Chapter 9
353
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 information on the dialog and background operations, see Running operations in the background on page 67.
Add Software
The Add Software panel lets you choose the software items you want to package. You can specify multiple software items, if necessary.
354
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).
Chapter 9
355
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.
356
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.
Chapter 9
357
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.
358
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
Chapter 9 Creating packages and other depot objects 359
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 ??DEPLOYPATH?? Description of Use The path to a sub-directory in a staging directory on a target server. The subdirectory is named for the package being deployed. The sub-directory contains files used for deployments and rollbacks. The response file used by the installable. The admin file used by the installable. The deploy path followed by the name of the installable. The name of the installable. An identifier used in the uninstall command. The directory holding the software in the package being deployed. 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. Applies to: Typically used with support files but can be used with any type of file required for deployments or rollbacks.
??INSTALL_RESPONSEFILE?? ??INSTALL_ADMINFILE?? ??PACKAGEFILE?? ??PACKAGENAME?? ??PATCHID?? ??SOURCE??
InstallShield packages Solaris packages Solaris packages HP-UX products HP-UX patches RPMs Solaris patches OS service packs InstallShield packages MSI packages Solaris patches Solaris patch clusters RPMs AIX patches AIX packages Custom software Solaris packages
??SOURCEORPARENTDIR??
The source file being deployed if the 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 The subpatches you want to install or uninstall. The admin file used to uninstall the installable. AIX patches HP-UX patches HP-UX bundles Solaris packages InstallShield packages
??SUBPATCHES??
??UNINSTALL_ADMINFILE??
??UNINSTALL_RESPONSEFILE?? The response file used to uninstall the installable. ??WINDIR??
The environment variable representing OS service packs the Windows directory, such as /c/winnt.
360
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
Chapter 9
361
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).
362
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 properties on page 140. 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.
364
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 controlled through ACLs. For more information on defining an ACL, see Defining permissions for a system object on page 186.
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.
Using the Depot folder, right-click the depot folder where you want to add the software package. From the pop-up menu, select New => Software => Hotfix.
Chapter 9
365
Add Software
Using the Servers folder, right-click a server and select Browse from the pop-up menu, which display the Live node in a tab in the content editor. Using the Hotfixes server object type, select one or more hotfixes and right-click. From the pop-up menu, select Add To Depot As => Hotfix. Using the results of a Snapshot Job, select the hotfixes that should be added to the Depot, 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 information on the dialog and background operations, see Running operations in the background on page 67.
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.
366
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:
Chapter 9
367
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.
368
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. the following:
4 In the left pane, select a hotfix for which you want to provide information and do 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.
Chapter 9
369
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. source file for the patch, do the following:
D If you are adding a patch to the Depot and you have manually specified the
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.
370
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 ??HOTFIXNAME?? ??SOURCE?? Description of Use The name assigned to the patch or service pack. 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.
Chapter 9
371
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 Dictionary (see Using the Property Dictionary on page 118). These properties are 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 controlled through ACLs. For more information on defining an ACL, see Defining permissions for a system object on page 186.
Modifying a software package

Use this procedure to modify a software package or hotfix that you have already added to the Depot.
372
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)
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 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.
Chapter 9
373
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
374
Adding a BLPackage to the Depot
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.
Adding a BLPackage to the Depot

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.
Using the Depot folder, right-click the depot folder where you want to add the BLPackage. From the pop-up menu, select New => BLPackage. Using the Servers folder, right-click a server and select Browse from the pop-up menu, which displays the Live node in the content editor. Select one or more server objects and right-click. From the pop-up menu, select Add To Depot As => BLPackage.
Chapter 9
375
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
save the BLPackage. and navigate to the depot folder where you want to
376
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.
Chapter 9
377
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. Includes/Excludes section.
5 To recursively select all subfolders in a folder, select Recurse subfolders in the 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.
378
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: 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:
? []
Chapter 9
379
Package Contents
Matching Pattern *.html ??? foo.[ch] *.[a-z]
Explanation Match server objects ending in .html in the current directory Match server objects that contain exactly three characters Match a server object called foo.c or foo.h Match all server objects in the current directory that have a one-letter lowercase extension Match server objects called web Match server objects called either Web or web
web [Ww]eb
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 not 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.
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:
Click Add New Include/Exclude . The New 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. Include a leading slash when specifying the server object. For example, enter /autoconf instead of autoconf. If necessary, use wild cards in the path. 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 .
380
Package Options
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.
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.
Chapter 9
381
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
The Properties panel shows a list of properties automatically assigned to a BLPackage, as determined by the BLPackage 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 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 for system object properties on page 140. 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 through ACLs. For more information on defining an ACL, see Defining permissions for a system object on page 186.
382
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.
Chapter 9
383
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.
384
Opening a BLPackage to edit
When editing a BLPackage, you can perform any of the following procedures:

Opening a BLPackage to edit 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
Opening a BLPackage to edit

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.
Changing object attributes in a BLPackage

Use this procedure to change the attributes of an object in a BLPackage.
Chapter 9
385
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).
386
The Permissions property of UNIX-style files lets you click Browse a dialog where you can edit the files permissions.
to display
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 networkbased 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.
388
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:
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.
Single-user mode without reboot/shutdownInstructs a Deploy Job to process this
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. the object being deployed. The Deploy Job continues to run under its current mode. This is the default value.
Not requiredInstructs a Deploy Job that single-user mode is not required for
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.
Chapter 9
389
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.
390
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 networkbased software package should be deployed to a target server.
Chapter 9
391
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.
392
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 Multiple Full or Empty Value Values Value is provided Single
Action Add or Modify
Replace Yes or No For keys that can only have one value, the Replace option is ignored.
Deployment Replaces the single value currently in the file with the value passed in.
Rollback Writes an Add or Modify (depending on the original command) using the original single value. On rollback, that value replaces the new value. Writes an Add or Modify (depending on the original command) using the original single value. On rollback, that value replaces the blank entry.
Add or Modify
Yes or No For keys that can only have one value, the Replace option is ignored.
Empty value Single
Replaces the single value currently in the file with a blank value. This action effectively performs a delete. It is useful when you need to empty a value, and you do not know how that value is set on all targets.
Chapter 9
393
Action Add or Modify
Replace No
Single or Multiple Full or Empty Value Values Values are provided Multiple
Deployment Adds new entries to the list of possible values. However, if an entry being added already exists in the targets Value list, that entry is skipped and the rest of the entry values are processed. No action occurs.
Rollback Writes a Delete command to remove only those entries that did not exist before the command was run.
Add or Modify
No
Empty value Multiple
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. Writes an Add or Modify (depending on the original command) using the original list of values. On rollback, those value replace the new values. Writes an Add or Modify (depending on the original command) using the original list of values. On rollback, those values replace the blank entry.
Add or Modify
Yes
Values are provided
Multiple
Replaces the existing list of multiple values with new values that are passed in.
Add or Modify
Yes
Replaces the existing list of multiple values with a blank entry. This action effectively deletes all entries. It is useful when you need to empty a value and you do not know how that value is set on all targets. If the target is set to a value, this action deletes that value and renders the entry blank.
Delete
Yes or No The Replace setting is ignored for all Delete commands.
Value is provided
Single
Writes an Add command to change the deleted value back to its original setting.
394
Action Delete
Replace Yes or No The Replace setting is ignored for all Delete commands.
Single or Multiple Full or Empty Value Values Empty value Single
Deployment No action occurs.
Rollback Writes a Delete command for the single empty value, which essentially results in no action.
Delete
Values are provided
Multiple
If the target has entries in a value list, this action removes those entries.
Writes an Add command that adds only those values that were deleted from original list.
Delete
No action occurs
Writes a Delete command for a list with multiple empty values, which essentially results in no action.
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.
Chapter 9
395
Adding a local property to a BLPackage
For OwnerOption, select Apply to apply the owner attributes of this file during deployment or rollback. Select Ignore to ignore the owner attributes of this file. For GroupOption, select Apply to apply the group attributes of this file during deployment or rollback. Select Ignore to ignore the group attributes of this file. This option only applies to UNIX file deployments. For PermissionsOption, select Apply to apply this files permissions during deployment or rollback. Select Ignore to ignore this files permissions.
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.
Adding a local property to a BLPackage

When editing a BLPackage, you can assign local properties directly to the package. These properties only apply to the BLPackage; they are not available globally like properties created in the Property Dictionary. 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
396
Moving an object within a BLPackage
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.
Moving an object within a BLPackage

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.
Deleting an object in a BLPackage
1 In the hierarchy view, select the BLPackage or any software package included in
the BLPackage.
2 Right-click and select Order by Dependencies from the pop-up menu.

All software packages in the BLPackage are ordered according to their dependencies.
Deleting an object in a BLPackage

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.
398
Finding and replacing text in a BLPackage
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.
Finding and replacing text in a BLPackage

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:
Chapter 9
399
Finding and replacing text in a BLPackage Case sensitiveSearches for text that matches the case of the text string you have
entered.
(?) 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.
Pattern match (? & *)Searches for text using wild card input. A question mark
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.
400
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.
Chapter 9
401
Importing assets into a BLPackage
Importing assets into a 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
RPM Group from the pop-up menu.
is, they should all be installed or uninstalled together), right-click, and select Create
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.
402
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 popup 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 from the pop-up menu.
Chapter 9
403
Verifying assets in a BLPackage
Verifying assets in a BLPackage

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
3 Click Finish to close the wizard and save your changes.
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
optionally provide descriptive text. clicking Browse
2 For Save in, specify a location in the Depot where the script should be stored by
OK.
. The Select Folder dialog opens. Choose a depot folder and click
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. such as UTF8 or UTF16.
4 From File encoding, select the type of character encoding that is used for the script, 5 Under Script Type, select one of the following:
Execute the script separately against each hostThe script executes repeatedly, runscript program, which can run the same command on multiple machines.
each time running on a different server. This option uses the Network Shell
Chapter 9
405
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 Automation Administration Guide.
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.
406
Parameters
1 Display the Add Parameter dialog by clicking Add Parameter

The Add Parameter dialog displays.
or selecting a parameter in the Script Parameters list and then clicking Update Parameter .
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.
Chapter 9
407
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
The Permissions panel is an access control list granting roles access to this system 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 defining an ACL, see Defining permissions for a system object on page 186.
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.
408
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. 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 Network Shell script. For more information, see Properties, Permissions, and Audit Trail tab group on page 98.
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.
Chapter 9
409
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
3 Click Finish to close the wizard and save your changes.
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. 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.
2 For Name, enter a name for the file if a name is not already displayed in this field or
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.
410
Permissions
Permissions
The Permissions panel is an access control list granting roles access to this system object (in this case, a file). 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.
Chapter 9
411
Permissions
412
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 Compliance Jobs on page 312. 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.
Chapter 10 Managing jobs 413
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 templates, BLPackages, and server object-based Snapshot and Audit Jobsso they 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
414
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
Chapter 10
Managing jobs
415
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 Property Dictionary on page 118.
416
Managing jobs from the Jobs or Servers folder
Managing jobs from the Jobs or Servers folder

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.
Chapter 10
Managing jobs
417
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.
418
Executing a job against failed targets
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 a server group to select all servers within the group. Click one or more servers, if necessary expanding server groups.
Click By Name at the bottom of the window. The left panel lists servers by name in a 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.
Chapter 10
Managing jobs
419
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. Using the Servers folder, right-click a server and select Browse. Then select the Audit Results or Snapshot Results tab to navigate to a job.
2 Right-click a failed job run and select Execute Against Failed Targets. NOTE
As a preferred alternative to 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:
occurred.

All FailuresRuns the job on all servers where errors or warnings have 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.
420
Defining a job execution override for a role and user
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).
Defining a job execution override for a role and user

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
Chapter 10
Managing jobs
421
Executing a job with BMC Remedy ITSM approval
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 Server Automation Administration Guide. You can specify an approval type when you execute a job or schedule a job for execution, as shown in the following table.
422
Action Executing a job by
Result
selecting the Execute Now checkbox in the job creation wizard. right-clicking an existing job and selecting Execute. execute a job against failed targets using an execution task
If BMC Remedy ITSM approval is not required, the job executes immediately. If BMC Remedy ITSM approval is required, the Enter approval information dialog is displayed. See Setting the approval type on page 423.
When you add a schedule:

by using a wizard to create a new job by editing an existing job
If BMC Remedy ITSM approval is not required, the job executes according to the schedule. 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.
Chapter 10
Managing jobs
423
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 Manual approval Use when Use this option for jobs that require a BMC Remedy ITSM administrator to review the job details and impact level prior to approving execution. By default, this option generates a change request with a Change Timing value of Normal and an Urgency value of Medium. Note: Approving a job may take some time. The administrator that approves the job may not be available for some time (on manual approval), so submit the approval request as early as possible. Automatic approval Use this option for change requests that use an Approval Process Configuration form to automatically approve the request. By default, this option generates a change request with a Change Timing value of No impact and an Urgency value of Medium. Emergency approval Use this option for jobs that need immediate attention and must be run immediately. By default, this option generates a change request with a Change Timing value of Emergency and an Urgency value of High. No approval If you select No approval, you are not required to enter the additional BMC Remedy ITSM parameters. If a job type requires approval and you select No approval, the approval mechanism is bypassed and the job executes either immediately (Execute now) or as scheduled. This option enables users with the authorization to select No approval to bypass the approval process for special circumstances.
The Job Approval type defines what values must be populated in the change request by the BMC Remedy ITSM user.
2 Enter the additional information that is used in the change request.

Field Change type Comments Impact Enter Enter the type of change being requested. The default value is Change. Enter any additional comments that would be helpful to the BMC Remedy ITSM user approving the request. 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.
424

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.
Chapter 10
Managing jobs
425
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. 3 Click the Schedule tab.
The job schedule log makes it easy to see:
when the job has been approved and is waiting to run if the attempt to schedule the job has failed (for example, failed to create or update the change ticket)
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
426
Managing jobs in progress
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.
Managing jobs in progress

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.
Chapter 10
Managing jobs
427
Managing jobs in progress 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 in Progress view tab and choose Close. on the tab or right-click the Task
428
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.
Chapter 10
Managing jobs
429
Creating and defining an Execution Task manually
NOTE
To create an Execution Task, you must have, at minimum, the ExecutionTask.Create 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
To create an Execution Task, you must have, at minimum, the ExecutionTask.Create 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.
430
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 by selecting it and clicking Edit Schedule . or modify an existing 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 Scheduled Job Notifications Schedule Servers
Delete an existing schedule by selecting it in the list and clicking Remove Schedule .
Chapter 10
Managing jobs
431
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 Setting values for system object properties on page 140.
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 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
432

Chapter 10
Managing jobs
433
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.
434
Modifying Execution Task definitions
Modifying Execution Task definitions

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. to save your revisions to the Execution Task.
2 Click Save
Chapter 10
Managing jobs
435
Executing a job through an Execution Task
Executing a job through an Execution Task

When you execute an Execution Task, you are actually executing the job with which the Execution Task is associated at the target servers defined through the Execution Task. 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.
Viewing job run information through an Execution Task

The Execution Task concentrates information about the relevant job runs as they progress towards the successful completion of the job on all target servers. To view information for the Execution Task and all its job runs, 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.
436
Viewing job run information through an Execution Task
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.
Chapter 10 Managing jobs 437
Viewing history for a job
Viewing history for a job

Use this procedure to view history for a job:

Using the Jobs folder, navigate to a job, right-click it, and select Show Results. Using the Servers folder, right-click a server and select Browse. Then select the Audit Results or Snapshot Results tab to navigate to 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.
438
Viewing the status of a job
3 If necessary, sort jobs in ascending or descending order by clicking on the header

for any column of information in the content editor.
Viewing the status of a job

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.
Chapter 10
Managing jobs
439
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 Waiting for approval Description The job has been submitted for approval in BMC Remedy ITSM, and execution is blocked pending approval notification. The change request has been approved in BMC Remedy ITSM, and job execution is pending according to the job schedule.
Request approved - Waiting for 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.
440
Viewing the job definition of a job run
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.
Viewing the job definition of a job run

Use this procedure to display the definition of a job that has been run. All data displayed in a job definition is read-only.
Using the Servers folder, right-click a server and select Browse. Then select the Audit Results or Snapshot Results tab to navigate to a job. Expand the job to display the job runs. Using the Servers folder, right-click a server and select Browse. Then select the 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.
Chapter 10
Managing jobs
441
Exporting job logs
Using the Servers folder, right-click a server and select Browse. Then select the Activity tab to display the job runs (see Viewing job activity on page 438). Using the Servers folder, right-click a server and select Browse. Then select the Audit Results or Snapshot Results tab to navigate to a job. Expand the job to display the job runs. Open the Jobs folder, navigate to a job, 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 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. the left.
4 To display messages pertaining to a specific server, select that server in the list on
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.
Using the Servers folder, right-click a server and select Browse. Then select the Activity tab to display the job runs (see Viewing job activity on page 438). Using the Servers folder, right-click a server and select Browse. Then select the Audit Results or Snapshot Results tab to navigate to a job. Expand the job to display the job runs.
442
Viewing job schedules
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 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
Chapter 10
Managing jobs
443
Defining time-outs for jobs

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. 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 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.
444
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 Automation Administration Guide.
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 Automation Administration Guide.
Chapter 10
Managing jobs
445
Updating server status before running a job

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 properties on page 140.
Run the update-server-agent-status.nsh script by doing the following:
446
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 10
Managing jobs
447
448
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-byside 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.
Chapter 11
Snapshot Jobs
449
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.
450
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 .NET Global Assemblies applications, packages, patches, RPMs, bundles, and products COM+/MTS components Location Saved database database database; values longer than 255 characters are stored in the file server server objects that constitute the component are stored in the location appropriate for that server object database database database database file attributes are stored in the database; file content is stored in the file server database database database database database; values longer than 255 characters are stored in the file server database database; values longer than 255 characters are stored in the file server database database database database database
configuration files daemons event logs extended object file system hardware information hotfixes local groups local users metabase processes registry security settings services system info UNIX groups UNIX users
Chapter 11
Snapshot Jobs
451
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. Open the Jobs folder and select a job folder. Right-click and select 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 Default Notifications 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.
452
General
1 For Name, enter an identifying name for the Snapshot Job. For Description, you can
optionally provide descriptive text. clicking Browse click OK.
2 For Save in, identify the job folder where you want to store this Snapshot Job by
3 Under Select Snapshot Job Type, select one of the following:
the Snapshot Job. The snapshot records information for all components (specified using templates) which are discovered on the target servers you specify.
Snapshot componentsChoose the component templates that form the basis of
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.
Chapter 11
Snapshot Jobs
453
Components Templates for Filtering
Components Templates for Filtering

The Component Templates for Filtering panel lets you identify the component templates that form the basis of a snapshot. Any components based on that template that 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 Selected Templates list in the right panel.
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 Includes and Excludes 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, even though that version of the object may not be included in your Configuration Object Dictionary.
1 Using the Server Objects list, add a new server object by clicking Add
an existing server object by selecting it and clicking Update Objects window opens.
or modify . The Select Server
To delete an existing server object, select it in the Server Objects list and click Delete .
454
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.
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 you want. To add a server object without searching through the tree on the left, click Add New , 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. Selecting this option instructs the system to include all folders subordinate to the 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: Files and directories COM+ Metabase Registry
Chapter 11
Snapshot Jobs
455
Server Objects
You can include or exclude server objects by name, and you can define matching patterns to identify multiple server objects to include or exclude. Matching patterns are based on wild cards, as described below:
? []

Matching Pattern *.html ??? foo.[ch] *.[a-z] Explanation Match server objects ending in .html in the current directory Match server objects that contain exactly three characters Match a server object called foo.c or foo.h Match all server objects in the current directory that have a one-letter lowercase extension Match server objects called web Match server objects called either Web or web
web [Ww]eb
456
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:
Click Add New Include/Exclude . The New 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. Include a leading slash when specifying the server object. For example, enter /autoconf instead of autoconf. If necessary, use wild cards in the path. 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.
Snapshot/Audit Options
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.
Chapter 11
Snapshot Jobs
457
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 circumstances trigger an audit, identifies a group or user to monitor, and lists operations to audit.
Checksum - Calculate and store a unique key based on all the data in each file.
By storing full MD5 checksums, you can compare entire files and detect changes that occur anywhere in a file. Note that computing full checksums requires significant processing.
Contents - Store a copy of the physical file on the file server when taking a snapshot. If a snapshot includes a symbolic link to a file, the link must point to a valid file or the snapshot will fail. If you are planning to use a snapshot as the basis of an audit and then synchronize files using the results of that audit, you must check this option. 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.
458
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 component templates.
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. 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.
Chapter 11
Snapshot Jobs
459
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. trap should be generated. You can select a status indicating changes occurred, did not occur, or both.
B For When results are, check the job statuses that determine whether an SNMP
460
Schedules
Schedules
Execute job now.
or .
4 When you finish entering information 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.
Chapter 11
Snapshot Jobs
461
Schedules
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
462
Schedules

The Scheduled Job Notifications tab lets you generate emails and SNMP traps when a scheduled job completes. Any notifications defined here override default job notifications. The Scheduled Job Notifications tab also lets you send email messages and generate SNMP traps when any change to a snapshot occurs. This capability provides a simple mechanism for tracking configuration changes. Note that the first time a Snapshot Job runs, no changes are detected because the first run establishes a baseline against which future changes are tracked. 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.
4 To send email notifications when any changes to the snapshot occur, under
Chapter 11
Snapshot Jobs
463
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. trap should be generated. You can select a status indicating changes occurred, did not occur, or both.
B For When results are, check the job statuses that determine whether an SNMP
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 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 a Snapshot 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). One common use for job properties is to assign time-out properties.
464
Permissions
Permissions
The Permissions panel is an access control list granting roles access to this Snapshot 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 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 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 Components Templates for Filtering Server Objects Targets Default Notifications Schedules These tabs correspond to panels in the New Snapshot Job wizard. Use them to modify the job definition. If you open a server object-based Snapshot Job that includes a custom configuration object and a more recent version of that object exists, a tab called Version Warnings 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.
Chapter 11
Snapshot Jobs
465
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.
466
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.
Chapter 11
Snapshot Jobs
467
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:
Out All External Changes. 468 BMC BladeLogic User Guide
At the server level, right-click the server and select Back Out All Changes or Back
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:
Chapter 11 Snapshot Jobs 469
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
store the BLPackage. and navigate to the depot group where you want to
Package Options
Package Options panel lets you make choices about how to create a BLPackage.
470
Adding software to the depot from snapshot results
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. 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).
2 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.
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
Chapter 11 Snapshot Jobs 471
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.
472
Exporting the results of an audit or snapshot 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. the exported data, such as UTF8 or UTF16.
5 From File encoding, select the type of character encoding that should be used for 6 On the Export Results dialog, click Save.
Chapter 11
Snapshot Jobs
473
474
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.
Chapter 12
Audit Jobs
475
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 Default Notifications 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.
476
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
optionally provide descriptive text. clicking Browse click OK.
2 For Save in, identify the Job folder where you want to store this Audit Job by
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).
Chapter 12
Audit Jobs
477
Component Templates for Filtering
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 Selected Templates list in the right panel.
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.
478
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 Includes and Excludes Snapshot/Audit Options
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, even though that version of the object may not be included in your Configuration Object Dictionary.
1 Using the Server Objects list, add a new server object by clicking Add
an existing server object by selecting it and clicking Update Objects window opens.
or modify . The Select Server .
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.
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 you want.
Chapter 12
Audit Jobs
479
Server Objects
To add a server object without searching through the tree on the left, click Add New , 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. Selecting this option instructs the system to include all folders subordinate to the 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: 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 zerolength strings. This pattern does not match a separator character in a path, such as /.
480
Server Objects
Wildcard ? []
Explanation 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].

Matching Pattern *.html ??? foo.[ch] *.[a-z] Explanation Match server objects ending in .html in the current directory Match server objects that contain exactly three characters Match a server object called foo.c or foo.h Match all server objects in the current directory that have a one-letter lowercase extension Match server objects called web Match server objects called either Web or web
web [Ww]eb
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:
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.
Chapter 12
Audit Jobs
481
Server Objects
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.
Snapshot/Audit Options
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.
Account Disabled - Compare the status of user accounts. ACL Owner - Compare the owner of a file or registry key.
482
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 circumstances trigger an audit, identifies a group or user to monitor, and lists operations to audit.
Checksum - Calculate a unique key (an MD5 checksum) based on all the data in a
file and use that key to compare entire files and detect changes that occur anywhere in a file. Computing full checksums requires significant processing.
Code Page - Compare users language of choice. Contents - Compare file content when performing an audit based on a snapshot of file content. Effective Setting as String Value - Compare the effective value of security settings. Full Name - Compare users full names. Group members - Compare the groups belonging to a Local Group. Group owner - Compare a files group ID. Home Directory Drive - Compare the home directories of user accounts. Home Path - Compare the home paths of user accounts. Inherit Auditing ACL - Compare whether an object inherits access control entries in the System Access Control List (SACL) from its parent object. Inherit Permission ACL - Compare whether an object inherits access control entries in the Discretionary Access Control List (DACL) from its parent object. Light Checksum - Calculate a unique key based on the first 512 bytes of a file (a light MD5 checksum) and then use the light checksum to compare header information in files without expending the processing necessary for calculating full checksums. Light checksums are useful for binary files; they are not recommended for text files. Local Setting as String Value - Compare the value of security settings defined for
each server.
Login Script - Compare the login script for user accounts. Logon Server - Compare users logon server. Max Size - Compare the maximum size of event logs.
Chapter 12
Audit Jobs
483
Targets Member of - Compare the groups to which users belong. Permission ACL - Compare access control entries in the Discretionary Access Control List (DACL) for a file or registry key. Each DACL access control entry specifies whether access is granted, identifies a group or user granted or denied access, and lists actions permitted or denied. Permissions - Compare the permissions assigned to files. Privilege Level - Compare the privilege level for user accounts. Profile Path - Compare user profile paths. Retention - Compare the amount of time event logs are kept. Size - Compare the sizes of files. User Expire Date - Compare the dates when user accounts expire. User members - Compare the users belonging to a Local Group. User owner - Compare a files user ID. Version - Compare file version information for DLL, EXE, and other types of
files.
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.
484
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.
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. 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. 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.
Chapter 12
Audit Jobs
485
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. by checking Consistent, Inconsistent, or both.
B For When results are, specify the type of audit results that should trigger an email 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
to the right.
Limit email body size to and then enter the maximum, in kilobytes, in the text box
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. generated by checking Consistent, Inconsistent, or both.
6 Specify the audit result status that determines whether an SNMP trap should be
For example, if you select Inconsistent and an audit indicates that two server object types 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 trap.
486
Schedules
Schedules
Execute job now.
2 Using the Schedules list, add a new schedule by clicking Add

existing schedule by selecting it and clicking Update window opens.
, or modify an . The Add New Schedule .
To delete an existing schedule, select it in the list and click Delete categories of information:
Schedule Scheduled Job Notifications
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
Chapter 12
Audit Jobs
487
Schedules
NOTE
488
Schedules

The Scheduled Job Notifications tab lets you generate email and SNMP traps when a 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 configurations, or both. 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 Default Notifications tab. To send email notifications, under Job Run
Notifications, do the following:
4 To send email based on audit results, do the following:
Chapter 12
Audit Jobs
489
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. by checking Consistent, Inconsistent, or both.
B For When results are, specify the type of audit results that should trigger an email 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
to the right.
Limit email body size to and then enter the maximum, in kilobytes, in the text box
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. generated by checking Consistent, Inconsistent, or both.
6 Specify the audit result status that determines whether an SNMP trap should be
For example, if you select Inconsistent and an audit indicates that two server object types 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 trap.
Properties
The Properties panel shows a list of properties automatically assigned to an Audit 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 Audit Job is determined by the Job builtin 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. One common use for job properties is to assign time-out properties.
490
Permissions
Permissions
The Permissions panel is an access control list granting roles access to this Audit 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 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 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 for Filtering Masters Server Objects Targets Default Notifications Schedule These tabs correspond to panels in the New Audit Job wizard. Use them to modify the job definition. If you open a server object-based Audit Job that includes a custom configuration object and a more recent version of that object exists, a tab called Version Warnings 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.
Chapter 12 Audit Jobs 491
Viewing audit results
Viewing audit results

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.)
492
Viewing audit results by object
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:
Chapter 12
Audit Jobs
493
Column Name Compliant Non-compliant Failed
Description The name of the audit job and the master server. The total number of servers that are consistent with the master. The total number of servers that are inconsistent with the master. The total number of objects for which the attempt to evaluate consistency failed on at least one target. The total number of objects for which consistent evaluation was not attempted on at least one target. The total number of objects that have differing characteristics between the master and at least one target. The total number of objects that are not present on the master but are present on at least one target. The total number of objects that are present on the master but are missing on at least one target.
Not Attempted
Changes
Extra
Missing
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 Name # of Consistent Targets # of Inconsistent Targets # of Failed Targets Description The name of the component or Audit Job on which the audit is based. The total number of servers for which this object is consistent with the master. The total number of servers for which this object is inconsistent with the master. The total number of servers for which the attempt to evaluate consistency for this object failed. The total number of servers for which no attempt was made to evaluate the consistency of this object.
# of Not Attempted Targets
494
Viewing audit results by server
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 Name Compliant Non-compliant Failed Not Attempted Changes Extra Missing Description The name of the job and the master server. The number of objects on all targets that are not compliant with the master. The total number of objects that are inconsistent between the master and at least one target. The total number of objects for which the attempt to evaluate consistency failed on at least one target. The total number of objects for which consistent evaluation was not attempted on at least one target. The total number of objects that have differing characteristics between the master and at least one target. The total number of objects that are not present on the master but are present on at least one target. 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.
Chapter 12
Audit Jobs
495
The right panel shows a listing of all the target servers, with columns showing the following server-level summaries:
Column Name Changes Description The name of the job and the master. The total number of objects present on both the master and this target but for which there are some differences in characteristic values. The total number of objects present on this target but not on the master. The total number of objects present on the master but missing on this target.
Extra Missing
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 Name Changes Extra Missing Description The name of the object. If the value is non-zero, the object is present on both the master and target but there are some difference in characteristic values. If the value is non-zero, the object is present on this target but not on the master. 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.
496
Viewing differences between text files
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. any of the following:
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.
Viewing differences between text files

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. differences.
2 Using the Server View, navigate to a node that consists of a file where there are
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.
Chapter 12
Audit Jobs
497
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.
Using audit results to synchronize servers
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.
Chapter 12 Audit Jobs 499
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.
500
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.
and navigate to the depot group where you want to store the BLPackages generated by this procedure. want to store the Deploy Jobs and the Batch Job generated by this procedure.
3 For Save sync/deploy job in, click Browse and navigate to the job group where you
Package Options
The Package Options panel lets you make decisions about how to create a BLPackage.
Copy file contentsCopy the contents of all files included in the BLPackage. Collect access control list (ACL) attributesCollect permission and log
Chapter 12
Audit Jobs
501
Packaging audit results
Packaging audit results

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.
502
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
save the BLPackage. and navigate to the depot group where you want to
Package Options
The Package Options panel lets you make decisions about how to create a BLPackage.
Copy file contentsCopy the contents of all files included in the BLPackage. Collect access control list (ACL) attributesCollect permission and log
Chapter 12
Audit Jobs
503
Package Options
504
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.
Chapter 13
File Deploy Jobs
505
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:
Using the Servers folder, right-click a server and select Browse from the pop-up menu. In the content editor, expand the Live => File System node for a server, and then select the files and directories you want to deploy. Right-click and select Deploy Files from the pop-up menu. The New File Deploy Job wizard opens. Open the Jobs folder and navigate to the job folder where you want to create a File Deploy job. Right-click the job folder and select New => File Deploy Job from the pop-up menu. The New File Deploy Job wizard opens.
2 Provide information for the File Deploy job, as described in the following sections:
General Targets Options
506
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 OK. . The Select Folder dialog opens. Choose a job folder and click
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 directory. and use the Add Source File dialog to provide a path to a file or
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.
Chapter 13
File Deploy Jobs
507
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.
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.
508
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.
Chapter 13 File Deploy Jobs 509
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 subnets. 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.
510
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. during an indirect push:
2 Use any of the following options to define how the copy should be performed
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.
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.
Synchronize push to repeatersCheck to copy only modified files to the repeater
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.
Chapter 13
File Deploy Jobs
511
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.
512
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 precommands 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 postcommands. 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.
Chapter 13
File Deploy Jobs
513
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.
514
Schedules
Schedules
Execute job now.
or .
information:
categories of information:
Chapter 13
File Deploy Jobs
515
Schedules
Schedule
NOTE
516
Schedules
Execute on approval and Approval type settings

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:


Chapter 13
File Deploy Jobs
517
Properties
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 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 a File Deploy 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. One common use for job properties is to assign time-out properties.
518
Permissions
Permissions
The Permissions panel is an access control list granting roles access to this File Deploy 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 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 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 Options Advanced Options Schedules These tabs correspond to panels in the New File Deploy Job wizard. Use them to modify the job definition.
Chapter 13
File Deploy Jobs
519
Modifying File Deploy Jobs
520
Chapter
14
Software and BLPackage Deploy Jobs

14
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.
Chapter 14
521
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
Chapter 14
523
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.
524
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 BladeLogic Server Automation Administration Guide.
Chapter 14
525
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. Using the Servers folder, right-click a server and select Browse from the pop-up menu. In the content editor, expand the Live node for the selected server, and navigate to the software that you want to deploy. Right-click the software and select Deploy from the pop-up menu. The New Deploy Job wizard opens. If software must first be added to the Depot, the Select Matching Software dialog opens.
executable listed in the window to software stored in the Depot. If necessary, you can add software packages to the Depot with this process. For more information, see Matching software with depot items on page 373.
3 Provide information for the Deploy Job, as described in the following sections:
General Software Targets Targets Default Notifications 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.
526
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 Default Notifications Phases and Schedules 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.
Chapter 14
527
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 Automation Administration Guide.
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.
528
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.
Chapter 14
529
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.
530
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. . The Select Depot Object dialog opens. Select a package from a location in the Depot and click OK. value for the property:
5 For Package, choose the package to be deployed by clicking Browse
6 If the BLPackage includes local properties, do one of the following to provide a

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.
Chapter 14
531
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.
532
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: app_configuration.
A Add the configuration file to the Depot as a BLPackage called 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.
Chapter 14
533
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.
534
Targets
1 To change the order in which software packages are deployed, select a package in
the Install Software list. Click Move Up of the selected package. or Move Down to change the position
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.
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. 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 installDirectory/ Share/BladeLogic.mib.
Chapter 14
535
Phases and Schedules

The Phases and Schedules panel lets you choose the deployment phases that should occur during deployment of a software package or BLPackage. It also lets you schedule the execution of a job. 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 WAN saturate a network with data. By staging indirectly, you can segment your network and help spread the load repeater over multiple hosts and sub-nets. If staging directory you are staging through a thin pipe, for example a Wide Area Network (WAN) like the Internet, you may have throughput issues. Staging to repeaters can shift the bulk of a deployment to a much faster local area network.
536
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
Chapter 14
537
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
538
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. This option is not available if you are modifying an existing 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.
below. Then, do the following:
To schedule individual phases of the job, select Execute selected phases as specified
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.
Chapter 14
539
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.


540
Schedule
NOTE
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).
Chapter 14
541
Select Interval. and do the following: A. For Start At, enter the date and time when the job should first occur. Use a 24hour clock format (00:00 to 23:59) for specifying the time. B. For Repeat Every, enter the interval for subsequent occurrences.

542
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 any of the following:
Specify whether the job can execute in parallel on a target with other Deploy Jobs. In some situations you may want a job to execute in single-job mode, meaning no other Deploy Jobs can be processed while this job is executing. Note that when a job starts, it may be placed in a queue of jobs waiting to execute. The job leaves the queue when execution begins. Jobs defined to run in parallel can execute while other parallel jobs are also executing. A job defined to run in singlejob 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 singleuser 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.
Chapter 14
543
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
targets if any targets do not successfully complete the Commit phase.
must pass commit, which instructs the job to undo the Commit phase to all
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.
544
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-ofband reboot, you must define that object within a BLPackage as requiring an out-ofband 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.
Chapter 14
545
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 dropdown 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. user mode no matter how individual objects in the package are defined.
Ignore item defined user mode settingPrevents a server from entering single-
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:
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.
Use item defined reboot settingCauses a target to reboot after an object in the
Ignore item defined reboot settingPrevents a server from rebooting no matter how a package is defined unless the object being deployed includes an out-ofband reboot (that is, a reboot that is built into the object and is not part of the BLPackage instructions).
546
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
reboot for reboot at end of job...
those reboots should be reconfiguration reboots by checking Use configuration
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.
Chapter 14 Software and BLPackage Deploy Jobs 547
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 reconfiguration reboot for reboot at end of job? Reconfigure Reboot Option Selected in Deploy Job
Is Reboot Reboot Option Required for Selected in Item in Package? Deploy Job Yes or No
Description
Use item defined (Not applicable) reboot setting
Use item defined The job reboots reconfigure for each item that setting requires a reboot. If any items require a reconfiguration reboot, those reconfiguration reboots occur. Ignore item defined reconfigure setting The job reboots for each item that requires a reboot. All reboots are normal reboots.
Yes or No
Use item defined (Not applicable) reboot setting
Yes or No
Ignore item defined reboot setting Ignore item defined reboot setting
(Not applicable)
Use item defined No reboots reconfigure occur. setting Ignore item defined reconfigure setting No reboots occur
Yes or Not
(Not applicable)
548
Job Options
Is Reboot Reboot Option Required for Selected in Item in Package? Deploy Job Yes or No
Use reconfiguration reboot for reboot at end of job?
Reconfigure Reboot Option Selected in Deploy Job
Description
Use item defined No reboot setting and reboot at end of job
Use item defined The job reboots reconfigure for each item that setting requires a reboot. In addition, a normal reboot occurs at the end of job unless the last item installed also performs a reboot. Ignore item defined reconfigure setting The job reboots for each item that requires a reboot. 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 No reboot setting and reboot at end of job
Yes or No
Use item defined Yes reboot setting and reboot at end of job
Use item defined The job performs reconfigure all item-level setting reboots, including any reconfiguration reboots. The final reboot at the end of the job is a reconfiguration reboot. Ignore item defined reconfigure setting The job performs all item-level reboots but none of those reboots are reconfiguration reboots. The final reboot at the end of the job is a reconfiguration reboot. 549
Yes or No
Use item defined Yes reboot setting and reboot at end of job
Chapter 14
Job Options
Is Reboot Reboot Option Required for Selected in Item in Package? Deploy Job Yes or No Ignore item defined reboot setting and reboot at end of job
Use reconfiguration reboot for reboot at end of job? No
Reconfigure Reboot Option Selected in Deploy Job
Description
Use item defined The job ignores reconfigure all item-level setting reboots and performs a normal reboot at the end of the job. Ignore item defined reconfigure setting The job ignores all item-level reboots and performs a normal reboot at the end of the job.
Yes or No
Ignore item defined reboot setting and reboot at end of job
No
Yes or No
Yes
Use item defined The job ignores reconfigure all item-level setting reboots and performs a reconfiguration reboot at the end of the job. Ignore item defined reconfigure setting The job ignores all item-level reboots and performs a reconfiguration reboot at the end of the job.
Yes or No
Yes
Yes
Consolidate any Yes or No After item deployment reboots until end of job
Use item defined The job delays all item-level reconfigure reboots until a setting final reboot at the end of the job. If any itemlevel reboots are reconfiguration reboots, the final reboot is a reconfiguration reboot. Ignore item defined reconfigure setting The job delays all item-level reboots until a final, normal reboot at the end of the job.
Yes
Consolidate any No After item deployment reboots until end of job
550
Phase Options
Is Reboot Reboot Option Required for Selected in Item in Package? Deploy Job Yes
Use reconfiguration reboot for reboot at end of job?
Reconfigure Reboot Option Selected in Deploy Job Ignore item defined reconfigure setting
Description The job delays all item-level reboots until a final reconfiguration reboot at the end of the job.
Consolidate any Yes After item deployment reboots until end of job
No
Consolidate any Yes or No After item deployment reboots until end of job Consolidate any Yes or No After item deployment reboots until end of job
Use item defined No reboots reconfigure occur. setting
No
Ignore item defined reconfigure setting
No reboots occur.
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.
552
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. Windows-only Options:
5 If you are deploying to Windows machines, check any of the following under
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 twosecond 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.
Chapter 14
553
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 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.
554
Permissions
The default list of properties assigned to a Deploy Job is determined by the Job builtin 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. 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 timeouts 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 timeouts, 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. For more information on defining an ACL, see Defining permissions for a system object on page 186.
Chapter 14
555
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.
Modifying Deploy Jobs

Use this procedure to modify an existing Deploy Job.
To modify the definition of an existing Deploy Job, open the Jobs folder and navigate to an existing job. Right-click the job and select Open from the pop-up menu. The content editor displays the following tabs: General Package - (BLPackage Deploy Jobs) Software - (Software Deploy Jobs) Targets Default Notifications Phases and Schedules Job Options Phase Options These tabs correspond to panels in the New Deploy Job wizard. Use them to modify the job definition.
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.
556
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.
Chapter 14
557
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 Server Automation Administration Guide. 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 can add software packages to the Depot with this process. For more information, see Matching software with depot items on page 373.
3 Provide information for the uninstall job, as described in the following sections:
General Software Targets Targets Default Notifications Phases and Schedules Job Options Phase Options Properties Permissions
558
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 position of the selected package. or Move Down to change the
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:
Chapter 14
559
Performing actions on a job
Job Status In progress Completed successfully Completed with errors
Icon
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 job Performing actions on a server or phase Undoing a Deploy Job Rebooting servers
Performing actions on a job

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.
560
Performing actions on a server or phase
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.
Execute from the pop-up menu.
To resume a failed job that is in a paused state, right-click a Deploy Job and select
Performing actions on a server or phase

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, rightclicking, and selecting Retry. The job immediately runs the phase of the job that did not complete previously.
Undoing a Deploy Job
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.
Undoing a Deploy Job

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
from the pop-up menu.
2 Select the most recent run of a Deploy Job. 3 Do one of the following:
To undo all committed packages, select the most recent job run and select Undo from the pop-up menu.
562
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.
Chapter 14
563
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 properties on page 140.
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.
564
Using NFS to mount a location while running single-user mode
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.
For details on how to define a property value, see Setting values for system object properties on page 140.

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 singleuser 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. For details on how to define a property value, see Setting values for system object properties on page 140.
Chapter 14
565
566
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.
Chapter 15
567
General
Open the Jobs folder and navigate to the job folder where you want to create a new Network Shell Script Job. Right-click the job folder and select New => NSH Script Job from the pop-up menu.
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. Network Shell Script Job. and navigate to the script that is the basis of this
3 For NSH Script, click Browse
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
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.
Chapter 15
569
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 Inserting a parameter on page 142.
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.
Chapter 15
571
Schedules
Schedules
572
Schedules
Execute job now.
or .
information:
categories of information: Schedule Scheduled Job Notifications
Schedule
NOTE
Chapter 15
573
Schedules

574
Schedules

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:

Chapter 15
575
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 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 a Network Shell Script 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. 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 controlled through ACLs. For more information on defining an ACL, see Defining permissions for a system object on page 186.
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:
576
General Targets Parameters Default Notifications Schedules These tabs correspond to panels in the New Network Shell Script Job wizard. Use them to modify the job definition.
Chapter 15
577
578
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.
Chapter 16
Batch Jobs
579
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. 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.
2 Select the jobs to add to the Batch Job from the tree displayed in the Select Jobs to
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 ACL Push Jobs Modifying Audit Jobs Modifying Compliance Jobs Modifying Component Discovery Jobs Modifying Deploy Jobs Modifying Deregister Configuration Object Jobs Modifying Distribute Configuration Objects Jobs Modifying File Deploy Jobs Modifying Network Shell Script Jobs Modifying Snapshot Jobs Modifying Update Server Properties 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.
580
Batch Job Options
To modify the list of jobs, do any of the following: To delete a job, select the job and click Delete . or Move
To reposition a job in the list, select the job and click Move Up 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.
Chapter 16
Batch Jobs
581
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
optionally provide descriptive text. stored by clicking Browse and click OK.
2 For Save in, specify a location in the Jobs folder where the Batch Job should be
. The Select Folder dialog opens. Choose a job folder
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. targets simultaneously.
Execute jobs in parallelAll the individual jobs in the Batch Job run against all
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.
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.
582
Batch Job Options
For more information on using these options, see Defining a job execution override for a role and user on page 421.
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. . The
7 To specify servers where the Batch Job should execute, click Add Servers
Select Servers/Groups window opens.
10 Click the right arrow to move your selections to the right panel. 11 Click OK to close the Select Servers/Groups window.
Chapter 16
Batch Jobs
583
Permissions
Permissions
The Permissions panel is an access control list granting roles access to this Batch 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 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 properties on page 140. 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 Dictionary to create new properties. For more information, see Using the Property Dictionary on page 118. One common use for job properties is to assign time-out properties.
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.
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.
584
Schedules
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
Chapter 16
Batch Jobs
585
Schedules
Execute job now.
or .
information:
Schedule
NOTE
586
Schedules

Chapter 16
Batch Jobs
587
Schedules


588
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 navigate to an existing job. Right-click the job and select Open from the pop-up menu. The content editor displays the following tabs: Batch Job Options Default Notifications Schedules These tabs correspond to panels in the New Batch Job wizard. Use them to modify the job definition.
To modify the definition of an individual job that is included in the batch, select the job in the left-hand tree and use the tabs on the right to access the information you want to change. For detailed information on modifying a specific job type, refer to the following sections: Modifying ACL Push Jobs Modifying Audit Jobs Modifying Compliance Jobs Modifying Component Discovery Jobs Modifying Deploy Jobs Modifying Deregister Configuration Object Jobs Modifying Distribute Configuration Objects Jobs Modifying File Deploy Jobs Modifying Network Shell Script Jobs Modifying Snapshot Jobs Modifying Update Server Properties 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.
Chapter 16
Batch Jobs
589
To modify the list of jobs, do any of the following: To delete a job, select the job and click Delete . or Move
To reposition a job in the list, select the job and click Move Up 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 Default Notifications Schedules You cannot add, delete, or reposition jobs included in a nested Batch Job unless you modify the definition of that nested Batch Job.
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 Batch Job. For more information, see Properties, Permissions, and Audit Trail tab group on page 98.
590
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.
Chapter 17
591
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
VMware

What you can do

Virtual environment
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 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 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 Live browse for virtual node inventory (host, and Virtual Machine) Snapshot of Virtual Machine or host Audit of Virtual Machine or host
Solaris
IBM
Hyper-V
592
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)
Child Node VMware Virtual Center Server Objects
Virtual Environment VMware
Inventory: Shows the dynamic tree under a vCenter (this is the equivalent of the VMware Infrastructure clients Hosts & Clusters view). This tree shows hierarchical organization and configuration information. Clusters: Shows all the clusters in the vCenter.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.
Chapter 17
593
Contents of the Live node in virtual environments
Table 6
Contents of the Live node by virtual environment (part 2 of 2)

Child Node Managed System Server Objects
Virtual Environment IBM Frame
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 Hyper-V Microsoft SCVMM
Clusters: Shows all the clusters in the Microsoft SCVMM. This 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.
594
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 Snapshot Job - General
Selection 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 General Selection 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.
Chapter 17
595
Managing a VMware environment
Managing a VMware environment

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.
Browsing VMware Virtual Machines

Use this procedure to browse the contents of a VMware virtual environment.
1 In the Servers folder, navigate to a VMware vCenter server. 2 Right-click the server and select Browse. 3 In the Live Browse tab or the content editor, expand the Live node. 4 Expand the VMware Virtual Center server object type to display the nodes.
596
Browsing VMware Virtual Machines
Table 13 describes the structure of the VMware Virtual Center server object type. Table 7
View Inventory
Structure of the VMware Virtual Center object type (part 1 of 2)

Description 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. 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:
Hosts
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
Chapter 17
597
Managing VMware Virtual Machines
Table 7
View
Structure of the VMware Virtual Center object type (part 2 of 2)

Description Lists all the Virtual Machines in the vCenter, in alphabetical order and the power status for each. The Virtual Machine view is a quick way to browse the Virtual Machines in the environment without having to navigate to each VMware host. For each Virtual Machine, you can view:
Virtual Machines
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.
598
Table 8
Task Snapshot Audit Start Stop Suspend Reset
Management tasks for VMware Virtual Machines

Description See Running Snapshot Jobs and Audit Jobs on hosts on page 595. Start a Virtual Machine and run any scripts that are configured to run when the machine starts. Run any power-down scripts and then stop a Virtual Machine. Pause a Virtual Machine that is running. 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. See Saving a virtual servers state on page 599. Delete a Virtual Machine.
Snapshotvm Delete
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. 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 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.
Chapter 17
599
Viewing vCenter server properties
6 Click OK.
Viewing vCenter server properties

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 Virtual machine Available Properties Parent Host Parent Datacenter Parent Cluster (if part of a cluster) Parent Datacenter Parent Cluster (if part of a cluster)
ESX host
Use the following procedure to view the server properties of a Virtual Machine or ESX host on a vCenter server.
1 In the Servers folder, navigate to a vCenter server and expand the Live node. 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 Virtual machine Properties Parent Host Parent Datacenter Parent Cluster (if part of a cluster) Parent Datacenter Parent Cluster (if part of a cluster)
ESX host
600
Adding a new Virtual Machine

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.
1 In the Servers folder, navigate to a vCenter server and expand the Live node. 2 Expand the VMware Virtual Center server object type and then expand the Virtual
Machines node.
3 Browse to an individual Virtual Machine, for example VirtualMachineX.
Chapter 17
601
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 Package Type Select Server Objects Selection Create Package From: Live 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: created.
A In the Depot folder, navigate to the depot folder holding the BLPackage you just 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.
602
In addition to whatever other BLPackage options you choose, make sure to include the following selections:
Node Options => General Selection Set the value of each of the following options according to a new, unique name for the new Virtual Machine.

Name Configuration file Snapshot directory Log Directory Suspended directory
Resources => ResourcePool
Set the value to one of the following:
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. Rightclick the package and select Deploy from the pop-up menu. The New Deploy Job wizard opens. page 527.
B Fill out the wizard panels as described in Deploying a BLPackage on

In addition to whatever other Deploy Job options you choose, sake sure you select a vCenter server as the target on the Targets panel.
Chapter 17
603
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.
604
1 From the Depot folder, right-click the depot folder where you want to add the
Package.
Virtual Guest Package. From the pop-up menu, select New => Virtual Guest
The Virtual Guest Package wizard displays.
2 On the Virtual Guest Package dialog, enter the following:

Field Name Description Member of VM Guest Package type Description Enter a name for the package. Enter a brief description of the package. Browse to the folder in the Depot where you want the Virtual Guest Package to be created. 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. Browse to the location of a template on which this Virtual Guest Package will be based.
VMware VC Template
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.
Chapter 17
605
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 VM Config Type Settings
Description 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/ Disk Settings
Number of virtual Processors, Memory size and Disk 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 Guest OS computer settings information like User, Organization, Licensing information and Time Zone locale settings IP and DNS configuration for the guest BMC BladeLogic Property dictionary settings
VM Computer Settings
Guest Network Local Properties
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.
606
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. to Process in Parallel. Click Next.
3 On the General panel, provide a name, description and set the Number of Targets 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. Networking parameters like Network Port groups and Adaptor Type. If the package is based on a template, this panel is read-only. Click Next.
7 On the Network Connections Wizard panel, specify the Network connections and
8 On the Basic Config panel, specify the Guest OS basic configuration information
like Computer Name, Admin password, WorkGroup and Domain registrationrelated information. Click Next. information such as User, Organization, Licensing information, and Time Zone locale settings. Click Next.
9 On the Computer Settings panel, specify the Guest OS computer settings
Chapter 17
607
Remediating a Virtual Machine
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.
Remediating a Virtual Machine

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:
608
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. 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 Global Zones server object type to display the nodes.
Table 13 describes the structure of the Global Zones server object type. Table 9
View Non-global Zones
Structure of the Global Zones object type

Description 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 Resource Pools
Displays the settings and attributes for each project. Displays resource pool information such as processor set data (pset name, system ID, maximum and minimum CPU settings) and pool default.
Chapter 17
609
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
Task Snapshot Audit Start Install Halt Reboot Boot
Management tasks for Non-global Zones

Description See Running Snapshot Jobs and Audit Jobs on hosts on page 595. Starts a Non-global Zone. Installs a Zone that is in the configured state. Stops a Zone and returns it to the ready state. Halts and then boots a Zone. 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.
610
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. 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 Managed System server object type to display the nodes.
Table 13 describes the structure of the Managed System server object type. Table 11
View Configuration
Structure of the Managed System object type (part 1 of 2)

Description 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
Chapter 17
611
Managing IBM LPARs on the frame
Table 11
View
Structure of the Managed System object type (part 2 of 2)

Description 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:
VIO Servers:
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.
612
Managing a Microsoft Hyper-V environment
Table 12
Task Snapshot Audit Start Restart Stop
Management tasks for IBM LPARs

Description See Running Snapshot Jobs and Audit Jobs on hosts on page 595. Start an LPAR from the HMC and run any scripts that are configured to run when the partition starts. Stop the LPAR from the HMC and then start it again. Run any power-down scripts from the HMC and then stop the LPAR.
Managing a Microsoft Hyper-V environment

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. 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 Microsoft SCVMM server object type to display the nodes.
Chapter 17
613
Managing Microsoft Virtual Machines
Table 13 describes the structure of the Microsoft SCVMM server object type. Table 13
View Clusters
Structure of the Microsoft SCVMM object type

Description 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 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.
Hosts
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. 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:
Virtual Machines
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.
614
Managing virtualization sprawl
The Virtual Machines node shows all Virtual Machines configured within the SCVMM server.
3 Right-click a Virtual Machine. From the pop-up menu, select any of the
Table 14
Task Snapshot Audit Start Poweroff Suspend SaveState
Management tasks for Hyper-V Virtual Machines

Description See Running Snapshot Jobs and Audit Jobs on hosts on page 595. Starts the Virtual Machine. Perform an immediate stop of the Virtual Machine, without running any power-down scripts. Pause the Virtual Machine. Save the Virtual Machine's state to hard disk. Discard the saved state from hard disk. Run any power-down scripts and then stop a Virtual Machine. Create a snapshot for the Virtual Machine.
DiscardSaveState Shutdown Snapshotvm
Managing virtualization sprawl

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
Identifying virtual sprawl

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.
Chapter 17
615
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 VMware and Solaris Task 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 environments only Discover unregistered Virtual Machines on the datastores of the 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)
616
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 Name Description Save in Number of Targets to Process in Parallel Description Enter a name for the Job. Enter a brief description of the Job. Browse to the folder in which you want to save the Job. Set the Number of Targets to 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.
Chapter 17
617
Option Import Lifecycle Properties
Description Imports the server lifecycle properties for a virtual system from a pre-defined mapping file. The selected XML file contains a list of mappings for the targets and VMware vCenter servers against which the Virtual Infrastructure Discovery Job is run. 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:
618
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 11 Click Finish after completing the last step of the wizard. NOTE
VSMDiscoveryJob ACL, by default, has all of the permissions required. Click Next.
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.
Chapter 17
619
Creating the server lifecycle properties mapping file
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.
620
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" customProperty="" /> <property name="owner" customProperty="" /> <property name="expiry date" customProperty="" /> </VirtualEntityManager> <VirtualEntityManager> <name>hostname_2</name> <type>VMware vCenter</type> <property name="location" customProperty="VM location" /> <property name="owner" customProperty="VM owner" /> <property name="expiry date" expiry date"/> </VirtualEntityManager> </VirtualEntityManagerList> </CustomPropertyMapping>
defaultValue="Boston" defaultValue="BMC"
isMap="false" isMap="false"
defaultValue="2009-08-21 14:07:20" isMap="false"
defaultValue="" defaultValue="" defaultValue=""
isMap="true" isMap="true" isMap="true" customProperty="VM
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.
Chapter 17
621
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.
622
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.
Chapter 18
623
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 Agent Information Network Top Description Runs the Network Shell agentinfo command, which provides information about specified servers. Displays processes running on servers across a network. Information displays in a shell and is updated on a periodic basis. Opens a Network Shell on specified servers. Reboots specified servers. 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. Displays information about the configuration of specified servers, such as their speed, disk size, and memory. Displays statistics about disk usage on specified servers. Displays memory usage on specified servers. Displays processes running on specified servers. Displays overview information about activity on specified servers, such as the number of processes running and the amount of memory used on those servers.
NSH Here Reboot Server Secadmin
Remote Desktop Connection Opens a connection with a remote Windows machine.
Server Overview View Disk Usage View Memory Usage View Processes View Server Activity
The Custom Command Administration window lets you perform any of the following procedures:

Creating or modifying a custom command 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.)
624
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 %h %p Information Provided The names of selected servers on which the command should run. 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. 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.
%f
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.
Chapter 18
625
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.
Deleting a custom command
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 controlled through ACLs.
11 Define an ACL for the custom command. For more information on defining an
ACL, see Defining permissions for a system object on page 186.
Finish or OK.
12 Depending on whether you are creating or modifying a custom command, click
Deleting a custom command

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
dialog prompts you to confirm the deletion.
.A
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.
Chapter 18
627
Adding a custom configuration object
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:
Adding a custom configuration object Identifying configuration files Creating extended objects 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.
Adding a custom configuration object

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.
628
Identifying configuration files
1 Obtain a ZIP file containing the materials needed to implement a custom

configuration object. Dictionary opens.
2 Select Configuration => Config Object Dictionary View. The Configuration Object 3 Click the Add Configuration Object icon
opens. . The New Configuration Object wizard
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. 6 Click Next. The Permissions panel displays.
The Permissions panel is an access control list granting roles access to this server object. Access to all objects, including the sharing of objects between roles, is controlled through ACLs.
7 Define an ACL for the server object. For more information on defining an ACL, see
Defining permissions for a system object on page 186.
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.
Chapter 18
629
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.
630
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.
Configuration Object
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
to the right, select the server with the file path you are specifying.
Add multiple files (wildcarded File path) from server. Then, from the drop-down list
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 navigate to the file.
to
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.
Chapter 18
631
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
ACL, see Defining permissions for a system object on page 186.
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.
632
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 Name /etc/auto_* file Associated Grammar File auto.gm
Description Parses files with lines made up of a varying number of tab-delimited entries; the first entry is the unique key. Parses files with four colon-delimited values in each line; the first value is the unique key. Parses files with four colon-delimited values per line; the first value is the unique key. Parses files with lines made up of a varying number of tab-delimited entries; uses the entire line as the unique key. Parses files where each line consists of seven colondelimited fields; the first value is the unique key. Parses files with a varying number of space- or tabdelimited entries on each line; the unique key is generated by a combination of all entries. Parses files with lines of nine colon-delimited values; the first value is the unique key. Parses all /etc/security files in AIX that have a header on one line followed by name/value pairs connected by an equal sign (=); the first value is the unique key. 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. 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. Parses WebLogic config.xml files. Parses Tomcat context.xml files. Stores five time-based values and one ambiguous command value per line; the command is the unique key. Parses files consisting of lines of a varying number of comma-separated entries; uses the entire line as a unique key. Parses files where each line consists of six tabdelimited entries; the first entry is the unique key.
/etc/group file /etc/inittab file /etc/pam file
group.gm inittab.gm pam.gm
/etc/passwd file /etc/resolv.conf file /etc/shadow file AIX /etc/security/* file audit control file
passwd.gm resolv.gm
shadow.gm aix_security.gm
audit_control.gm
audit files
audit.gm
config.xml console_perms context.xml crontab file
config.xml.gm context.xml.gm crontab.gm
console_perms.gm Parses /etc/security/console.perms files on Linux.
csv file
csv.gm
fstab mount file
fstab.gm
Chapter 18
633
Grammar Type Name grub.conf hosts file
Associated Grammar File grub.gm hosts.gm
Description Parses /etc/grub.conf files on Linux. Parses files with lines consisting of a varying number of space-delimited entries; the first entry is the unique key. Parses formats similar to a simple XML format. Parses records with a name and one value and treats comments as values. Parses /etc/lilo.conf files on Linux. Parses a complex format specific to /etc/yp.conf files on Linux. Parses machine.config XML files used for IIS and .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. Parses records with a name and multiple values, such as name = value1 value2 value3. Parses files with single name/value pairs connected by an equal sign (=); uses the name before the equal sign as a unique key. 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. Parses formats using an initial key followed by a colon with a varying number of space-delimited values after the colon. Parses tnsnames.ora and listener.ora files in Oracle.
httpd.conf file init.ora file lilo.conf Linux /etc/yp.conf file Machine Config XML file
httpd.gm init.ora.gm lilo.gm ypconf.gm machine.config.x ml.gm
name = multi values name = value
nvp.gm
nsvp.gm
name space value
nsvp_space.gm
nsswitch.conf on UNIX Oracle config files
nsswitch.gm
ora.gm
running-managed- running-managed- Parses Tomcat running-managed-servers.xml files. servers.xml servers.xml single unique value per line Solaris /etc/system file Solaris inetd.conf file single_val.gm Parses files where each line contains one value that does not contain a space, equal sign (=), or pound sign (#). Uses a complicated grammar to parse Solaris /etc/system files. Parses Solaris files with lines consisting of a varying number of tab-delimited entries; all entries make up the unique key.
system.gm inetd.gm
634
Grammar Type Name split line into fields
Associated Grammar File line.gm
Description Parses generic records separated by spaces; all fields participate in the key. Used as an alternative to generic.gm, this grammar is used to parse /etc/init.d/netconfig, /etc/security/audit_startup, and /etc/ftpd/ftpaccess files on Solaris. Parses /etc/ssh/ssh_config files on Linux. Parses /etc/ssh/sshd_config files on Linux. Parses Tomcat server.xml files. Parses Tomcat users.xml files. Parses /etc/syslog.conf files on UNIX.
ssh_config sshd_config
ssh_config.gm sshd_config.gm
tomcat-server.xml tomcatserver.xml.gm tomcat-users.xml UNIX /etc/syslog.conf file users and exports file tomcatusers.xml.gm syslog.gm
users.gm
Parses files using the format of the BMC BladeLogic users and exports configuration files. For a discussion of those files, see the BMC BladeLogic Administration Guide. The first entry is the unique key. Parses files where each line consists of seven tabdelimited entries; uses the first entry as the unique key. Parses J2EE web.xml files. Parses web.config XML files used for IIS and .NET applications. This grammar is specifically designed for web.config XML files that may include multiple nodes with identical names and the same parent node. Parses files by treating a complete line as a single field; uses the entire line as a unique key. This grammar can be used for parameter substitution during Deploy Jobs. Parses Windows INI formats with a bracketenclosed header and subsequent name-value pairs; the first entry is the unique key. Parses xinetd.conf files on Linux. Uses an XML library to parse XML files.
vfstab mount file
vfstab.gm
web.xml Web Config XML file
web.xml.gm web.config.xml.g m
whole line as record
generic.gm
Windows INI file
ini.gm
xinetd.conf file XML file
xinetd.gm xml.gm
Chapter 18
635
Creating extended objects

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 Configuration Object . 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 Configuration Object . This option functions the same as the Add Configuration Object icon except that all fields are automatically completed using information from the extended object you are copying.
To delete one or more extended objects, select those objects and then click Delete Configuration Object . A message prompts you to confirm your action. Click Yes to confirm.
3 For Name, enter a name for the extended object. For Description, you can optionally
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.
Chapter 18 Administrative tools 637
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
to navigate to the program or script generating the path or use Browse 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.
638
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.
The Permissions panel is an access control list granting roles access to this extended object. Access to all objects, including the sharing of objects between roles, is controlled through ACLs.
11 Define an ACL for the extended object. For more information 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. . The Icon Library dialog opens.
2 For Icon, click Browse 3 Do one of the following:
To add a new custom icon, click Add Custom Icon dialog opens.
. The New Custom Icon
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.
Chapter 18
639
Deleting a custom configuration object
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.
Deleting a custom configuration object

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. Configuration Object Dictionary opens.
2 From the Configuration menu, select Config Object Dictionary view. The 3 Select one or more custom configuration objects and click Delete Configuration
Object
. A message prompts you to confirm your action.
640
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 templates, BLPackages, and server object-based Snapshot and Audit Jobsso they reference a new version of a custom configuration object. You must run this job after you add a new version of a custom configuration object to the Configuration Object Dictionary if you want policy-based objects to reference that new version. For more information, see Creating 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.
Chapter 18
641
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

the following sections: General Selected Configuration Objects Targets Default Notifications Schedules Properties Permissions
General
The General panel lets you provide basic information that identifies a Distribute Configuration Objects Job.
642
Selected Configuration Objects
clicking the browse button. The Select Folder dialog opens. Choose a job folder and click OK.
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 Server Automation Administration Guide for more information on configuring Application 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.
Schedules
Schedules
Execute job now.
or .
information:
categories of information:
Chapter 18
645
Schedules
Schedule
NOTE
646
Schedules

Chapter 18
647
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 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 a Distribute Configuration 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). 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 Distribute Configuration Objects Job. 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.
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.
Modifying Distribute Configuration Objects Jobs

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:
648
Creating an Upgrade Model Objects Job
General Selected Configuration Objects Targets Default Notifications Schedules These tabs correspond to panels in the New Distribute Configuration Objects Job wizard. Use them to modify the job definition.
Creating an Upgrade Model Objects Job

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 Default Notifications Schedules Properties Permissions
Chapter 18
649
General
General
The General panel lets you provide basic information that identifies a Upgrade Model Objects Job.
Selected Objects
The Selected Objects panel lets you choose the component templates, BLPackages, and server-object based Snapshot Jobs and Audit Jobs that you want to upgrade so they use the current version of custom configuration objects.
650
1 From Available Objects, select one or more component templates, BLPackages, and
server-object based Snapshot Jobs and Audit Jobs.
Chapter 18
651
Schedules
Schedules
Execute job now.
or .
information:
Schedule
652
Schedules
NOTE
Chapter 18
653
Properties

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 defined as editable. For more information on assigning property values, see Setting values for system object properties on page 140.
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). 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 Upgrade Model Objects Job. 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.
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.
Modifying Upgrade Model Objects Jobs

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 Default Notifications Schedules These tabs correspond to panels in the Upgrade Model Objects Job wizard. Use them to modify the job definition.
Chapter 18
655
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

the following sections: General Selected Configuration Objects Targets Default Notifications Schedules Properties
656
General
Permissions
General
The General panel lets you provide basic information that identifies a Deregister Configuration Object Job.
clicking the browse button. The Select Folder dialog opens. Choose a job folder and click OK.
Chapter 18
657

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. 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. objects.
2 Check Remove any version of selected configuration objects present on servers if you
3 In the Available Configuration Objects list, select one or more custom configuration 4 Click the right arrow to move your selections to the right panel.
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.
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.
658
Schedules
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.
Schedules
Schedules
Execute job now.
or .
information:
Schedule
NOTE
660
Schedules

Chapter 18
661
Properties
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 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 Deregister Configuration Object 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). One common use for job properties is to assign time-out properties.
662
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 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 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.
Modifying Deregister Configuration Object Jobs

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 Selected Configuration Objects Targets Default Notifications Schedules These tabs correspond to panels in the Deregister Configuration Object Job wizard. Use them to modify the job definition.
The Infrastructure Management window

The Infrastructure Management window provides a way to view and manage Application Servers and other servers that support BMC BladeLogic operations.
Chapter 18
663
The Infrastructure Management window
The Infrastructure Management window has these nodes:

Node Application Servers Description 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. Lets you configure, control, and manage multiple Application Servers on the same host. (Your role must be granted authorization to view and manage Application Servers on this node.) For information, see the BMC BladeLogic Server Automation Administration Guide. Displays information about the PXE servers used for provisioning Windows and Linux servers in a BMC BladeLogic environment. For information, see Getting
Application Server Launchers
Pxe Servers
information about PXE servers on page 666.

Database Config Info Proxy Servers
Displays database connection information. For information, see Getting information about the database on page 667. Lets you create and manage SOCKS proxy servers used to communicate with remote target servers. See Managing SOCKS proxy servers on page 673. 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. 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 BladeLogic Server Automation Administration Guide. Lets you create and manage repeater servers used for indirect staging to target servers during deployment. See Managing repeater servers on page 680. Lets you create and manage rules for determining the repeater used for indirect staging to target servers. See Configuring servers to use repeaters during deployments on page 675. 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.
Network Routing Rules
File Servers
Repeater Servers
Repeater Routing Rules
Job Execution Rules
664
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: A list of Application Servers on the host (using the same database) General information about an Application Server
Do the following: Expand the Application Servers node. The left pane lists each Application Servers Display Name and Authorization Port. Click the Application Servers name in the left pane. 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 Application Server provides Status information about an Application Server service A menu of actions you can perform on the Application Server
Expand the hierarchy of an Application Server. (The number and type of services vary according to the Application Servers type.) Expand the hierarchy of the Application Server. Click the service name. Right-click the Application Server.
Chapter 18
665
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.
1 Select Configuration => Infrastructure Management. 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.
1 Select Configuration => Infrastructure Management. 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.
666
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.
1 Select Configuration => Infrastructure Management. 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.
Chapter 18
667
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. routing communications to servers. See Creating rules for routing to remote servers on page 669. page 671.
3 Use the Network Routing Wizard to create a network routing policy and rules for
4 Add the remote servers you want to manage. See Adding remote servers on
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.
1 Select Configuration => Infrastructure Management. 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 Name Description 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. (Optional) Descriptive text about the proxy server. The name of the host machine for the proxy server. The port for the SOCKS proxy.
Description Host Port
668
Creating rules for routing to remote servers
Text Box / Button User name and Password
Description 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. 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.
Resolve host name
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.
1 Select Configuration => Infrastructure Management. 2 In the Infrastructure Management window, right-click the Network Routing Rules
node and select Network Routing Wizard. The General panel opens.
Chapter 18
669
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.
670
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. property.
7 Click OK. The instance (rule name) appears in the Value column for the server 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.
672
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 properties on page 211.
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.
1 Select Configuration => Infrastructure Management. 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. from the pop-up menu.
3 To edit the properties, right-click the name of the proxy server and select Properties
Chapter 18
673
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.
1 Select Configuration => Infrastructure Management. 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.
1 Select Configuration => Infrastructure Management. 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.
1 Select Configuration => Infrastructure Management. 2 In the Infrastructure Management window, expand the Network Routing Rules
hierarchy.
674
Configuring servers to use repeaters during deployments
3 Right-click the rule to which you want to assign proxy servers and select Assign
Targets for Rule. The Targets panel opens.
4 In the list under Select proxies for the rule, select one or more SOCKS proxy servers
through which communication to remote servers should be routed. Then click the right arrow to move the servers to the selected list (on the right). To remove a server from the selected list, select the server name and click the left arrow.
5 Click Finish. NOTE

If a routing rule has multiple SOCKS proxy servers associated with it, the Application Server chooses one proxy server to use for routing to the target server. However, if that proxy server is not running, the connection to the target server fails. The connection does not fail over to another proxy server associated with the rule.
Configuring servers to use repeaters during deployments

When you deploy a BLPackage or software package, the objects being deployed are copied to a staging directory on target servers. Often this involves copying large files to many target servers. In some situations, copying these objects to a repeater can reduce network traffic. From the repeater, objects are copied to target servers staging directories and used during the Commit phase of a Deploy Job. 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 BladeLogic Server Automation Administration Guide.
Chapter 18
675
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.
1 Select Configuration => Infrastructure Management. 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:
Text Box / Button Name Description (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.
676
Creating rules to determine the repeater used for target servers
Text Box / Button Host
Description (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. 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 Automation Administration Guide.
Enable Advanced Repeater
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.

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.
1 Select Configuration => Infrastructure Management. 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.
Chapter 18
677
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.
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 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 .
678
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.
11 Click Close to close the Infrastructure Management window.

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.
Chapter 18
679
Managing repeater servers
4 Click in the Value column of the selected property. Then click Select a value
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.)
. The
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. property.
6 Click OK. The instance (rule) name appears in the Value column for the server 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.
1 Select Configuration => Infrastructure Management. 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.
680
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. To remove a server from the selected list, select the server name and click the left arrow.
5 Click OK.
Chapter 18
681
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.
682
Creating rules to determine Application Servers to use for job execution
3 Right-click the repeater server and choose from the following options:
Option Update Repeater Server Status Description This option contacts the repeater server to determine current status. The Infrastructure Management window displays such information as name, host, and staging directory. If the staging directory exists, the window also displays information about its disk usage. If the repeater server is not running, its name shows a red X icon ( ). Refresh Properties This option updates the status of the server. 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 Cache Verify Advanced Repeater Cache Repair Advanced Repeater Cache This option clears the cache on an advanced repeater server. This option verifies that the cache on an advanced repeater server is operational. This option repairs a corrupted cache on an advanced 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.
1 Select Configuration => Infrastructure Management. 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.
Chapter 18
683
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.
C In the next drop-down box to the right, select a comparison-operator, such as

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 Property Condition again. . To add further conditions, click Add
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).
Creating complex routing rules

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. . The New Rule wizard opens
3 In the Rules Management panel, click Add Rule

and shows the General panel.
Chapter 18
685
Creating complex routing rules
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.
C In the next drop-down box to the right, select a comparison-operator, such as

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 Property Condition again.
. To add further conditions, click Add
The following shows a routing rule definition.
686
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. 9 Click Close to close the Infrastructure Management window.
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 servers on page 677.
Chapter 18
687
Viewing and editing routing rules
Viewing and editing routing rules

Use this procedure to view or edit routing rules.
1 Select Configuration => Infrastructure Management. 2 In the left pane of the Infrastructure Management window, right-click the node for
the routing rules you want to edit; for example, Repeater Routing Rules. Then select Rules Management from the pop-up menu.
The Rules Management panel opens and shows each rules name, description, and definition.
3 In the Rules Management panel, select the name of the rule that you want to view
in more detail or to edit. Then click Edit Selected Rule opens to the General tab. . The Modify Rule dialog
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.
688
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.
Changing the order of rule evaluation

To determine which server to use for interaction with a target server, the Application Server evaluates each request against the list of routing rules. The order of rules on the list determines the order of evaluation. You can change the order of rules in the Rules Management window.
the routing rules you want to reorder; for example, Repeater Routing Rules. Then select Rules Management from the pop-up menu. , and Move to Bottom
3 On the Rules tab, select the rule you want to re-position and use the Move Up
, Move to Top the list is evaluated first.)
Move Down
, icons. (The rule at the top of
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 select Rules Management from the pop-up menu.
Chapter 18
689
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.
690
Chapter
19
Patch management for Microsoft Windows

19
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.)
Chapter 19
691
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 PatchCatalog.* PatchCatalog.ModifyACL PatchCatalog.CreateACL PatchCatalog.Create PatchCatalog.Delete PatchCatalog.Read PatchCatalog.Update PatchCatalog.Modify PatchCatalog.ModifySchedule PatchCatalog.Cancel PatchCatalog.ModifyProperties PatchSmartGroup.* PatchSmartGroup.ModifyACL PatchSmartGroup.CreateACL PatchSmartGroup.Create PatchSmartGroup.Delete PatchSmartGroup.Read PatchSmartGroup.Write PatchSmartGroup.Modify WindowsSoftware.* Server.* ServerGroup.* DepotFile.* (Offline) Access to the server on which the patch repository is located If the patch administrator creates a catalog in offline mode, depot file permissions are needed to select the metadata files during catalog creation. Gives the user the ability to Manage the patch catalog Modify ACLs Create ACLs Create a new patch catalog Delete a patch catalog Open an existing patch catalog Add new objects to a patch catalog Modify an existing patch catalog Schedule a patch catalog update job Cancel a patch catalog update job Modify catalog update job properties Patch smart group management Modify ACLs Create ACLs Create a new patch smart group Delete a patch smart group Open an existing patch smart group Add new objects to a patch smart group Modify an existing patch smart group
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: nonplatform 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 Proxy Server Type Description 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. Defines the password associated with the defined User Name required to log onto the Proxy Server. Defines the domain name of the Proxy Server. Defines the IP Address or Host Name of the Proxy Server. Defines the port number used for communication with the Proxy Server.
Password Domain Host Port
3 Click the Windows tab.
Chapter 19
693
Parameters Catalog Object Processor Batch Size
Description Defines a default batch size used for parallel processing 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 specifically required.
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 Connection Retry HTTP/HTTPS/FTP Connection Timeout Patching to Remediation job timeout
If BMC BladeLogic fails to connect to a vendor site on the first try, specify the number of attempts made before reporting failure. Specify the length of time, expressed in milliseconds, that BMC BladeLogic will wait before making another attempt to connect to the vendor site. Defines a job timeout ratio, patching (x) to remediation (y), 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. Defines a timeout ratio, remediation (x) to download (y), 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.
Remediation to Download job timeout
694
Book Title
Parameters Patching to Remediation job part timeout
Description Defines a job part timeout ratio, patching (x) to remediation (y), 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. Defines a job part timeout ratio, remediation (x) to download (y), 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. The Deploy Job sends commands to the operating system 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. The Deploy Job sends commands to the operating system which in turn sends responses back to BMC BladeLogic 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.
Remediation to Download job part timeout
Patch deploy success return codes
Patch deploy 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 codes The Deploy Job sends commands to the operating system 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. During rollback of a patch, the operating system returns an exit code if the action was successful. In most cases, standard commands are used; occasionally, the operating system uses a return code not known to BMC BladeLogic. Unknown codes entered in this field are defined to BMC BladeLogic as undeploy success return codes.
Patch undeploy success return codes
Chapter 19
695
Viewing published patches
Parameters
Description
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 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 undeploy failure return codes. Patch undeploy warning return codes During rollback of a patch, the operating system may return a warning. In most cases, standard commands are used; occasionally, the operating system uses a return code not known to BMC BladeLogic. Unknown codes entered in this 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 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
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.
Chapter 19
697
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
Defining catalog parameters

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.

catalog is placed.
Member Of is a read-only field indicating Depot, the location where the new
3 In the Catalog Mode section, select Source from Vendor (Online Mode). 4 In Repository Options, enter the following:
Box Windows Helper Server Location Description (Mandatory) Browse to or enter the NSH path to a userdefined 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. (Not applicable in Online Mode) The source is assumed to be the URL for Shavlik Technologies which is supplied automatically. Browse to or enter the NSH path to the location where the patch repository will be located. This location should have ample free space since files contained in the repository can run into gigabytes of data.
Payload Source Location (NSH Path) Repository Location (NSH Path)
698
Book Title
Box Patch Signature File (nfnetchk) Package Info File (pd5)
Description Not applicable for an online catalog where the signature file, either hfnetchk6b.cab or hfnetchk6b.xml, is downloaded automatically from the Shavlik Technologies website. 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 Network URL type for payload deployment* Description
(default) Copy to agent at staging: The BMC BladeLogic 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 deployment*
Enter an NSH-accessible path to a location where the payload 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. 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.
RBAC Policy
NOTE
For more information on Network URLs, see URL syntax for network data transmission on page 362.
Chapter 19
699
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.
Scheduling updates to the catalog

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.
Defining catalog update job properties

A list of standard job properties is displayed. Most are read-only though a few are available for edit.
Property RESULTS_RETENTION_TIME Description Expressed in number of days, defines the length of time that BMC BladeLogic retains a job run and result information. Defines the maximum number of parallel work items processed per Virtual Machine host. Defines whether the object was auto-generated. Expressed in number of minutes, defines the length of time a job should run before being automatically cancelled. Expressed in number of minutes, defines the length of time that the job part/work item should run before being automatically cancelled.
MAX_PARALLEL_PER_VM_HOST AUTO_GENERATED JOB_TIMEOUT
JOB_PART_TIMEOUT
To edit a job property, click in the Value column for that parameter and enter information.
Defining ACL permissions and/or ACL policies

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 BMCprovided utility, to a server with Internet access that is outside of the environment and not directly available to the BMC BladeLogic Application Server.
Chapter 19
701
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 <protocol></protocol> Description Specify the proxy configuration for a protocol. Valid values are:

http https ftp
<port></port> <host></host> <username></username> <password></password> domain-name></domainname>
Specify the port used for communication with the proxy server. Enter the proxy servers host name or IP address. Enter the user name required for authentication prior to communication with the proxy server. Enter the password associated with the user name identified in the parameter, <username>. Enter the proxy server domain name which will be used for authentication.
<proxy-type></proxy-type> Define the type of proxy server. Valid values are:

ntlm ntlm-v2 squid
Chapter 19
703
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-payloadcertificate>
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</productcategory> <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 Parameter downloaderConfiguration FilePath Description Enter the location of the Configuration File used by the patch 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
Chapter 19
705
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> <domain-name></domain-name> <proxy-type>ntlm</proxy-type> </proxy> </proxy-settings> <temporary-location>c:\tmp</temporary-location> <validate-payload-certificate>true</validate-payloadcertificate> <payload-repository-location>d:\repo\windows</payloadrepository-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</productcategory> <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:


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.
To define catalog parameters 1 Right-click a folder within the Depot and choose New => Patch Catalog => Windows
Patch Catalog.

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 Disk Repository (Offline Mode).
Chapter 19
707
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 userdefined 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 (NSH Path) Payload Repository Location (NSH Path)* Enter or browse to the location where existing metadata and/or payload files are stored. Files stored in this location will be copied to the catalog automatically. Browse to or enter the NSH path to the location where the 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.

(default) Copy to agent at staging: The BMC BladeLogic 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 NSH-accessible network location where patch payloads are stored. (See also Network URL for payload deployment.)
708
Book Title
Box Network URL for payload deployment*
Description Enter an NSH-accessible path to a location where the payload 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. 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.
RBAC Policy
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. 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 language used by the products interface and help
files.
Chapter 19
709
4 Click OK to save the filter. TIP


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.
Defining catalog update job parameters

JOB_PART_TIMEOUT
710
Book Title
Viewing the catalog on the BMC BladeLogic Console


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 online patch catalog on page 697. 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.
Chapter 19
711
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
Updating 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.
Downloading patches to the catalog

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.
Chapter 19
713
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.
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.
Removing irrelevant patches from an existing catalog

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.
Chapter 19
715
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:
Description Select to analyze patches that address security 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. Select to analyze patches that help prevent or clean up malicious software. Option Analyze security patches (recommended)
Analyze security tools
Analyze non-security patches Select to analyze performance-related fixes, fixes for known bugs, and hardware drivers. Filter out service packs from result Select this option if you want to exclude service packs from 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:
Description Select when remediation should occur immediately, once analysis completes. All options displayed are available only when Auto Remediate is selected. 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. Option Auto Remediate
Packaging Options Package name prefix
716
Book Title
Viewing results of a patching job
Option Save package(s) in
Description 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. 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 displayed. Browse to and select the ACL Policy which will be assigned to each BLPackage, Deploy Job, and Batch Job created by the patching job. Select a set of pre-defined, parameter definitions that will be applied to each Deploy Job created by the Patching Job.
Deploy Job Options Save batch/deploy job(s) in
ACL Policy for Package(s)/Deploy Job(s) Deploy Job Options
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.
12 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, instead of the default notifications defined in the previous step, whenever this job is run.
13 Click Finish.
Best Practice: Once remediation is complete, run patch analysis again. The second
TIP
analysis sometimes reveals other patches that are missing and should also be remediated.

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 autoremediation was included for the job.
Chapter 19
717
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. On the right side of the pane, statistics are displayed. How 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 lists every missing patch discovered during analysis together with architecture, whether the patch is recommended by Shavlik Technologies website, whether its a security patch, as well as a description of the patch. Rightclick 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 organizes target servers included in the job according to two sub-categories, Failed Targets and Successful Targets. Target servers included in the job are grouped into ranges known as buckets and within these ranges, target servers are listed individually including the number of Missing Bulletins, Missing Hotfixes, and final Status. Rightclick 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.
Analysis Run at <date><time>
Object View
Server View
718
Book Title
Actions you can take from this view include:

Action Show Job Description Opens a read-only view of the job definition including parameter definitions, analysis options, targets, default notifications, and schedules. 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. Updates the display for the selected job to reflect the jobs current status. Select to run the job again against target servers that returned either warnings, errors or failures. The application displays the list of failed servers. Select the Create Execution Task check box and click OK. Results are shown on the right side of the workspace. Rightclick the job results and select Show Log. Messages generated by BMC BladeLogic while the job was running are displayed. Exports the log as a CSV file to a location on the same computer from which you initiated the Export Log command.
Delete
Refresh Execute Against Failed Targets
Show Log
Export Log
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 Download Selected Patches Open Patch Remediate All Servers Define a remediation job that is specifically for the patches you selected. Select to download payload for a specific set of patches where only the metadata is present in the patch catalog. . Opens the Depot Software Properties box with a two-page, read-only description of the metadata for the selected patch. 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. Select to download payload for all patches where only the metadata is present in the patch catalog.
Download All Missing Patches
Chapter 19
719
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 <jobName> Run at <date><time> Description The name of the job is displayed. 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 Refresh Show Log Description Updates the display for the selected job to reflect the jobs current status. 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. Clear Execution Override: The user and role which scheduled the job will be the
6 Click Next. 7 In Packaging Options, enter the following information:

Option Package Name Prefix Description 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. 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.
Save package in
8 In Deploy Job Options, enter the following information:

Option Save batch/deploy job(s) in ACL Policy for Package(s)/Deploy Job(s) Deploy Job Options Description Enter or browse to a job folder where the Batch and Deploy Jobs created by the remediation job will be stored. Browse to and select the ACL Policy which will assign predefined permissions to each BLPackage, Deploy Job and Batch Job created by the remediation job. Select a set of pre-defined, parameter definitions that will be applied to each Deploy Job created by the Remediation Job.
9 Click Next. 10 Define the default job notifications you want to be sent out on job completion and
click Next.
To execute the remediation job immediately, select the Execute Job Now check box.
Chapter 19
721
Click New Schedule to open the Add New Schedule screen. Define the time interval, time zone, and notification options to be used, instead of the default notifications defined in the previous step, whenever this job is run.
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 jobName Run at date time Description The name of the job is displayed. 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.

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.
Chapter 19
723
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. 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.
NOTE
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. Offline: In an air-gapped environment, where the servers do not have Internet 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 repository which is housed on a server within the environment.
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).
Chapter 20
725
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. 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. (Roll out can be automatically performed at the end of patch analysis or separately, at a later time.) Re-analyze your servers to ensure that each one is at the required patch level.
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.

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 Solaris should have the following permissions:
Define permissions for PatchCatalog.* PatchCatalog.ModifyACL PatchCatalog.CreateACL PatchCatalog.Create PatchCatalog.Delete PatchCatalog.Read PatchCatalog.Update PatchCatalog.Write PatchCatalog.Modify PatchCatalog.ModifySchedule PatchCatalog.Cancel PatchCatalog.ModifyProperties PatchSmartGroup.* Gives the user the ability to Patch catalog management Modify ACLs Create ACLs Create a new patch catalog Delete a patch catalog Open an existing patch catalog Add new objects to a patch catalog Add new objects to a patch catalog Modify an existing patch catalog Schedule a patch catalog update job Cancel a patch catalog update job Modify catalog update job properties Patch smart group management
726
Define permissions for PatchSmartGroup.ModifyACL PatchSmartGroup.CreateACL PatchSmartGroup.Create PatchSmartGroup.Delete PatchSmartGroup.Read PatchSmartGroup.Write PatchSmartGroup.Modify SolarisSoftware.* Server.* ServerGroup.* DepotFile.*
Gives the user the ability to Modify ACLs Create ACLs Create a new patch smart group Delete a patch smart group Open an existing patch smart group Add new objects to a patch smart group Modify an existing patch smart group (Offline) Access to the server on which the patch repository is located 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 autopopulated during catalog as well as patching and remediation job creation. These parameters are grouped into two categories: non-platform specific and platformspecific.
To define global configuration parameters 1 On the Configuration menu, select Patch Global Configuration View. 2 Click the All Operating Systems tab.
Chapter 20
727


User Name
4 Click the Solaris tab. 5 Enter the User Name and Password supplied for access to the Sunsolve website.
Parameters Catalog Object Processor Batch Size Description Defines a default batch size used for parallel processing 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 specifically required. 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.
728
Parameters Action on Failure
Description During deployment on a target server, if a particular patch fails to deploy, what should BMC BladeLogic do:

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. HTTP/HTTPS/FTP Connection Retry HTTP/HTTPS/FTP Connection Timeout Patching to Remediation job timeout If BMC BladeLogic fails to connect to a vendor site on the first try, specify the number of attempts made before reporting failure. Specify the length of time, expressed in milliseconds, that BMC BladeLogic will wait before making another attempt to connect to the vendor site. Defines a job timeout ratio, patching (x) to remediation (y), 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. Defines a timeout ratio, remediation (x) to download (y), 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. Defines a job part timeout ratio, patching (x) to remediation (y), 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. Defines a job part timeout ratio, remediation (x) to download (y), 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. The Deploy Job sends commands to the operating system which in turn sends responses back to BMC BladeLogic indicating that the commands succeeded. 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 success return codes.
Patching to Remediation job part timeout
Chapter 20
729
Parameters Patch deploy failure return codes
Description The Deploy Job sends commands to the operating system which in turn sends responses back to BMC BladeLogic indicating that the commands failed. 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 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 codes The Deploy Job sends commands to the operating system 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. During rollback of a patch, the operating system returns an exit code if the action was successful. In most cases, standard commands are used; occasionally, the operating system uses a return code not known to BMC BladeLogic. Unknown codes entered in this field are defined to BMC BladeLogic as undeploy success return codes.
Patch 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 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 undeploy failure return codes. Patch undeploy warning return codes During rollback of a patch, the operating system may return a warning. In most cases, standard commands are used; occasionally, the operating system uses a return code not known to BMC BladeLogic. Unknown codes entered in this 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 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
6 Click Save.
730

The process of deciding which patches available from the vendors need to be applied 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.
The patch catalog is how you maintain and work with that repository through the 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 catalog on page 732. 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.
Chapter 20
731

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


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.
732
To define catalog parameters 1 On the BMC BladeLogic Console, right-click a folder in the Depot and choose
New => Patch Catalog => Solaris Patch Catalog.

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.
5 In Repository Options, enter the following:

Box Payload Source Location (NSH Path) Payload Repository Location (NSH Path)* Description (Not applicable in Online Mode) The source is assumed to be the network URL for the SunSolve website which is supplied automatically. Browse to or enter the NSH path to the location where the 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. (Not applicable in Online Mode) The location in the Depot where the patchdiag.xref file is located. 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 catalog on page 740.
Source patchdaig.xref File Metadata Corrections File
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 Adding files to the catalog on page 740.
Chapter 20
733

Box Network URL type for payload deployment* Description (Default) Copy to agent at staging: The BMC BladeLogic 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. 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.
RBAC Policy
NOTE
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
Filters are used to limit the amount of information brought into the catalog from the 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. 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 747).
734
To add a filter 1 Select Add 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.


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 SunSolve website.
Chapter 20
735
Defining an offline patch catalog for Solaris

JOB_PART_TIMEOUT


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 airgapped environment.
736
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 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). During catalog creation, select the same filters used during download to the 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. Update the patch catalog.
Downloading to a Solaris server with Internet access

The Patch Downloader utility provided by BMC BladeLogic uses configuration information, which includes the local path, filters used during download of the patchdiag.xref file as well as payload files from the SunSolve website. The steps to follow are defined in the following procedures:

To prepare the Configuration file on page 738 To download patches for defined filters on page 739
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-solaris-downloader-config.xml).
Chapter 20
737
To prepare the Configuration file 1 Locate and open the sample-solaris-downloader-config.xml file. 2 (Optional) Add proxy information using the following syntax:
<port></port> <host></host> <username></username> <password></password> <domain-name></domain-name> <proxy-type></proxy-type> Parameter <port></port> <host></host> <username></username> <password></password> <domain-name></domainname> Description Defines the port number used to communicate with the proxy server. Defines the IP address or host name of the proxy server. Defines the user name required to log onto the SunSolve website. Defines the password used to log onto the SunSolve website. Defines the domain name of the proxy server.
<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:
738
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 Parameter downloaderConfiguration FilePath sunsolveUserName sunsolvePassword Description Enter the location of the Configuration File used by the patch downloader. Enter the user name required to log onto the SunSolve website. 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 Windows, Solaris or Linux server.
Chapter 20
739
The configuration file contains the following settings:

<solaris-downloader-config> <config> <proxy-settings> <port>8080</port> <host>IPAddress</host> <username>vpcuser</username> <password>fr3sca!@#</password> <domain-name>vpcdc</domain-name> <proxy-type>ntlm-v2</proxy-type> </proxy-settings> <temporary-location>c:\tmp</temporary-location> <payload-repository-location>d:\tmp\solaris</payload-repositorylocation> <metadata-override-file-path /> <download-request-retries>10</download-request-retries> <download-request-timeout>180000</download-request-timeout> <downloader-parallel-threads>10</downloader-parallel-threads> </config> <subscription> <cluster-filter> <cluster-name>Solaris 9 SPARC Sun Alert Patch Cluster</clustername> <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-id>100323-05</patch-id> <patch-id>100386-01</patch-id> <patch-id>100393-01</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
740
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.
Chapter 20
741
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> <patch-id>113000-07</patch-id> <reboot-info>rebootafter</reboot-info> <single-user>singleuser</single-user> </patch> <patch> <patch-id>138194-01</patch-id> <reboot-info>rebootimmediate</reboot-info> <single-user>singleusernone</single-user> </patch> <patch> patch-id>138195-01</patch-id> reboot-info>rebootnone</reboot-info> single-user>singleuser</single-user> </patch> <patch> <patch-id>138215-01</patch-id> <reboot-info>reconfigimmediate</reboot-info> <single-user>singleusernone</single-user> </patch> <patch> <patch-id>138216-01</patch-id> <reboot-info>reconfigafter</reboot-info> <single-user>singleuser</single-user> </patch> </solaris-sumreboot-info>
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.
742
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 Parameter -i inputFilePath Description 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. 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.
-o outputFilePath

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 a 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. These tasks can be performed either through the wizard or later through the BMC BladeLogic Console.

Defining catalog parameters Adding filters Scheduling updates to the catalog Defining Catalog Update Job parameters Defining ACL permissions and/or ACL policies
Chapter 20
743

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.
To define catalog parameters 1 Right-click a folder in the Depot and choose New => Patch Catalog => Solaris Patch
Catalog.

3 In Catalog Mode, select Source from Disk Repository (Offline Mode). 4 In Repository Options, enter the following:
Box Payload Source Location (NSH Path) Payload Repository Location (NSH Path)* Description Enter or browse to a location where existing metadata and/or payload files are stored. Browse to or enter the NSH path to the location where the 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. (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. (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.
Source patchdiag.xref File
Metadata Corrections File
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. The default name for this file is sum_reboot.info. For more information, see Adding files to the catalog on page 740.
744

Box Network URL type for payload deployment* Description (Default) Copy to agent at staging: The BMC BladeLogic 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. 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.
RBAC Policy
NOTE
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 1 Select Add 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.

Create multiple filters, using any or all of the filter options, to match the criteria defined during initial download.
Chapter 20
745

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 SunSolve website.
Defining Catalog Update Job parameters

JOB_PART_TIMEOUT

746

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:
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 732. 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. Schedules: For more information, see Scheduling updates to the catalog on page 735. 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 parameters on page 746. 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 749.

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 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. 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 Patch or Cluster as well as associated Clusters/Patches. For more information on smart groups, see Managing BMC BladeLogic resources on page 84.
Chapter 20
747


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. This option can be used to create a patch repository provided the patches are downloaded in .zip, .jar, or .tar.Z format. 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. 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 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. 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
748
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.
Downloading patches to the catalog

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.
Member Of is a read-only field indicating Depot, the location where the new
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. 6 Choose when you want to run the job:
Chapter 20
749
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.

3 Click Close.

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

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
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:
Description Select to analyze all patches contained in the patchdiag.xref file. Select to analyze patches that were recommended by the vendor according to information contained in the patchdiag.xref file. Select to analyze patches that address security vulnerabilities. Analyze the patches from the Include List without analyzing associated dependencies. Option Group Analyze all patches Analyze Recommended patches Analyze Security patches List Analyze Without Dependencies
Chapter 20
751
8 Identify when BMC BladeLogic should remediate servers where patches are
missing:
Option Auto Remediate Description Select when remediation should occur once analysis completes. All options displayed are available only when Auto Remediate is selected. 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. 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. 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 displayed. Browse to and select the ACL policy which will be assigned to each BLPackage, Deploy Job, and Batch Job created by the patching job. Select a set of pre-defined, parameter definitions that will be applied to each Deploy Job created by the patching job.
Save package(s) in
click Next.
752
13 Click Finish.
TIP


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. On the right side of the pane, statistics are displayed, including 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 perform one of the following actions: Refresh, Show Log, or Export Log.
Analysis Run at <date><time>
Chapter 20
753
Object View
Object View lists every missing patch discovered during analysis together with architecture, whether the patch is recommended 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. Server View organizes target servers included in the job according to two sub-categories, Failed Targets and Successful Targets. Target servers included in the job are grouped into ranges known as buckets and within these ranges, target servers are listed individually including the number of Missing Clusters, Missing Patches, and final Status. Rightclick 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.
Server View

Delete
Show Log
Export Log
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.
754
Remediating servers
Action Download Selected Patches Open Patch Remediate All Servers
Description Select to download payload for a specific set of patches where only the metadata is present in the patch catalog. Opens the Depot Software Properties box with a two-page, read-only description of the metadata for the selected patch. 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. Select to download payload for all patches where only the metadata is present in the patch catalog.
Download All Missing Patches
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 <jobName> Run at <date><time> Description The name of the job is displayed. 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.

Remediating servers
Chapter 20 Patch management for Solaris 755
Remediating servers
user, BLAdmin, and the role, BLAdmins.
Set Execution Override: The Patch Remediation job will always execute as the

Save package in

9 Click Next.
756
10 Define the default job notifications you want to be sent out on job completion and
click Next.
To execute the remediation 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 to be used, instead of the default notifications defined in the previous step, whenever this job is run.
NOTE
12 Click Finish.


Chapter 20
757
Deploying patches
Deploying patches
NOTE
Patch Reporting
758
Chapter
21
Patch management for Red Hat Enterprise Linux

21
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. A simplified version of the patching process is as follows:
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. 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.
Analyze your target servers to determine the payload that needs to be deployed to those servers. 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 roll out can be automatically performed at the end of patch analysis or separately at a later time.)
Chapter 21
759
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 Red Hat Enterprise Linux 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 patch administrator or split between team members. A patch administrator for Red Hat Enterprise Linux should have the following permissions:
Define permissions for PatchCatalog.* PatchCatalog.ModifyACL PatchCatalog.CreateACL PatchCatalog.Create PatchCatalog.Delete PatchCatalog.Read PatchCatalog.Update PatchCatalog.Write PatchCatalog.Modify PatchCatalog.ModifySchedule PatchCatalog.Cancel PatchCatalog.ModifyProperties PatchSmartGroup.* PatchSmartGroup.ModifyACL PatchSmartGroup.CreateACL PatchSmartGroup.Create PatchSmartGroup.Delete PatchSmartGroup.Read PatchSmartGroup.Write PatchSmartGroup.Modify LinuxSoftware.* Server.* ServerGroup.* (Offline) Access to the server on which the patch repository is located Gives the user the ability to Patch catalog management Modify ACLs Create ACLs Create a new patch catalog Delete a patch catalog Open an existing patch catalog Add new objects to a patch catalog Add new objects to a patch catalog Modify an existing patch catalog Schedule a patch catalog update job Cancel a patch catalog update job Modify catalog update job properties Patch smart group management Modify ACLs Create ACLs Create a new patch smart group Delete a patch smart group Open an existing patch smart group Add new objects to a patch smart group Modify an existing patch smart group
760
Role and ACL Policy definitions are made using the role-based access control utility (RBAC). For more information, see Managing authorizations on page 147.

To define global configuration parameters 1 On the Configuration menu, select Patch Global Configuration View. 2 Click the All Operating Systems tab. 3 Enter the following details:

User Name
4 Click the RedHat tab. 5 Enter the User Name and Password for access to the Red Hat Network vendor site.
Chapter 21
761

Parameters Catalog Object Processor Batch Size Description Defines a default batch size used for parallel processing 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. In most cases, the default value should not be changed. 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. In most cases, the default value should not be changed. 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. Results show the job as failing. Continue: Ignore the failure. The Deploy Job continues and the results show the job as failing.
If BMC BladeLogic fails to connect to a vendor site on the first try, specify the number of attempts made before reporting failure. Specify the length of time, expressed in milliseconds, that BMC BladeLogic will wait before making another attempt to connect to the vendor site. Defines a job timeout ratio, patching (x) to remediation (y), 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. Defines a timeout ratio, remediation (x) to download (y), 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.
762
Parameters Patching to Remediation job part timeout
Description Defines a job part timeout ratio, patching (x) to remediation (y), 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. Defines a job part timeout ratio, remediation (x) to download (y), 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. The Deploy Job sends commands to the operating system which in turn sends responses back to BMC BladeLogic indicating that the commands succeeded. 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 success return codes. The Deploy Job sends commands to the operating system which in turn sends responses back to BMC BladeLogic indicating that the commands failed. 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 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 codes The Deploy Job sends commands to the operating system 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.
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.
Chapter 21 Patch management for Red Hat Enterprise Linux 763
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). The patch catalog is how you maintain and work with that repository through the 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.
764
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. Define the filters used to screen metadata and payload according to product and language criteria. Run the catalog update.
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. 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 Parameters Defining ACL permissions and/or ACL policies

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 createrepo pythonurlgrabber Minimum version 0.4.6 2.9.6
Chapter 21
765
To define catalog parameters 1 Right-click a folder in the Depot and choose New => Patch Catalog => RedHat Linux
Patch Catalog.

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.
5 In Repository Options, enter the following:

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 Repository Location (NSH Path)* Browse to or enter the NSH path to the location where the 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. 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.
766

RBAC Policy
NOTE
For more information on Network URLs, see URL syntax for network data transmission on page 362
Adding filters
Filters are used to limit the amount of information brought into the catalog from the 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.
Chapter 21
767
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 782).
To select a filter 1 Select Add 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


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 RedHat Network website.
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.
768
Schedules can be defined either when the catalog is created or later, when editing the catalog.
Defining Catalog Update Job Parameters

Property RESULTS_RETENTION_TIME
Description Expressed in number of days, defines the length of time that BMC BladeLogic retains a job run and result information. Defines the maximum number of parallel work items processed per Virtual Machine host. Defines whether the object was auto-generated. Expressed in number of minutes, defines the length of time a job should run before being automatically cancelled. Expressed in number of minutes, defines the length of time that the job part/work item should run before being automatically cancelled.
JOB_PART_TIMEOUT


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.
Chapter 21
769
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 the RPMs, Errata and Update Levels using the Patch Downloader utility provided by BMC BladeLogic or your own download utility. 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 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
The steps to follow are defined in the following procedures:

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.
770
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-redhat-downloader-config.xml).
To prepare the configuration file 1 Create and open a configuration file. 2 (Optional) Add proxy information using the following syntax:
<port></port> <host></host> <username></username> <password></password> <domain-name></domain-name> <proxy-type></proxy-type> Parameter <port></port> <host></host> <username></username> <password></password> <domain-name></domainname> Description Defines the port number used to communicate with the proxy server. Defines the IP address or host name of the proxy server. Defines the user name required to log onto the Red Hat Network website. Defines the password used to log onto the Red Hat Network website. Defines the domain name of the proxy server.

NLTM NLTM-V2 Squid
Chapter 21
771
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>
772
Parameter <errata-type-filter> <os></os> <arch></arch> <channel-label> </channel-label> <errata-severity> </errata-severity>
Description Enter the operating system for the channel label. Enter the architecture for the channel label. Enter the channel label you want to download. Configure filter for metadata download of security advisory errata patches. For each classification, enter True to include patches of that type or False to exclude patches of that type.

<critical> <high> <moderate> <low>
<errata-type></errata-type>
Configure filter for metadata download of errata according to type. For each classification, enter True to include patches of that type or False to exclude patches of that type.

<security></security> <bugfix></bugfix> <enhancement></enhancement>
To create a filter that downloads a specific RPM or list of RPMs, use the following syntax:
<errata-ids-filter> <os></os> <arch></arch> channel-label></channel-label> <errata-ids> <errata-id></errata-id> </errata-ids> </errata-ids-filter> Parameter <os></os> <arch></arch> <channel-label> </channel-label> <errata-id> </errata-id> Description Enter the operating system for the channel label. Enter the architecture for the channel label. Enter the channel label you want to download. Enter a valid Errata ID for the channel label specified in the filter.
Chapter 21
773
To create a filter that downloads the ISO to the repository, use the following syntax:
<update-level-filter> <os></os> <arch></arch> channel-label></channel-label> <update-level></update-level> </update-level-filter> Parameter <os></os> <arch></arch> <channel-label> </channel-label> <update-level> </update-level> Description Enter the operating system for the channel label. Enter the architecture for the channel label. Enter the channel label you want to download. Enter a valid update level for the channel label specified in 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 downloaderConfiguration FilePath rhnUserName rhnPassword
Description Enter the location of the Configuration File used by the patch downloader. Enter the user name required to log onto the Red Hat Network website. Enter the password required to log onto the Red Hat Network website.
774
To list available channels 1 Enter the following command:

redhat_downloader.sh/redhat_downloader.bat -listChannels
To extract packages from ISO 1 Enter the following command:

redhat_downloader.sh/redhat_downloader.bat -extractPackagesFromISO repoLocation patchRepositoryFilePath -isoLocation isoFilePath osArch operatingSystemArchitecture Variable patchRepositoryFilePath isoFilePath operatingSystemArchitecture Description Enter the local location of the patch repository used by the patch downloader. Enter the location of the ISO from which RPMs will be extracted. Enter an operating system/architecture combination; for example, RHES5x86.
To download patches for specific filters 1 Enter the following command:

redhat_downloader.sh/redhat_downloader.bat -configFile downloaderConfigurationFilePath -rhnUser rhnUserName -rhnPass rhnPassword Variable downloaderConfiguration FilePath rhnUserName rhnPassword Description Enter the location of the Configuration File used by the patch downloader. Enter the user name required to log onto the Red Hat Network website. Enter the password required to log onto the Red Hat Network website.
To print out help for the Patch Downloader 1 Enter the following command:
redhat_downloader.bat/redhat_downloader.sh -help
Chapter 21
775
To print out version information for the Patch Downloader 1 Enter the following command:
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> <protocol>http</protocol> <port>8080</port> <host>IPAddress</host> <username>patch</username> <password>patch</password> <domain-name /> <proxy-type>ntlm</proxy-type> </proxy-settings> <temporary-location>c:\tmp</temporary-location> <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>
776
<subscription> <errata-type-filter> <os>RHES5</os> <arch>x86</arch> <channel-label>rhel-i386-server-5</channel-label> <errata-severity> <critical>true</critical> <high>true</high> <moderate>true</moderate> <low>true</low> </errata-severity> <errata-type> <security>true</security> <bugfix>true</bugfix> <enhancement>true</enhancement> </errata-type> </errata-type-filter> <errata-ids> <os>RHES5</os> <arch>x86</arch> <channel-label>rhel-i386-server-5</channel-label> <errata-ids> <errata-id>RHSA-2009:0429</errata-id> <errata-id>RHBA-2009:0388</errata-id> </errata-ids> </errata-ids-filter> <update-level-filter> <os>RHES5</os> <arch>x86</arch> <channel-label>rhel-i386-server-5</channel-label> <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.
Chapter 21
777
To create a repository 1 Enter the following command:

redhat_downloader.sh -createRepo -srcLocation locationOperSysArch repoLocation repositoryPath
This command using the following variables:

Command -srcLocation Variable syntax for the command 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 patch catalog is how you maintain and work with the patch repository through 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 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:

778

In the following procedure, you establish that the catalog operates in Offline 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.
To define catalog parameters 1 Right-click a folder in the Depot and choose New => Patch Catalog => RedHat Linux
Patch Catalog.
2 Enter a name and description and then, click Next.

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 will be copied to the catalog automatically. Metadata and Payload Repository Location (NSH Path)* Browse to or enter the NSH path to the location where the 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.
Chapter 21
779

RBAC Policy
NOTE
For more information on Network URL syntax, see URL syntax for network data transmission on page 362
Adding filters
Filters are used to limit the amount of information brought into the catalog from the repository. Use this procedure to recreate the same filters defined in the configuration file used by the Patch Downloader utility. 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 782.
780

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 By Errata Type Options

Bug Fix Advisory Product Enhancement Advisory Security Advisory Errata Severity: Choose Critical, Moderate, Important and/or Low.
By Errata Advisory By Update Level
Enter an Errata Advisory number and click Add. A list of added advisories is displayed under Included Items. Enter an Update Level identifier; only one can be included for each filter.


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 RedHat Network website.
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.
Chapter 21
781
Schedules can be defined either when the catalog is created or later, when editing the catalog.

JOB_PART_TIMEOUT


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:
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 764. 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.
782
Schedules: For more information, see Scheduling updates to the catalog on page 768. 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 782. Results: Results of all jobs run using the patch catalog are shown here.

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 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.
You can view the contents of a smart group in the left pane or right-click and select
For more information on smart groups, see Managing BMC BladeLogic resources on page 84.


Updating an existing 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, a payload is also downloaded for newly added patches. Patches that do not match the filtering criteria are marked as irrelevant.
Chapter 21
783
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 an analysis job or by a BLPackage. To clean up the catalog and remove these patches, right-click the catalog and select Remove Irrelevant Patches.
Right-click the Red Hat Enterprise Linux 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

3 Click Close.
784

To create a patching job 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.
Chapter 21
785
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:
Save package(s) in
786
click Next.
14 Click Finish.
TIP

Chapter 21
787

The results summary shows 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 are available within the results view and 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 such as 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. On the right side of the pane, statistics are displayed including how many missing RPMs and patches 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 lists every missing patch discovered during analysis together with architecture, whether the patch is recommended by RedHat Network 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, Deploy Selected Patches, or Open Patch. Server View organizes target servers included in the job according to two sub-categories, Failed Targets and Successful Targets. Target servers included in the job are grouped into ranges known as buckets and within these ranges, target servers are listed individually including the number of Missing RPMs, Missing Patches, 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, Export or Remediate All Servers.
Analysis Run at date time
Object View
Server View

Action Show Job Description Opens a read-only view of the job definition including parameter definitions, analysis options, targets, default notifications, and schedules. 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. Updates the display for the selected job to reflect the jobs current status.
Delete
Refresh
788
Action Execute Against Failed Targets
Description Select to run the job again against target servers that returned either warnings, errors or failures. The application displays the list of failed servers. Select the Create Execution Task check box and click OK. Results are shown on the right side of the workspace. Rightclick the job results and select Show Log. Messages generated by BMC BladeLogic while the job was running are displayed. Exports the log as a CSV file to a location on the same computer from which you initiated the Export Log command.
Show Log
Export Log
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. Open Patch Remediate All Servers Opens the Depot Software Properties box with a two-page, read-only description of the metadata for the selected patch. 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.


Chapter 21
789
Remediating servers
Remediating servers

Save package in
790
Remediating servers

click Next.
NOTE
12 Click Finish.
Chapter 21
791


Deploying patches
NOTE
WARNING
Although an undo option is available for deployed patches, BMC neither supports nor recommends this action for the Red Hat Enterprise Linux platform. The undo option, which depends on platform-specific operating system commands, can compromise the target server.
792
Patch reporting
Patch reporting
Chapter 21
793
Patch reporting
794
Chapter
22
Patch management for SUSE Linux Enterprise

22
This chapter describes the patch management process for servers operating on a SUSE Linux Enterprise 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. A simplified version of the patching process is as follows:
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. The repository is used for analysis, packaging and deployment. For more information, see Viewing published patches on page 799.
Analyze your target servers to determine the payload that needs to be deployed to those servers. 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 roll out can be automatically performed at the end of patch analysis or separately, at a later time.) 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 SUSE Linux Enterprise servers in your organization.
Chapter 22
795

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 patch administrator or split between team members. A patch administrator for SUSE Linux Enterprise should have the following permissions:
Role and ACL Policy definitions are made using the role-based access control utility (RBAC). For more information, see Managing authorizations on page 147.
796


User Name
4 Click the SUSE Linux tab.
Chapter 22
797
Description Defines a default batch size used for parallel processing 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. In most cases, the default value should not be changed.
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. In most cases, the default value should not be changed. 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. Results show the job as failing. Continue: Ignore the failure. The Deploy Job continues and the results show the job as failing.
If BMC BladeLogic fails to connect to a vendor site on the first try, specify the number of attempts made before reporting failure. Specify the length of time, expressed in milliseconds, that BMC BladeLogic will wait before making another attempt to connect to the vendor site. Defines a job timeout ratio, patching (x) to remediation (y), 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. Defines a job part timeout ratio, patching (x) to remediation (y), 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.
798
Parameters Patch deploy success return codes
Description The Deploy Job sends commands to the operating system which in turn sends responses back to BMC BladeLogic indicating that the commands succeeded. 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 success return codes. The Deploy Job sends commands to the operating system which in turn sends responses back to BMC BladeLogic indicating that the commands failed. 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 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 codes The Deploy Job sends commands to the operating system 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.
5 Click Save.

The process of deciding which patches available from the vendors need to be applied to your SUSE Linux Enterprise servers is known as patch sourcing and starts 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 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.
Chapter 22
799
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. 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 the RPMs using the Patch Downloader utility provided by BMC BladeLogic. 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.
NOTE
The server which houses the patch repository must have the createrepo and pythonurlgrabber packages pre-installed before downloaded patches into the repository.
800

The Patch Downloader utility provided by BMC BladeLogic 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 SUSE Linux Enterprise website. The steps to follow are defined in the following procedures:

The following additional procedures are also provided:
For a command which will extract RPM packages from the ISOs, see To extract packages from ISO on page 804. For a command that will download patches by defined filters, see To download patches for specific filters on page 804. For a command that will print out available help files, see To print out help for the Patch Downloader on page 804. 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 804.
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-suse-downloader-config.xml). For more information, see Configuration file on page 805.
Chapter 22
801
<port></port> <host></host> <username></username> <password></password> <domain-name></domain-name> <proxy-type></proxy-type> Parameter <port></port> <host></host> <username></username> <password></password> <domain-name></domainname> Description Defines the port number used to communicate with the proxy server. Defines the IP address or host name of the proxy server. Defines the user name required to log onto the SUSE Linux Enterprise website. Defines the password used to log onto the SUSE Linux Enterprise website. Defines the domain name of the proxy server.

NLTM NLTM-V2 Squid
802
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> <username></username> <password></password> </os-arch-filter> Parameter <os></os> <arch></arch> <url></url> <username></username> <password></password> Description Enter the operating system for the channel label. Enter the architecture for the channel label. Enter the URL for the vendor site. Enter the user name assigned for access to the vendor site. Enter the password for the user name required to access the vendor site.
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.
Chapter 22
803
Variable downloaderConfiguration FilePath
Description Enter the location of the Configuration File used by the patch downloader.

suse_downloader.sh -extractPackagesFromISO -repoLocation patchRepositoryFilePath -isoLocation isoFilePath -osArch operatingSystemArchitecture Variable patchRepositoryFilePath isoFilePath operatingSystemArchitecture Description Enter the local location of the patch repository used by the patch downloader. Enter the location of the ISO from which RPMs will be extracted. Enter an operating system/architecture combination; for example, SLES10x86.
To download patches for specific filters 1 Enter the following command:

suse_downloader.sh/suse_downloader.bat -configFile downloaderConfigurationFilePath Variable downloaderConfigurationFilePath Description 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
804
Configuration file
The sample-suse-downloader-config.xml file is shown below:
<suse-downloader-config> <config> <proxy-settings> <protocol>http</protocol> <port>8080</port> <host>ipAddress</host> <username>patch</username> <password>patch</password> <domain-name /> <proxy-type>ntlm</proxy-type> </proxy> </proxy-settings> <temporary-location>c:\tmp</temporary-location> 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> <os-arch-filter> <os>SLES10</os> <arch>x86</arch> <url>https://nu.novell/repo/$RCE/SLES10-Updates/sles-10x86/rpm/</url> <username>abs</username> <password>suse1234</password> </os-arch-filter> </subscription> </suse-downloader-config>

Chapter 22
805

suse_downloader.sh -createRepo -srcLocation locationOperSysArch repoLocation repositoryPath
suse_downloader.sh -createRepo -srcLocation /repo/suse_repo_repo1.SLES10x86;/repo/suse_repo2,SLES9-x86 -repoLocation /repo/suse_new_repo
EXAMPLE

Command -srcLocation Variable syntax for the command 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 was 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 patch catalog is how you maintain and work with the patch repository through 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 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.

806

To define catalog parameters 1 Right-click a folder in the Depot and choose New => Patch Catalog => SuSE Linux
Patch Catalog.

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 will be copied to the catalog automatically. 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 repository location (NSH path)* Browse to or enter the NSH path to the location where the 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.
Chapter 22
807

RBAC Policy
NOTE
For more information on Network URL syntax, see URL syntax for network data transmission on page 362.
Adding filters
Filters are used to limit the amount of information brought into the catalog from the repository. Use this procedure to recreate the same filters defined in the configuration file used by the Patch Downloader utility. 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 811.
808

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.


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 SUSE Enterprise Linux website.
Chapter 22
809

JOB_PART_TIMEOUT

810

Once created, you can open the SUSE Linux Enterprise 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 a patch catalog on page 800. 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. Schedules: For more information, see Scheduling updates to the catalog on page 809. 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 810. Results: Results of all jobs run using the patch catalog are shown here.

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 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. 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 RPM as well as associated Patches. For more information on smart groups, see Managing BMC BladeLogic resources on page 84.
Chapter 22
811

For an offline catalog, the following procedures help you maintain the catalog. Choose from one of the following:


A catalog update will regenerate 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 an analysis job or by a BLPackage. To clean up the catalog and remove these patches, right-click the catalog and select Remove Irrelevant Patches.
Right-click the SUSE Linux Enterprise 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

3 Click Close.

Analysis: The patching job checks the configuration of target servers and determines which patches are needed. (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. 7 Select the analysis option. Choose either:

Install Mode Update Mode
Chapter 22
813
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:
Save package(s) in
10 Click Next. 11 Define the target server list and click Next.
814
12 Define the default job notifications you want to be sent out on job completion and
click Next.
14 Click Finish.
TIP
15 Viewing results of a patching job


The results summary shows 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 are available within the results view and 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 such as 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. On the right side of the pane, statistics are displayed including how many missing RPMs and patches were discovered during analysis as well as how many target servers were 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.
Chapter 22
815
Object View
Object View lists every missing patch discovered during analysis together with architecture, whether the patch is recommended by SUSE Enterprise Linux website, whether it is a security patch, as well as a description of the patch. Rightclick on any patch within Object View and perform one of the following actions: Add to Depot As => BLPackage or Open Patch. Server View organizes target servers included in the job according to two sub-categories, Failed Targets and Successful Targets. Target servers included in the job are grouped into ranges known as buckets and within these ranges, target servers are listed individually including the number of Missing RPMs, Missing patches, 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, Export or Remediate All Servers.
Server View

Delete
Show Log
Export Log
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.
816
Action Open Patch Remediate All Servers
Description Opens the Depot Software Properties box with a two-page, read-only description of the metadata for the selected patch. 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.


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 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.
Chapter 22
817
Remediating servers
To remediate a server 1 At the end of analysis, right-click the patching job and choose 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

Save package in

Option Save batch/deploy job(s) in ACL Policy for Package(s)/Deploy Job(s) Deploy Job Options Description Enter or browse to a job folder where the batch and deploy jobs created by the remediation job will be stored. Browse to and select the ACL Policy which will assign predefined permissions to each BLPackage, Deploy Job and Batch Job created by the remediation job. Select a set of pre-defined parameter definitions that will be applied to each Deploy Job created by the Remediation Job.
818
Remediating servers
9 In Deploy Job Properties, enter the following information:

Option Results Retention Time Max_Parallel_Per_VM_Host Job_Timeout Job_Part_Timeout Description Expressed in number of days, defines the length of time that BMC BladeLogic retains a job run and result information. Defines the maximum number of parallel work items processed per Virtual Machine host. Expressed in number of minutes, defines the length of time a job should run before being automatically cancelled. Expressed in number of minutes, defines the length of time that the job part/work item should run before being automatically cancelled. Expressed in number of seconds, defines the length of time a URL copy command should run before being automatically cancelled. Expressed in seconds, defines the length of time a NSH command should run before being automatically cancelled.
Deploy_Job_URL_Copy_ Timeout Deploy_Job_NSH_CMD_ Timeout
click Next.
NOTE
13 Click Finish.
Chapter 22
819


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
Although an undo option is available for deployed patches, BMC neither supports nor recommends this action for the SUSE Linux Enterprise platform. The undo option, which depends on platform-specific operating system commands, can compromise the target server.
820
Patch Reporting
Patch Reporting
Chapter 22
821
Patch Reporting
822
Chapter
23
Patch management for Oracle Enterprise Linux

23
This chapter describes the patch management process for servers operating on an Oracle 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. A simplified version of the patching process is as follows:
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. The repository is used for analysis, packaging and deployment. For more information, see Viewing published patches on page 827. Analyze your target servers to determine the payload that needs to be deployed to those servers. 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 roll out can be automatically performed at the end of patch analysis or separately, at a later time.) 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 Oracle Enterprise Linux servers in your organization.
Chapter 23
823

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 patch administrator or split between team members. A patch administrator for Oracle Enterprise Linux should have the following permissions:
Role and ACL Policy definitions are made using role-based access control (RBAC). For more information, see Managing authorizations on page 147.
824


User Name
4 Click the Oracle Enterprise Linux tab.
Chapter 23
825
Description Defines a default batch size used for parallel processing 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 specifically required.
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:

If BMC BladeLogic fails to connect to a vendor site on the first try, specify the number of attempts made before reporting failure. Specify the length of time, expressed in milliseconds, that BMC BladeLogic will wait before making another attempt to connect to the vendor site. Defines a job timeout ratio, patching (x) to remediation (y), 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. Defines a job part timeout ratio, patching (x) to remediation (y), 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.
826
Parameters Patch deploy success return codes
Description The Deploy Job sends commands to the operating system which in turn sends responses back to BMC BladeLogic 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 BladeLogic. Unknown codes entered in this field are defined to BMC BladeLogic as success return codes.
The Deploy Job sends commands to the operating system which in turn sends responses back to BMC BladeLogic indicating that the commands failed. This field instructs BMC BladeLogic to interpret the given exit code(s) as a failure. 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 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. This field instructs BMC BladeLogic to interpret the given exit code(s) as a warning. 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 codes The Deploy Job sends commands to the operating system which in turn sends back a request for reboot to BMC BladeLogic. This field instructs BMC BladeLogic to interpret the given exit code(s) as a request for a reboot. 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.
5 Click Save.

The process of deciding which patches available from the vendors need to be applied to your Oracle Enterprise Linux servers is known as patch sourcing and starts with creation of a patch catalog.
Chapter 23
827
A patch repository is a physical location on a network server which contains the 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 airgapped environment. Download always occurs prior to analysis using a BMCsupplied 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 BladeLogic. The essential steps required to create an offline catalog are as follows:

Define filters for repository content in the configuration file. 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, 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.
NOTE
828

The Patch Downloader utility provided by BMC BladeLogic 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 Oracle website. The steps to follow are defined in the following procedures:

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. For a command which will extract RPM packages from the ISOs, see To extract packages from ISO on page 832. For a command that will print out available help files, see To print out help for the Patch Downloader on page 832. 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 833.
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-oel-downloader-config.xml). For more information, see Configuration file on page 833.
Chapter 23
829
<port></port> <host></host> <username></username> <password></password> <domain-name></domain-name> <proxy-type></proxy-type> Parameter <port></port> <host></host> <username></username> <password></password> <domain-name></domainname> Description Defines the port number used to communicate with the proxy server. Defines the IP address or host name of the proxy server. Defines the user name required to log onto the Oracle Enterprise Linux website. Defines the password used to log onto the Oracle Enterprise Linux website. Defines the domain name of the proxy server.
<proxy-type></proxy-type> Select the type of proxy server used. Choose either:

NLTM Squid
830
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> Parameter <os></os> <arch></arch> <channel-label> </channel-label> Description Enter the operating system for the channel label. Enter the architecture for the channel label. Enter the channel label you want to download.
sh oel_downloader.sh -configFile downloaderConfigurationFilePath oelUser oelUserName -oelPass oelPassword Parameter downloaderConfiguration FilePath oelUserName oelPassword Description Enter the location of the Configuration File used by the patch downloader. Enter the user name required to log onto the Oracle Enterprise Linux website. Enter the password required to log onto the Oracle Enterprise Linux website.
Chapter 23
831
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 1 Enter the following command:

oel_downloader.sh/oel_downloader.bat -listChannels -oelUser oelUserName -oelPass oelPassword Parameter oelUserName oelPassword Description Enter the user name required to log onto the Oracle Enterprise Linux website. Enter the password required to log onto the Oracle Enterprise Linux website.

oel_downloader.sh -extractPackagesFromISO -repoLocation patchRepositoryFilePath -isoLocation isoFilePath -osArch operatingSystemArchitecture Parameter patchRepositoryFilePath isoFilePath operatingSystemArchitecture Description Enter the local location of the patch repository used by the patch downloader. Enter the location of the ISO from which RPMs will be extracted. Enter an operating system/architecture combination; for example, OELES5x86.
oel_downloader.bat/oel_downloader.sh -help
832
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> <username>patch</username> <password>patch</password> <domain-name /> <proxy-type>ntlm</proxy-type> </proxy> </proxy-settings> <temporary-location>c:\tmp</temporary-location> 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> <os-arch-filter> <os></os> <arch></arch> <channel-label></channel-label> </subscription> </oel-downloader-config>

Chapter 23
833

oel_downloader.sh -createRepo -srcLocation locationOperSysArch repoLocation repositoryPath
oel_downloader.sh -createRepo -srcLocation /repo/oel_repo1,OEL5x86;/repo/oel_repo2,OEL4-x86 -repoLocation /repo/oel_new_repo
EXAMPLE

Command -srcLocation Variable syntax for the command 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 was 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 patch catalog is how you maintain and work with the patch repository through 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 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.

834

To define catalog parameters 1 Right-click a folder in the Depot and choose New => Patch Catalog => OEL Linux
Patch Catalog.

3 In the Catalog Mode section, select Source from Disk Repository (Offline Mode). 4 In Repository Options, enter the following:
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 will be copied to the catalog automatically. 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 repository location (NSH path)* Browse to or enter the NSH path to the location where the 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.
Chapter 23
835
5 In Depot Object Options, enter the following:

(default) Copy to agent at staging: The BMC BladeLogic 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 NSH-accessible network location where patch payloads are stored.(See also Network URL for payload deployment.)
Enter an NSH-accessible path to a location where the payload 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. Browse to select a pre-defined ACL Policy. Permissions defined by the ACL Policy will be assigned to all Depot Objects created in the catalog.To create an ACL Policy, use the RBAC Manager.
Object Policy Permissions
NOTE
For more information on Network URL syntax, see URL syntax for network data transmission on page 362.
Adding filters
Filters are used to limit the amount of information brought into the catalog from the repository. Use this procedure to recreate the same filters defined in the configuration file used by the Patch Downloader utility. Filters can be defined during catalog creation or later, when editing the catalog (for more information, see Adding filters on page 836).
836

2 In OS Flavor, select from the list provided.

Operating system (OS) and Architecture are supplied automatically in read-only boxes.


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 Oracle website.
Chapter 23
837

JOB_PART_TIMEOUT

838

Once created, you can open the Oracle Enterprise Linux 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 a patch catalog on page 828. 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. Schedules: For more information, see Scheduling updates to the catalog on page 837. 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 838. Results: Results of all jobs run using the patch catalog are shown here. For more information, see Viewing results of a patching job on page 843 and Viewing remediation results on page 848.

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 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.
Open to view properties of a particular RPM as well as associated Patches.
You can view the contents of a smart group in the left pane or right-click and select
For more information on smart groups, see Managing BMC BladeLogic resources on page 84.
Chapter 23
839

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

840
3 Click Close.

Analysis: The patching job checks the configuration of target servers and determines which patches are needed. (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

Chapter 23
841
Creating a patching job Clear Execution Override: The user and role which scheduled the job will be the
6 Click Next. 7 Select the analysis option. Choose either:

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 Auto Remediate Description Select when remediation should occur once analysis completes. All options displayed are available only when Auto Remediate is selected. 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. 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. 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 displayed.
Save package(s) in
842
Option ACL Policy for Package(s)/Deploy Job(s) Deploy Job Options
Description Browse to and select the ACL policy which will be assigned to each BLPackage, Deploy Job, and Batch Job created by the patching job. Select a set of pre-defined, parameter definitions that will be applied to each Deploy Job created by the patching job.
click Next.
14 Click Finish.
TIP

Chapter 23
843

The results summary shows 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 such as 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. On the right side of the pane, statistics are displayed including how many missing RPMs and patches were discovered during analysis as well as how many target servers were scanned and not scanned. Right-click on this line and perform one of the following actions: Refresh, Show Log, or Export Log. Object View lists every missing patch discovered during 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. Server View organizes target servers included in the job according to two sub-categories, Failed Targets and Successful Targets. Target servers included in the job are grouped into ranges known as buckets and, within these ranges, target servers are listed individually, including the number of Missing Bulletins, Missing Hotfixes, and final Status. Rightclick 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, Export or Remediate All Servers.
Object View
Server View

Action Show Job Description Opens a read-only view of the job definition including parameter definitions, analysis options, targets, default notifications, and schedules. 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. Updates the display for the selected job to reflect the jobs current status.
Delete
Refresh
844
Action Execute Against Failed Targets
Description Select to run the job again against target servers that returned either warnings, errors or failures. The application displays the list of failed servers. Select the Create Execution Task check box and click OK. Results are shown on the right side of the workspace. Rightclick the job results and select Show Log. Messages generated by BMC BladeLogic while the job was running are displayed. Exports the log as a CSV file to a location on the same computer from which you initiated the Export Log command.
Show Log
Export Log
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. Open Patch Remediate All Servers Opens the Depot Software Properties box with a two-page, read-only description of the metadata for the selected patch. 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.


Chapter 23
845
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. However, when analysis results indicate that patches are missing, you can choose to remediate the target server using the following procedure.
Set Execution Override: The Patch Remediation 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

Option Package Name Prefix Description 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. 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.
Save package in
846
Remediating servers

Option Save batch/deploy job(s) in ACL Policy for Package(s)/Deploy Job(s) Deploy Job Options Description Enter or browse to a job folder where the Batch and Deploy Jobs created by the remediation job will be stored. Browse to and select the ACL policy which will assign predefined permissions to each BLPackage, Deploy Job and Batch Job created by the remediation job. Select a set of pre-defined parameter definitions that will be applied to each Deploy Job created by the remediation job.
click Next.
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.
Chapter 23
847


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
Although an undo option is available for deployed patches, BMC neither supports nor recommends this action for the Oracle Enterprise Linux platform. The undo option, which depends on platform-specific operating system commands, can compromise the target server.
848
Patch reporting
Patch reporting
Chapter 23
849
Patch reporting
850
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 Intelbased 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.
Chapter 24
Provisioning basics
851
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
852
Provisioning Windows and Linux servers: PXE environment

target machine being provisioned
1
DHCP Server
3
PXE / TFTP Server
database
6
Application Server
database
9
HTTP or SMB Server
10
11
BMC BladeLogic console
12
12
Chapter 24
Provisioning basics
853
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 upto-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.
854
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.
Chapter 24
Provisioning basics
855
Provisioning Solaris servers: JumpStart environment

BMC BladeLogic environment BMC BladeLogic console JumpStart environment SPARC target being provisioned
3
boot JumpStart boot server
create system package define data store instance import target device start provisioning job
2
JumpStart config server
4
obtain config files
5
JumpStart install server obtain OS files and run installer
6
BMC BladeLogic console install agent
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.
856
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
Chapter 24
Provisioning basics
857
Provisioning AIX servers: NIM environment
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 BMC BladeLogic console Target being provisioned NIM master
2 3 4 5
Application Server
Batch Job for additional configuration BMC BladeLogic console
858
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
where you store sets of installation files that are used for provisioning operating systems.
C Register the target devices MAC address (and optional additional information)
with the BMC BladeLogic system by importing the device.
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.
Chapter 24
Provisioning basics
859
Provisioning HP-UX servers: Ignite environment


BMC BladeLogic environment BMC BladeLogic console Target being provisioned Ignite master
2 3 4 5
Application Server
Batch Job for additional configuration BMC BladeLogic console
860
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
where you store sets of installation files that are used for provisioning operating systems.
C Register the target devices MAC address (and optional additional information)
with the BMC BladeLogic system by importing the device.
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.
Chapter 24
Provisioning basics
861
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
862
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

provisioning process. 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.
Chapter 24
Provisioning basics
863
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: running the provisioning process (PXE) Part two: completing the provisioning process (JumpStart, NIM, Ignite)
Part two: running the provisioning process (PXE)

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.
864
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.
Chapter 24
Provisioning basics
865
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.
866
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.
Chapter 25
867
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... Windows machines You need to create... 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.
868
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. 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.
NOTE
Creating a WinPE 2.x boot image file

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.)
Chapter 25
869
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:
870
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:
Chapter 25
871
Creating a WinPE 2.x boot image file 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
\Tools\PETools
CreateWinPE2_x.vbs and extractpxeboot.bat to the WAIK installation subdirectory:
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.
872
Creating a WinPE 2.x boot image file 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. to select the directory. The
Type the full path for the directory or click Browse 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:
Chapter 25
873
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 to select a location. Use which you want the image created, or click Browse 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 to select want to inject into the image, for Open Driver.txt file, click Browse 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.
874
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.
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.
Network Details: Specifies the path to the network.ini file. This file contains the
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.
Chapter 25
875
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 to select the file. the file name) or click Browse
876
Creating a WinPE 2.x boot image 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 directory.
to select the
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
Chapter 25
877
Creating a WinPE 2.x boot image file [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 caseinsensitive. 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.
878
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.
Parameter Arch BLDir Description (Required) Specifies the architecture of the server for which you are creating the boot image (x86 or x64). (Required) Specifies the full path to the \provisioning\winpe subdirectory, for example: C:\BMC_BL\provisioning\winpe (Required) Specifies the path to the temporary local directory to hold the image files you are about to create. For example: C:\BMC_BL\tmp This directory must already exist before you run the CreateWinPE2_x.vbs script. BootDir (Required) Specifies the boot image name, for example: boot_2_0_x86 or boot_2_0_x64. This name is also the name of the directory containing the image files. Note: Names containing spaces are not supported. In general, you can set BootDir to: boot_2_0 so that you can use the default placeholders in provisioning. When you run CreateWinPE2_x.vbs, it creates a directory in the path specified by DestDir. This new directory has the name specified by BootDir and contains the image files. CustomScript (Optional) Specifies the path to an optional external script that you want to run when the image is mounted. Specify the scripts full path and name. (Optional) If DestDir already exists and you want to overwrite it, specify OverwriteFlag=Y
DestDir
OverwriteFlag
Chapter 25
879
Parameter RSCDDir
Description (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 (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 (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.
BMIWinExe
CopyToISO
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.
880
Parameter AppServerPort
Description (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.)
Chapter 25
881
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
882
Creating a WinPE 2.x boot image file 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 CreateWinPE2_x.vbs script. 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.
Chapter 25
883
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.)
884
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.
Chapter 25
885
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) imagex utility comes with WAIK.) Example:
1 Use the imagex utility to mount the WinPE image to any empty directory. (The
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
886
Creating a WinPE 1.6 image file
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
Chapter 25
887
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. machine where you will be creating the image file using the following steps:
3 Download and install Microsoft Windows Server 2003 Resource Kit on the 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
888
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 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 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 Preinstallation Environment (WinPE) 2005 during step 1. Using the default location from those instructions, you would put Driver.txt in the following location:
Chapter 25
889
Creating a WinPE 1.6 image file 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 provisionfiles.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

C:\BMC_BL\provisioning\winpe
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.
890
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). as described in Extracting boot files for WinPE 1.6 images on page 898.
11 Extract the ntldr, ntdetec.com, and startrom.0 files and copy them to the TFTP server, 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:
Tools.
In the Main Product Install Options section, choose Windows XP Embedded SP1 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.
Chapter 25
891
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
892
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:

C:\BMC_BL\WinPE_1.6\WINPE
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] Set this to x86. This is the full path of the directory where you unzipped provision-files.zip, for example: C:\BMC_BL\provisioning\winpe 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.
architecture installDirectory
Chapter 25
893
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 Note: Pathnames containing spaces are not 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. Note: Pathnames containing spaces are not 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. CreateWinPE1_6.bat x86 C:\BMC_BL\provisioning\winpe 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.
Example command syntax:
894
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:
C:\tftproot\boot_1_6
(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:
C:\tftproot\boot_1_6
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:

C:\BMC_BL\WinPE_1.6\WINPE
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] Set this to amd64.
architecture
Chapter 25
895
To create and place an AMD64 WinPE 1.6 image... installDirectory This is the full path of the directory where you unzipped provision-files.zip, for example: C:\BMC_BL\provisioning\winpe 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 Note: Pathnames containing spaces are not 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 Note: Pathnames containing spaces are not 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. Note: Pathnames containing spaces are not 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
896
To create and place an AMD64 WinPE 1.6 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. CreateWinPE1_6.bat amd64 C:\BMC_BL\provisioning\winpe C:\ENGLISH\64BIT\STANDARD_WITH _SP2_VLP C:\BMC_BL\tmp\WinPE1_6_amd64\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.
Example command syntax:
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
Chapter 25
897
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.
898
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 You can get this file the same way you get external-files.zip. For detailed information, see the BMC BladeLogic Installation Guide. 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.
Chapter 25
899
To create an x86 Gentoo image... General syntax location
gentooMinimalIsofile outDirectory
mkgen2img.sh location/x86/bmi32
This is the full path the /provisioning/linux subdirectory, for example: /tmp/bmc_bl/provisioning/linux
gentooMinimalIsofile
This is the full path to the minimal ISO file you downloaded from the Gentoo site, for example: /tmp/bmc_bl/install-x86-minimal2007.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.0r1.iso /tftproot/x86pc/pxelinux
(Type this command all on one line.)

This command creates the files gentoo and gentoord.gz, which collectively make up the Gentoo image file entity.
To create an AMD64 Gentoo image... General syntax location
gentooMinimalIsofile outDirectory
mkgen2img.sh location/amd64/bmi64
This is the full path the /provisioning/linux subdirectory, for example: /tmp/bmc_bl/provisioning/linux
gentooMinimalIsofile
This is the full path to the minimal ISO file you downloaded from the Gentoo site, for example: /tmp/bmc_bl/install-x86-minimal2007.0-r1.iso
900
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.0r1.iso /tftproot/x86pc/pxelinux (Type this command all on one line.) This command creates the files gentoo and gentoord.gz, which collectively make up the Gentoo image file entity.
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 PreInstall 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:
Chapter 25
901
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. would.
2 Create the system package and create and run the Provision Job as you normally
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. required support components:
Prerequisite: Before configuring for one of these technologies, you must install
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.
902
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 PXE Tasks 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 Configuring the data store Creating custom system package types (optional) Changing the location of installation files Configuring the data store Creating custom system package types (optional) Changing the location of installation files Configuring the data store Creating custom system package types (optional) Changing the location of installation files
JumpStart
NIM
Ignite

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:
Chapter 25
903
1 Choose Configuration => Property Dictionary View. 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. in the right panel.
3 You need to create at least one instance of a data store, so click the Instances tab
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.
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:
Property Name
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.
904
Property Name FULL_PATH
Description 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.
Chapter 25
905
Property Name USERNAME PASSWORD
Description Provides the user name and password needed to access the data 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.) Full path to the Jumpstart root folder on the boot server. (For WAN boot installation) The path to the document root directory of the web server on the boot server. (For WAN boot installation) The URL through which the document root directory can be accessed via HTTP. (For WAN boot installation) The path to the cgi-bin directory on the boot server. (For WAN boot installation) The URL through which the cgi-bin directory on the install server can be accessed via HTTP. 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.) Full path to the configuration root on the configuration 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.) Full path to the installers on the install server. This is the full path to the directory that functions as a data store. (For WAN boot installation) The full path to the document root directory of the web server on the install server. (For WAN boot installation) The URL through which the document root directory can be accessed via HTTP.
BOOT_SERVER_FULL _PATH
BOOT_SERVER_DOCUM ENT_ROOT_PATH
BOOT_SERVER_URL BOOT_SERVER_CGI _BIN_PATH BOOT_SERVER_CGI _BIN_URL CONFIG_SERVER
CONFIG_SERVER _FULL_PATH INSTALL_SERVER
INSTALL_SERVER _FULL_PATH
INSTALL_SERVER_DOC UMENT_ROOT_PATH
INSTALL_SERVER _URL
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.
906
Creating custom system package types
Property Name
Description
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. 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 subfolders 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). 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. 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 subfolders and files as necessary.
STAGING_DIR_PATH
IGNITE_SERVER
STAGING_DIR_PATH

Applies to: PXE, JumpStart, NIM, Ignite 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.
Chapter 25
907
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 Configuring the data store on page 903). 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.
908
The fields for each operating system are shown in the table.
Operating System Windows
Field Windows 2008 only:
Description 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 OS installer location Name of the system package type. 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 C:\Program Files\BMC Software\BladeLogic\8.0\PXE you would enter pxestore\win2k. RSCD agent installer location Directory where the installer for the RSCD agent resides.
Chapter 25
909
Operating System
Field Initial partition size (MB)
Description Size of the initial disk partition (in MB). Default: 2000 Set this value according to Microsofts available disk space recommendations for the operating system type. To ensure that the operating system installation completes successfully, the provisioning process requires the following values for initial partition size:
For Windows 2008 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).
910
Operating System Red Hat, VMWare ESX, SUSE Linux
Field SUSE Linux only: SUSE/SLES Version 10.x or higher Red Hat only: RHAS 5 or Higher
Description Check this box if this system package type is for SUSE/SLES Version 10.x or higher. Then from the drop-down menu, select the SUSE/SLES version. Check this box if this system package type is for RHAS version 5 or higher.
VMWareESX only: ESX Select the VMware ESX version from the dropversion down menu. System package type OS installer location Name of the system package type. 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 and the root directory of the data store is C:\Program Files\ BMC Software\BladeLogic\8.0\PXE\ you would enter pxestore\RedHat_Advanced_Server_3_0 RSCD agent installer location Boot kernel file name Boot image file name Directory where the installer for the RSCD agent resides. For Boot kernel file name, enter the 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 initrdeverything.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 BladeLogic Installation Guide.
Chapter 25
911
Field Solaris architecture
Description Indicate the type of machine you plan to provision with this system package type by clicking either SPARC or x86. Name of the system package type. Relative path to the Tools directory of the installer tree. The location you specify should be relative to the data store install server root. For example, if the full path to the Tools directory is /jumpstart/solaris10/Solaris10 (meaning there exists a Tools directory under /jumpstart/solaris10/Solaris10) and the install server root is set up as /jumpstart, then enter solaris10/Solaris10.
System package type OS installer location
Solaris WAN boot only: WAN Boot Parameters Archive location
Miniroot Location
WAN Boot Location
The path to the Solaris Flash archive on the install server, relative to the install server document root directory. The path to the miniroot file on the boot server, relative to the boot server document root directory. The path to the wanboot installation program on the boot server, relative to the boot server document root directory.
Name of the system package type. Name of the NIM Shared Product Object Tree (SPOT) resource. Name of the NIM lpp_source resource. Name of the NIM mksysb resource. The NIM resource you want to use as the primary source for the operating system. Choose one of the following options:

AIX
System package type SPOT name Lpp_source name Mksysb name Bosinst source
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. Name of the system package type. Use Browse to browse to the Ignite index file you want to use for this system package.
System package type Index File
5 Click OK. The information you entered on the System Package Type window
displays on the System package tab.
912
Changing the location of installation files

Applies to: PXE, JumpStart, NIM, Ignite 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 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 Configuring the data store on page 903). 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.
Chapter 25
913
Operating System Windows
Field Windows OS installer location
Description 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 C:\Program Files\BMC 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 SUSE 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 and the root directory of the data store is C:\Program Files\BMC 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.
914
Configuring the PXE server
Field OS installer location
Description 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 Lpp_source name Mksysb name Bosinst source
Name of the NIM Shared Product Object Tree (SPOT) resource. Name of the NIM lpp_source resource. Name of the NIM mksysb resource. 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.
Chapter 25
915
Configuring the TFTP server
1 Choose Configuration => Provisioning Configurations. 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. 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.
6 For Prompt timeout, enter the amount of time the boot prompt displays before the
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.
916
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.
1 Choose Configuration => Provisioning Configurations. 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.
8 Click OK to save the current values. 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.
Chapter 25
917
Starting and stopping the TFTP server
Action Start PXE Server
Windows
Linux
The PXE server is a Windows Type the command: service, so choose Start => /etc/init.d/blpxe start Settings => Control Panel => 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 => /etc/init.d/blpxe stop Settings => Control Panel => 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 Start TFTP Server Windows The TFTP server is a Windows service, so choose Start => Settings => Control Panel => Administrative Tools => Services. Right-click BladeLogic TFTP Server and select Start. Stop TFTP Server The TFTP server is a Windows service, so choose Start => Settings => Control Panel => Administrative Tools => Services. Right-click BladeLogic TFTP Server and select Stop. Type the command: /etc/init.d/bltftp stop Linux Type the command: /etc/init.d/bltftp start
918
Configuring boot image files

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
Used only when working with legacy system packages. gentoo32 Used to provision x86 Linux machines. gentoo64 Used to provision AMD64 Linux machines. Skip Linux Pre-Install Used to provision a device with the Red Hat, VMware ESX, or SUSE operating system when you want to skip the Gentoo pre-installation image. For information, see Using the Skip Linux Pre-Install image on page 901. 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.
blade.img
Chapter 25
919
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:
1 Choose Configuration => Provisioning Configurations. 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.
in the fields as shown in the following table.
This window shows only the fields needed for your chosen operating system. Fill
NOTE
920
Image Type WinPE 2.x WinPE 1.6
Field Image file
Description The name of the image file. Assuming you used the standard BMC BladeLogic image creation 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 Image path
Description of the boot image file. 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. 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.
Set as default image
Chapter 25
921
Image Type Linux
Field Image file
Description 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
Description Kernel name
Description of the boot image file. 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 64 bit image
Command line arguments that the kernel requires at boot time. Check this field if this image is to be used to provision 64 bit machines. Leave it unchecked otherwise. The default image is the image that the system uses for auto-discovery. For example, when an unknown device PXE boots on your network, the system sends this device the default image. Check this field if this is the default image for your environment.
DOS
Image file Description Set as default image
The name that will appear in the boot image drop-down menus in the BMC BladeLogic GUI. Description of the boot image file. The default image is the image that the system uses for auto-discovery. For example, when an unknown device PXE boots on your network, the systems sends this device the default image. Check this field if this is the default image for your environment.
922
Image Type ESXi 4.0
Field Image file
Description 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 Kernel name
(Optional) Description of the image file. 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.
The default image is the image that the system uses for auto-discovery. For example, when an unknown device PXE boots on your network, the system sends this device the default image. Because auto-discovery is not supported for the ESXi 4.0 image, you cannot set this image as the default.
Chapter 25
923
Including a Batch Job in a system package
Image Type
Field
Description The name of the image file. For information on creating this image file, see Provisioning Windows 2003 or 2008 servers from a local data store on page 1044.
WinPE 2.x ISO Image file
Description Image path
(Optional) Description of the file. The tftproot subdirectory that contains this image file. For example, if this image file resides in this TFTP directory: C:\tftproot\boot_2_0 You would set the Image path field to boot.
64 bit image
Check this field if this image is to be used to provision 64 bit machines. Leave it unchecked otherwise. The default image is the image that the system uses for auto-discovery. For example, when an unknown device PXE boots on your network, the system sends this device the default image. Because auto-discovery is not supported for the WinPE 2.x ISO image, you cannot set this image as the default.
4 Click OK to save the current values.
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.
924
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 Windows Linux ESX Solaris AIX HP-UX Relevant Procedure Defining settings for Windows servers on page 927 Defining settings for Linux servers on page 948 Defining settings for ESX servers on page 960 Defining settings for Solaris servers on page 971 Defining settings for AIX servers on page 987 Defining settings for HP-UX servers on page 997
For detailed information on supported operating systems and versions, see the BMC BladeLogic Installation Guide.
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.
Chapter 25
925
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 for system object properties on page 140. 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, see Using the Property Dictionary on page 118).
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
information on defining an ACL, see Defining permissions for a system object on 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.
926
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:
Chapter 25
927
Pre-Install Scripts Windows
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.
Pre-Install Scripts Windows

The BMC BladeLogic system uses the Windows PE DiskPart utility to create WinPEbased 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 Postdisk 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 PreInstall 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%
928
Disk Partition Windows

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:
Chapter 25
929
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 dualboot 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.
930
Post-disk partition Windows
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 .
Post-disk partition Windows

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. 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. This tab also displays a check box, which gives you the option of rebooting the server after those commands execute.
Basic configuration Windows

The Basic Config tab lets you provide local information about a server, such as its name, workgroup, domain, and user account.
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 Autogenerate computer name.
Chapter 25
931
Basic configuration Windows
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.
932
Computer Settings Windows

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. select drivers.
A For configuring PnP or OEM drivers, for PnP driver paths, click Browse
to
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

the PnP or mass storage drivers.
and browse to the data store that contains
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.
Chapter 25 Provisioning servers 933
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.
934
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 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 plugand-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.
Chapter 25
935
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.
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.
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:
936
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.
Chapter 25
937
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.
938
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 Shiftclick 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.
Chapter 25
939
OS components Windows
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.
940
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.
Chapter 25
941
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.
942
Unattend entries Windows
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.
Chapter 25
943
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 reference scripts.
to select a property reference. See Using properties to
4 Click Add to selected node or Replace selected node.
944
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
change or by clicking Select Property and selecting a property reference.
2 In the Add/Replace XML Component area, edit the entry by either typing in the 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.
Chapter 25
945
Post-install configuration Windows
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.
946
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
job requires that there is an agent installed on the server.)
batch job, you must also check Install RSCD agent, because running a post-install
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
properties to reference scripts on page 1063.)
runonce.bat file, or click the Select Property icon to insert a parameter. (See Using
Chapter 25
947
Local properties Windows
The runonce.bat file runs one time when Windows starts for the first time after an unattended installation of the operating system.
Local properties Windows

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

Use this procedure to specify settings for an unattended installation of a server running a Linux 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.
the system package and select Open. 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
948
Pre-install scripts Linux
Network Linux Kickstart entries Red Hat Linux AutoYaST entries SUSE Linux Post-install configuration Linux Local properties Linux
Pre-install scripts 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
Disk partition Linux

The Disk Partition tab lets you define partitions for the servers being provisioned.
Chapter 25
949
Disk partition Linux
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: 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.) 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:
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 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.
950
Basic configuration Linux 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.

Basic configuration Linux

The Basic Config tab lets you provide local information about a server, such as its name and the password needed to access the machine.
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. 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, enter that name in the OM Server Name 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 Root password, enter the password used to access the root account. Then
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.
Computer settings Linux
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.
Computer settings Linux

The Computer Settings tab lets you provide information about peripheral devices and localization settings.
1 Click the Computer Settings tab. 2 Under Device Settings, select the keyboard layout type that you want to be the 3 For Mouse, select a type of mouse that you want to use with the machine. 4 Under Localization, do the following: A For Time zone, do either of the following:
system default. For example, in the United States you would probably select us.
Select a time zone from the drop-down list. Check Use Custom TimeZone and type a time zone in the text box.
952
OS components Linux
B For Locale, select a language option from the drop-down list. For example, in the
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. Click Select Property to display a drop-down menu of available properties. Select the property that contains the installation number. Leave the Installation Number field blank. If you do not enter an installation number (subscription number), the provisioning process installs the core operating system without the packages that require the subscription number. You can install these packages separately when you get the number.
OS components 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.
Chapter 25
953
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
The Network tab lets you provide networking information for a server, such as its IP 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. 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.
954
Kickstart entries Red Hat Linux
Select Obtain DNS server automatically if the DHCP server should provide the addresses for DNS servers. Select Use the following DNS server address if you want to manually configure a DNS server. Then, enter an IP address for DNS Server.
Kickstart entries Red Hat Linux

The Kickstart Entries tab lets you modify the contents of the kickstart file, which is a text file used in unattended installations of Red Hat Linux. When you define a Red Hat Linux system package, your input on the system package tabs is automatically converted into text in the first edit box at the top of the Kickstart Entries tab. If you want to add additional entries for configuration elements that are not covered 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
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 Kickstart file unchecked and add your new entries in the second edit box.
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 Kickstart file. 2 Modify the entries in the first edit box. 3 Then, still in the first edit box, add your additional entries.
AutoYaST entries SUSE Linux
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.

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 ??APP_SERVER_IP?? Description 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. The MAC address of the server being provisioned. 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.
??MAC_ADDRESS?? ??IP_ADDRESS??
956
Token ??SUBNET_MASK??
Description The subnet mask 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. The default gateway that was specified in the Network panel of the system package wizard. This value is overridden during provisioning using the value you enter in the Network panel of the provisioning wizard. The DNS server 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. The computer name that was specified in the Basic Config panel of the system package wizard. This value is overridden during provisioning using the value you enter in the Basic Config panel of the provisioning wizard. The root password that was specified in the Basic Config panel of the system package wizard. This value is overridden during provisioning using the value you enter in the Basic Config panel of the provisioning wizard. The network device that was specified in the Basic Config panel of the system package wizard. This value is overridden during provisioning using the value you enter in the Basic Config panel of the provisioning wizard. 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). 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). 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).
??DEF_GATEWAY??
??DNS_SERVER??
??HOST_NAME??
??ROOT_PASSWORD??
??NET_DEVICE??
??RSCD_DIR??
??DATA_STORE_BASE_DIR??
??DATA_STORE_IP??
Chapter 25
957
Post-install configuration Linux
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, rightclick 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.
Post-install configuration Linux

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 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.
958
Local properties Linux
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. 2 Under Operations Manager Settings, check Install RSCD agent if you want to install
BladeLogic console 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 console 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.
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.
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. install section of the Kickstart or AutoYaST file, or click Select Property a parameter. (See Using properties to reference scripts on page 1063.)
6 Under Post-Install Script, enter any commands that you want added to the post-
to insert
The commands you enter run one time immediately after an unattended installation of the operating system.
Local properties Linux

Chapter 25
959
Defining settings for ESX servers
If you are adding a new property, click Add
If you are modifying an existing property, right-click the name of the property and select Edit from the drop-down menu.
Defining settings for ESX servers

Use this procedure to specify settings for an unattended installation of a server running an ESX 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.
the system package and select Open. A tab for the system package appears in the content editor.
system packages tab. Each tab represents a category of settings, as described in the 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
960
Pre Install Script ESX
Pre Install Script 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 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 name from the list.
4 For Script Contents, do one of the following:
Enter Gentoo Linux commands. Type the name of a local property that contains a script, enclosing the property name with double question marks. Click Select Property to display a drop-down menu of available properties. Select the property that contains the script 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.
Chapter 25
961
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: 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.) 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.
962
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.
Chapter 25
963
Basic configuration ESX
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. 2 Under Local Settings, do the following:
964
A For Computer name, enter a unique name that should be assigned to the server. 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, 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. 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.
3 Under Provisioning Settings:
For Kickstart network device, enter the name of the network interface that the to server uses to communicate with the HTTP server. Or click Select Property 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.
Chapter 25
965
Computer Settings ESX
Computer Settings ESX

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 to display a drop-down menu of for Custom TimeZone, click Select Property 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: XXXXXXXXXX-XXXXX-XXXXX-XXXXX.
Network ESX
The Network tab lets you provide networking information for a server, such as its IP and DNS configuration.
1 Open the system package and 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.
966
Kickstart Entries ESX
Select Use the following IP address if the network connection should use a static 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.
Select Obtain DNS server automatically if the DHCP server should provide the addresses for DNS servers. 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 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. If you want to add additional entries for configuration elements that are not covered 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
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.
Chapter 25
967
To do this, leave Customize the Kickstart file unchecked and add your new entries in the second edit box.
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 Kickstart file. 2 Modify the entries in the first edit box. 3 Then, still in the first edit box, add your additional entries.
In this scenario, because you want to modify the automatically generated entries in the first edit box, you must add your additional entries to the first edit box, not the second edit box.
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.
The ESX 4.0 Kickstart does not support ethX as the value for --device.
NOTE
If you provided a License Key on the Computer Settings tab, its Kickstart entry is serialnum.
968
Post-Install Configuration ESX
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

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 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. 2 Under Operations Manager Settings, check Install RSCD agent if you want to install
BladeLogic console 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 console into a users configuration file on the RSCD agent. In this way, you control users access to the server not only through BMC BladeLogic console but also through Network Shell and the BLCLI. For detailed information on agent ACLs, see Using agent ACLs on page 192.
B For Post-install batch job, click Browse
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. install section of the Kickstart or AutoYaST file, or click Select Property a parameter. (See Using properties to reference scripts on page 1063.)
6 Under Post-Install Script, enter any commands that you want added to the post-
to insert
970
Local properties ESX
The commands you enter run one time immediately after an unattended installation of the operating system.
Local properties ESX

1 Open the system package and click the Local Properties tab. 2 Do one of the following.
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

Use this procedure to specify settings for an unattended installation of a server 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.
the system package and select Open. 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: Disk partition Solaris Basic configuration Solaris Computer settings Solaris Network Solaris Package specifications Solaris
Chapter 25
971
Disk partition 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 Disk Partition tab lets you define partitions for the servers being provisioned. The information you provide here becomes part of the JumpStart profile file.
1 Click the Disk Partition tab. 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: 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.
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
972
Default Partition Existing Partition
4 Then, do one of the following:
To modify an existing partition, select the partition in the Disk Partition list and click Update or Edit .
If you are adding a new partition, a wizard 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.
cannot place any other file systems on this disk.
Allhave this slice use the entire disk for the file system. If you choose All, you
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
Chapter 25
973
Basic configuration Solaris
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.

Basic configuration Solaris

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.
974
Computer settings Solaris
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 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 text 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. 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.
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.
Computer settings Solaris

The Computer Settings tab lets you provide information about localization settings.
1 Click the Computer Settings tab. 2 Under Localization, do the following: A For Timezone:
First, look at the time zones in the drop-down list. If the time zone you need is there, select it.
Chapter 25
975
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
The Network tab lets you provide networking information for a server, such as its IP configuration settings and name service.
976
Network Solaris
1 Click the Network tab. 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. 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. 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:
Chapter 25
977
Package specifications Solaris
Name Service NIS NIS+
Associated Fields Domain Name: Name of the group of systems using NIS. Name Server Host Name: Name of the NIS name server. Name Server IP Address: IP address of the NIS name server.
DNS
Domain Name: Domain name for the group of systems using DNS. Primary DNS Server: IP address of the primary DNS server. Secondary DNS Server: IP address of the secondary DNS server. Tertiary DNS Server: IP address of the tertiary DNS server. Additional Domains: Name(s) of additional domain(s) to search for name service information.

You can specify up to six domain names to search. Use CSV format (separate domain names with commas). The total length of this field (including commas) cannot exceed 250 characters.
LDAP
Domain Name: Name of the group of systems using LDAP. Profile Name: Name of the LDAP profile server. Profile Server IP Address: IP address of the LDAP profile server. Proxy DN: Domain name of the LDAP proxy server. Proxy Password: Password to access the LDAP proxy server. This password must not include the following character string: ??
Package specifications Solaris

The Package Specifications tab lets you choose which Meta Cluster you want to use. A Meta Cluster contains packages that specify what operating system software components to install on the machine.
1 Click the Package Specifications tab. 2 Under Meta Clusters, check the Meta Cluster that contains the operating system
components you want to install.
978
Additional sysidcfg entries
The Package Specifications tab gives you the option to check Use script for OS component selection and then either:
Type in a script that specifies which operating system components you want to install. Type the name of a local property that contains a script, enclosing the property name with double question marks. Click Select Property to display a drop-down menu of available properties. Select the property that contains the script from the list.
NOTE
Additional sysidcfg entries

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.
Chapter 25
979
Add Install Client Script Solaris
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
Add Install Client Script Solaris

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. 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.
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.
Begin Script Solaris
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 name with double question marks. Click Select Property to display a drop-down menu of available properties. 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.
Begin Script Solaris

The Begin Script tab lets you specify a script that JumpStart runs just after the target device boots from the network. At this point, no operating system or software 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. 2 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.
Chapter 25
981
Finish Script/Agent Install Solaris
NOTE
Finish Script/Agent Install Solaris

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:
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. (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. 2 Under Operations Manager Settings, check Install RSCD agent if you want to install
982
Reboot Script Solaris
4 To run a job that can install software and configure the server, do the following: A Check Run post-install Batch Job. B For Post-install Batch Job, click Browse
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.
Reboot Script Solaris

The Reboot Script tab lets you specify a script that connects to the target device and forces it to reboot from the network and send a BOOTP request to the JumpStart server. This starts the actual installation of the operating system. Sample reboot scripts are available from your BMC 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. 2 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.
Chapter 25
983
x86 Parameters Solaris
Click Select Property to display a drop-down menu of available properties. Select the property that contains the script from the list.
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:
984
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

Chapter 25
.
Provisioning servers 985
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

If you are modifying an existing property, right-click the name of the property and select Edit from the drop down menu.
986
Defining settings for AIX servers
Defining settings for AIX servers

Use this procedure to specify settings for an unattended installation of a server running an AIX 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.
the system package and select Open. 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
Basic configuration AIX

1 Click the Basic Config tab. 2 Under Local Settings, do the following:
Chapter 25
987
Basic configuration AIX
A For Computer Name, enter a unique name that should be assigned to the server.
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.
If you want this server to display its Computer name when it appears in the BMC BladeLogic console, leave the OM Server Name text 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. 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.
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
988
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.
Localization settings AIX

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.
Chapter 25
989
Localization settings AIX
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 that references this property. For information on inserting 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 parameter, see Inserting a parameter in a system package field on page 1059.
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, consult the AIX documentation. 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.
990
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, 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 parameter, see Inserting a parameter in a system package field on page 1059.
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:
Chapter 25
991
Agent Install/First boot script AIX
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:
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. 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.
992
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 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. 2 Under Operations Manager Settings, check Install RSCD agent if you want to install
4 To run a job that can install software and configure the server, do the following: A Check Run post-install batch job. B For Post-install batch job, click Browse
5 Under First boot Script, specify the contents of the NIM first boot script by doing
one of the following:
NOTE
Chapter 25
993
Local properties AIX
The first boot script runs one time immediately after an unattended installation and reboot of the operating system.
Local properties AIX

If you are modifying an existing property, right-click the name of the property 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. 2 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 Edit
A script dialog displays.
3 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 property name with double question marks.
994
Control flow
Click Select Property to display a drop-down menu of available properties. Select the property that contains the script name from the list.
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. Type the name of a local property that contains a script, enclosing the property name with double question marks. Click Select Property to display a drop-down menu of available properties. Select the property that contains the script from the list.
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 name with double question marks. Click Select Property to display a drop-down menu of available properties. Select the property that contains the setting from the list.
Chapter 25
995
Optional Bosinst Attributes
Optional Bosinst Attributes

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 property name with double question marks. Click Select Property to display a drop-down menu of available properties. 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 properties to reference scripts on page 1063.
996
Post bos_inst Script
Post bos_inst Script

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 properties to reference scripts on page 1063.
Preview

bosinst.data file
Machine definition command NIM resource definition Bosinst command
Defining settings for HP-UX servers

Use this procedure to specify settings for an unattended installation of a server running the HP-UX 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.
the system package and select Open. 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: Basic configuration HP-UX Disk partition HP-UX Computer settings HP-UX Network settings HP-UX Ignite Commands/Scripts Ignite parameters Software selection
Chapter 25
997
Basic configuration HP-UX
Boot script Post-install config HP-UX Preview Local properties HP-UX
Basic configuration HP-UX

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.
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. 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. 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.
998
Disk partition HP-UX
Disk partition HP-UX

The Disk Partition tab lets you define partitions for the servers being provisioned. You can use the default Ignite disk partitioning, or specify your own disk partitioning script.
1 Click the Disk Partition tab. 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
script, as described in Using properties to reference scripts on page 1063.
Partition. Then either type the script into the box, or use a property to reference the
Computer settings HP-UX

The Computer Settings tab lets you provide information about localization settings.
1 Click the Computer Settings tab. 2 Under Localization, do the following: 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.
Chapter 25
999
Network settings HP-UX
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 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 parameter, see Inserting a parameter in a system package field on page 1059.
Network settings HP-UX

The Network Settings tab lets you provide networking information for a server.
1 Click the Network Settings 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. For Default gateway, enter the address of the IP router that is used to forward traffic to destinations outside of the local network.

Ignite Commands/Scripts
Select Obtain DNS server automatically if the DHCP server should provide the addresses for DNS servers. Select Use the following DNS server address if you want to manually configure a 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 Commands/Scripts
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 name of the script. Type the name of a local property that contains a script name, 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 name from the list.
Type the contents of the script. Type the name of a local property that contains a script, enclosing the property name with double question marks.
Ignite parameters
Click Select Property to display a drop-down menu of available properties. Select the property that contains the script from the list.
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 name with double question marks. Click Select Property to display a drop-down menu of available properties. 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.
1002
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:
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. 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 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. 2 Under Operations Manager Settings, check Install RSCD agent if you want to install
4 To run a job that can install software and configure the server, do the following:
Chapter 25
1003
Preview
A Check Run post-install batch job. B For Post-install batch job, click Browse
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

If you are modifying an existing property, right-click the name of the property and click Edit from the drop down menu.
1004
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 information on defining an ACL, see Defining permissions for a system object on page 186.
Chapter 25
1005
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.
1006
Manually importing a device
ProvisionedProvisioned with an operating system and possibly additional postinstall 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.
blade.img
Used only when working with legacy system packages. gentoo32 Used to provision x86 Linux machines. gentoo64 Used to provision AMD64 Linux machines. Skip Linux Pre-Install Used to provision a device with the Red Hat, VMware ESX, or SUSE operating system when you want to skip the Gentoo pre-installation image. For information, see Using the Skip Linux Pre-Install image on page 901. ESXi 4.0 (vmkboot.gz) Used to provision AMD64 machines with ESXi 4.0. 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. WindowsPE_2_x_x64_ISO_Image Used to provision AMD64 and Windows machines from removable or CD-ROM media connected to the machine. WindowsPE_1_6_Image Used to provision x86 Windows machines. WindowsPE_1_6x64_Image Used to provision AMD64 and Windows 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.)
1008
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 PXE
Property ARCHITECTURE
Value
Required or Optional?
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 CABLE_TYPE to one of the following values:

Optional
tp bnc dix N/A
NIM
PLATFORM
Optional You can set PLATFORM to one of the following values, using the drop-down list:

chrp rs6k rspc
Chapter 25
1009
Provisioning Environment NIM
Property NETBOOT_KERNEL
Value You can set KERNEL_TYPE to one of the following values, using the drop-down list:

Required or Optional? Optional
mp up Optional
NIM
NET_SETTINGS
You can set NET_SETTINGS to one of the following values, using the drop-down list:

100 full 100 auto 100 half 1000 full 1000 auto 1000 half 10 full 10 auto 10 half auto full auto half auto auto
Ignite
ARCHITECTURE
Set ARCHITECTURE Required one of the following values:

PA-RISC Itanium
For information on how to edit the value of a property, see Setting values for system object properties on page 140. 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
information on defining an ACL, see Defining permissions for a system object on page 186.
1010
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 MAC,ARCHITECTURE Example File 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
Chapter 25
1011
PXE, JumpStart, x86 JumpStart, or Ignite Format Format MAC Example File 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), see Adding or modifying properties on page 125.
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.
1012
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.)
Chapter 25
1013
If you want this provisioning wizard field to be filled in...
Create a Device class property called...
Then define your Create a local system system package to use the new property package property like this... called... On the Basic Config panel of the system package, fill in the Computer name field like this: ??LOCAL_COMPUT ER_NAME??
Panel 2: Basic Config COMPUTER_NAME LOCAL_COMPUTE R_NAME Computer name Set Default value field to: (See Basic Config.) DEVICE.COMPUTE R_NAME Panel 2: Basic Config OM_NAME OM Server name (See Basic Config.)
LOCAL_OM_NAME On the Basic Config panel of the system package, fill in the Set Default value OM server name field to: 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
from the pop-up menu.
2 Click the Local Properties tab. 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:
1014
??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.
Chapter 25
1015
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 MAC 00-0B-CD-1B-E0-44 00-C0-9F-4B-9E-1B 00-02-B3-B1-1B-E3 PXE, JumpStart or Ignite Example MAC,ARCHITECTURE 00-0B-CD-1B-E0-44,x86 00-C0-9F-4B-9E-1B,x64 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 MAC,COMPUTER_NAME 00-0B-CD-1B-E0-44,"Sales1" 00-C0-9F-4B-9E-1B,"Sales2" 00-02-B3-B1-1B-E3,"Sales3" PXE, JumpStart or Ignite Example MAC,ARCHITECTURE,COMPUTER_NA ME 00-0B-CD-1B-E0-44,x86,"SalesA" 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
1016
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 dropdown menu lists standard image files.
blade.img
Used only when working with legacy system packages. gentoo32 Used to provision x86 Linux machines. gentoo64 Used to provision AMD64 Linux machines. Skip Linux Pre-Install Used to provision a device with the Red Hat, VMware ESX, or SUSE operating system when you want to skip the Gentoo pre-installation image. For information, see Using the Skip Linux Pre-Install image on page 901. ESXi 4.0 (vmkboot.gz) Used to provision AMD64 machines with ESXi 4.0. 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. WindowsPE_2_x_x64_ISO_Image Used to provision AMD64 and Windows machines from removable or CD-ROM media connected to the machine. WindowsPE_1_6_Image Used to provision x86 Windows machines. WindowsPE_1_6x64_Image Used to provision AMD64 and Windows 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.
Chapter 25
1017
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.
For more information on defining an ACL, see Defining permissions for a system 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-XXXX-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-0C29. 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.
1018
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).
Description The manufacturer of the server, such as Dell or HP. The model number of the server. The number of CPUs in the server. The generation of the CPU, such as Pentium III. The speed of the CPU in megahertz. The amount of random access memory in megabytes.
Setting System Manufacturer System Model CPU Count CPU Family CPU Speed RAM
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:
1020
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.
To set a property value back to its default value, click Reset to Default Value . The value of the property is reset to the value it inherits from a built-in property class. Depending on the type of property you are editing, you can take different actions to set a new value, such as entering an alphanumeric string, choosing from an enumerated list, or selecting a date. To insert a parameter into the value, enter the value, bracketed with double question mark delimiters (for example, ??MyPARAMETER??) or click the Select Property . For more information, see Inserting a parameter on page 142.
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.
Chapter 25
1021
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, doubleclick 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.
1022
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. select the system package.
3 To view the log for a provisioning job in which the system package was applied, 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.
Chapter 25
1023
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.)
1024
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.
Chapter 25
1025
Choose Devices
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 Server Automation Administration Guide for more information on configuring Application 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.
1026
System Package Selection
System Package Selection

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 be used to provision the server(s).
to select the system package that should
From the Selected Boot Image list, select the boot image that should be used to provision the server(s).
Select Image (PXE only)

(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.
System Package Properties

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 properties on page 140.
Chapter 25
1027
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.
System Package Type Windows Linux ESX Solaris AIX HP-UX Relevant Procedure 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
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).
1028
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.
System Package Type Windows Linux ESX Solaris AIX HP-UX Relevant Procedure Network Windows on page 942 Network Linux on page 954 Network ESX on page 966 Network Solaris on page 976 Network Config AIX on page 991 Network settings HP-UX on page 1000
Provisioning Summary (multiple servers only)

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.
Chapter 25
1029
Optional Bosinst Attributes (NIM only)
Optional Bosinst Attributes (NIM only)

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.
Begin Script (JumpStart only)

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.
Post-install Configuration
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.
System Package Type Windows Linux ESX Solaris AIX HP-UX Relevant Procedure Post-install configuration Windows on page 946 Post-install configuration Linux on page 958 Post-Install Configuration ESX on page 969 Finish Script/Agent Install Solaris on page 982 Agent Install/First boot script AIX on page 992 Post-install config HP-UX on page 1003
1030
Provisioning Job Settings (PXE only)
Provisioning Job Settings (PXE only)

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 -> postdisk partition... and so on
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:
Prompt user after each step tells the provisioning process to prompt the user to press
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
Chapter 25
1031
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 for a system object on page 186.
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 values, see Setting values for system object properties on page 140.
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, see Setting values for system object properties on page 140.
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.
1032
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

create a schedule for a job that you are creating schedule an existing job for execution
Chapter 25
1033
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 progress on page 427. 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.
NOTE
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 reprovisioned server. Any jobs you want defined for the server before you reprovisioned 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.
1034
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.
Chapter 25
1035
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 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 Provisioning Summary (multiple servers only) 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. If you want this server to display its Computer name when it appears in the BMC BladeLogic console, leave the OM Server Name text 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.
Chapter 25
1037
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. For an example of how inserting a parameter here can streamline provisioning, see Importing MAC Addresses and Configuration Values on page 1012.
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 reexecution. 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
schedule by clicking click Edit Schedule . or modify an existing .
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).
2 From Time Zone, select the time zone in which the job should run. NOTE

create a schedule for a job that you are creating schedule an existing job for execution
Scheduled Job Notification

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 installationDirectory/Share/BladeLogic.mib.
1 Click the Scheduled Job Notifications tab. 2 To send email notifications, under Job Run Notifications, do the following:
Chapter 25
1039
Setting up default notification of job completion
sysadmin@abc.com;sysmgr@abc.com.
should be notified when the job completes with a status that you specify. and use the Select Server dialog to choose Alternatively, you can click Browse 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. 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 installationDirectory/Share/BladeLogic.mib. To define default notifications:
Open.
2 Click the Default Notification tab. 3 To send email notifications, under Job Run Notifications, do the following:
1040
Viewing the log for a Provision Job
sysadmin@abc.com;sysmgr@abc.com.
should be notified when the job completes with a status that you specify. and use the Select Server dialog to choose Alternatively, you can click Browse 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.
Chapter 25
1041
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.
1042
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 popup 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 progress on page 427.
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.
Chapter 25
1043
Provisioning Windows 2003 or 2008 servers from a local data store
Provisioning Windows 2003 or 2008 servers 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 CDROM 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.
1044
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. the LocalDataStore instance with the system package on page 1051.
3 Associate the local data store instance with the system package. See Associating
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.
Chapter 25
1045
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:
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.
ISO Image: Creates a WinPE 2.x image in ISO format (bootImageName.iso) for
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.)
1046
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. CreateWinPE2_x.vbs script on page 883.
2 Run the CreateWinPE2_x.vbs script as described in Running the
Chapter 25
1047
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 .
1048
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 (\). installer files reside.
D For RSCD Installer location, type the path to the directory where the RSCD agent
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. 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.
4 On the Local Properties tab, you can accept or change the default setting for the
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:
Chapter 25
1049
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.
1050
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

Instance dialog appears.
. The Choose Property Class
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.
Chapter 25
1051
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.
1052
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.) store instance:
2 Provide values for the following properties of the Jumpstart WAN Install data
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 cgibin 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.
Chapter 25
1053
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
WAN Boot.
C On the Configurations tab, for Operating System Type, select Solaris. Then check 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 servers on page 971. would for a Solaris installation.
6 On the Basic Config tab, provide information for Local Settings as you normally 7 To set up a secure WAN boot installation, for WAN Boot Parameters, select either of
the following options:
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 Server during the installation: Specifies that the server generates
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.)
Authenticate Client after the installation (automatically selects Authenticate Server during the installation): Specifies that a trusted certificate is provided to the
1054
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.) Solaris Flash installation.
9 Provide information on the other tabs of the system package as you would for a
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 postinstallation 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:
Chapter 25
1055
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

to the TFTP server.
C Edit the values for Image File and Kernel name to specify paths that are relative 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 properties on page 1057.
1056
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:
Chapter 25
1057
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:
Value eth0 eth1 eth2 eth3
Name Port 0 Port 1 Port 2 Port 3
1058
Inserting a parameter in a system package field
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 dropdown 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.
Inserting a parameter in a system package field

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??.
System package fields that accept property references

You can use parameterized property references:

In all script areas of a system package. In the fields shown in the following table.
Chapter 25
1059
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 Windows Basic Config (See Basic configuration Windows on page 931.) Computer Settings (See Computer Settings Windows on page 933.) Network Settings (See Network Windows on page 942.) Local Properties (See Local properties Windows on page 948.) Linux Basic Config (See Basic configuration Linux on page 951.) Network Settings (See Network Linux on page 954.) Local Properties (See Local properties Linux on page 959.) Computer name OM Server Name Kickstart network device/AutoYaST network device Boot Kernel Parameters IP Address Subnet mask Default gateway DNS server Default value for an added property Fields Computer name OM Server Name Windows server domain Workgroup Domain admin user name User Information/Name User Information/Organization PnP driver path Path to $OEM$ directory License key IP address Subnet mask Default gateway Primary DNS server Secondary DNS server Default value for an added property
1060
System Package Type Panel Solaris Basic Config (See Basic configuration Solaris on page 974.) Computer Settings (See Computer settings Solaris on page 975.) Network Settings (See Network Solaris on page 976.)
Fields Computer name OM Server Name
Timezone System Locale
IP Address Netmask Default Route 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 Default value for an added property
Local Properties (See Local Properties Solaris on page 986.)
Chapter 25
1061
System Package Type Panel AIX Basic Config (See Basic configuration AIX on page 987.) Localization Settings (See Localization settings AIX on page 989.) Network Settings (See Network Config AIX on page 991.)
Fields Computer name OM Server Name Nim Machine Name Bosinst Locale Cultural Conventions Message Catalogs Keyboard Network object name Network Type Subnet Mask Network Name Client Gateway Master Gateway Network Adapter Name DNS IP Address Domain Name Default value for an added property
Local Properties (See Local properties AIX on page 994.) Nim Scripts (See NIM scripts on page 994.) Bosinst Attributes (See Optional Bosinst Attributes on page 996.)
Script Name
Bosinst attribute name Value
1062
Using properties to reference scripts
System Package Type Panel HP-UX Basic Config (See Basic configuration HP-UX on page 998.) Disk Partition (See Disk partition HP-UX on page 999.) Computer Settings (See Computer settings HPUX on page 999.) Network Settings (See Network settings HPUX on page 1000.)
Fields Computer name OM Server Name
Use Custom Disk Partition
TimeZone Keyboard
IP address Subnet mask Default gateway Primary DNS server Secondary DNS server Hardware Address Default value for an added property
Local Properties (See Local properties AIX on page 994.)
NOTE
You can use property references in any field that displays the Select Property icon .
Using properties to reference scripts

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. to open a text window.
C To the right of the Default value field, click Browse D Type your script in the text window.
Chapter 25
1063
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 where you store sets of installation files that are used for provisioning operating systems. You can create multiple data stores throughout your network, and then choose the most appropriate one for provisioning a specific device. For more information, see Data Store Instances and provisioning strategies on page 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
1064
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.
Chapter 25
1065
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.
1066
Appendix
System authorizations
The following table provides a complete list of all BMC BladeLogic system authorizations:
Name ACLPolicy.* ACLPolicy.Create ACLPolicy.CreateACL ACLPolicy.Delete ACLPolicy.Modify ACLPolicy.ModifyACL ACLPolicy.Read ACLPushJob.* ACLPushJob.Break ACLPushJob.Cancel ACLPushJob.Create ACLPushJob.CreateACL ACLPushJob.Delete ACLPushJob.Execute ACLPushJob.Modify ACLPushJob.ModifyACL ACLPushJob.ModifyProperties ACLPushJob.ModifySchedule ACLPushJob.ModifyTargets ACLPushJob.Read ACLTemplate.* ACLTemplate.Create ACLTemplate.CreateACL ACLTemplate.Delete ACLTemplate.Modify Description ACL policy management Create new ACL policy Create ACL for ACL policy Delete ACL policy Update ACL policy information Modify ACL for ACL policy Read ACL policy information ACL Push Job management Cancel ACL Push Job Create new ACL Push Job Create ACL for ACL Push Job Delete ACL Push Job Execute ACL Push Job Modify ACL Push Job Modify ACL for ACL Push Job Modify ACL Push Job properties Modify ACL Push Job schedule Modify ACL Push Job targets Read ACL Push Job Read ACL Push Job ACL template management Create new ACL template Create ACL for ACL template Delete ACL template Update ACL template information
Appendix A
1067
Name ACLTemplate.ModifyACL ACLTemplate.Read AIXSoftware.* AIXSoftware.Create AIXSoftware.CreateACL AIXSoftware.Delete AIXSoftware.Modify AIXSoftware.ModifyACL AIXSoftware.ModifyProperties AIXSoftware.Read ApplicationServer.* ApplicationServer.Create ApplicationServer.CreateACL ApplicationServer.Delete ApplicationServer.Modify ApplicationServer.ModifyACL ApplicationServer.ModifyProperties ApplicationServer.Read ApprovalConfig.* ApprovalType.* ApprovalType.Automatic ApprovalType.Emergency ApprovalType.Manual ApprovalType.NoApproval ApprovalType.PreApproved Atrium2BlSyncConfig.Modify Atrium2BlSyncJob.* Atrium2BlSyncJob.Break Atrium2BlSyncJob.Cancel Atrium2BlSyncJob.Create Atrium2BlSyncJob.CreateACL Atrium2BlSyncJob.Delete Atrium2BlSyncJob.Execute Atrium2BlSyncJob.Modify Atrium2BlSyncJob.ModifyACL Atrium2BlSyncJob.ModifyProperties Atrium2BlSyncJob.ModifySchedule Atrium2BlSyncJob.ModifyTargets Atrium2BlSyncJob.Read
Description Modify ACL for ACL template Read ACL template information Software authorizations Create new depot software Create ACL for depot software Delete depot software Modify depot software Modify ACL for depot software Modify depot software properties Open depot software Application Server management Create new Application Server Create ACL for Application Server Delete Application Server Modify Application Server information Modify ACL for Application Server Modify Application Server properties Read Application Server information Remedy approval configuration management Remedy approval type Remedy automatic approval Remedy emergency approval Remedy manual approval No approval required Pre-approved Atrium Import Job configuration Atrium Import Job management Break Atrium Import Jobs dependencies Cancel Atrium Import Job Create new Atrium Import Job Create ACL for Atrium Import Job Delete Atrium Import Job Execute Atrium Import Job Modify Atrium Import Job Modify ACL for Atrium Import Job Modify Atrium Import Job properties Modify Atrium Import Job schedule Modify Atrium Import Job targets Read Atrium Import Job
1068
Name AuditJob.* AuditJob.Break AuditJob.Cancel AuditJob.Create AuditJob.CreateACL AuditJob.Delete AuditJob.Execute AuditJob.Modify AuditJob.ModifyACL AuditJob.ModifyProperties AuditJob.ModifySchedule AuditJob.ModifyTargets AuditJob.Read Authorization.* Authorization.Create Authorization.Delete Authorization.Modify AuthProfile.* AuthProfile.Create AuthProfile.CreateACL AuthProfile.Delete AuthProfile.Modify AuthProfile.ModifyACL AuthProfile.Read AutomationPrincipal.* AutomationPrincipal.Create AutomationPrincipal.CreateACL AutomationPrincipal.Delete AutomationPrincipal.Modify AutomationPrincipal.ModifyACL AutomationPrincipal.ModifyProperties AutomationPrincipal.Read BatchJob.* BatchJob.Break BatchJob.Cancel BatchJob.Create BatchJob.CreateACL BatchJob.Delete BatchJob.Execute
Description Audit Job management Break Audit Jobs dependencies Cancel Audit Job Create Audit Job Create ACL for Audit Job Delete Audit Job Execute Audit Job Modify Audit Job Modify ACL for Audit Job Modify Audit Job properties Modify Audit Job schedule Modify Audit Job targets Read Audit Job Authorization management Create new authorization Delete authorization Modify authorization Authorization profile management Create new authorization profile Create ACL for authorization profile Delete authorization profile Modify authorization profile information Modify ACL for authorization profile Read authorization profile information Automation principal management Create new automation principals Create ACL for automation principals Delete automation principals Modify automation principal information Modify ACL for automation principals Modify automation principal properties Read automation principal information Batch Job management Break Batch Jobs dependencies Cancel Batch Job Create new Batch Job Create ACL for Batch Job Delete Batch Job Execute Batch Job
Appendix A
1069
Name BatchJob.Modify BatchJob.ModifyACL BatchJob.ModifyProperties BatchJob.ModifySchedule BatchJob.ModifyTargets BatchJob.Read BL_Administration.* BL_Administration.Read BL_Administration.System_Cleanup BL_Administration.Write BLPackage.* BLPackage.Create BLPackage.CreateACL BLPackage.Delete BLPackage.Modify BLPackage.ModifyACL BLPackage.ModifyProperties BLPackage.Read Component.* Component.Audit Component.Browse Component.Create Component.CreateACL Component.Delete Component.FileCreate Component.FileDelete Component.FileModify Component.Modify Component.ModifyACL Component.ModifyExceptions Component.ModifyProperties Component.Read Component.Snapshot Component.StartService Component.StopService ComponentGroup.* ComponentGroup.Create ComponentGroup.CreateACL ComponentGroup.Delete
Description Modify Batch Job Modify ACL for Batch Job Modify Batch Job Modify Batch Job schedule Modify Batch Job targets Read Batch Job BMC BladeLogic administrative tasks Read general system status Execute system level cleanup operations Write/modify general system properties BLPackage authorizations Create new BLPackage Create ACL for BLPackage Delete BLPackage Modify BLPackage Modify ACL for BLPackage Modify BLPackage properties Open BLPackage Component authorizations Allow audits on this component Browse component assets Create new component Create ACL for component Delete component Create files on component Delete files on component Modify files on component Modify component information Modify ACL for component Modify component exceptions Modify component properties Read server properties and other metadata Allow snapshots on this component Start component services Stop component services Component group authorizations Create new component group Create ACL for component group Delete component group
1070
Name ComponentGroup.Modify ComponentGroup.ModifyACL ComponentGroup.Read ComponentGroup.Write ComponentTemplate.* ComponentTemplate.Break ComponentTemplate.Create ComponentTemplate.CreateACL ComponentTemplate.Delete ComponentTemplate.Modify ComponentTemplate.ModifyACL ComponentTemplate.ModifyProperties ComponentTemplate.Read ComponentTemplateFolder.* ComponentTemplateFolder.Create ComponentTemplateFolder.CreateACL ComponentTemplateFolder.Delete ComponentTemplateFolder.Modify ComponentTemplateFolder.ModifyACL ComponentTemplateFolder.Read ComponentTemplateFolder.Write ComponentTemplateGroup.* ComponentTemplateGroup.Create ComponentTemplateGroup.CreateACL ComponentTemplateGroup.Delete ComponentTemplateGroup.Modify ComponentTemplateGroup.ModifyACL ComponentTemplateGroup.Read ComponentTemplateGroup.Write ConfigFile.* ConfigFile.Create ConfigFile.CreateACL ConfigFile.Delete ConfigFile.Modify ConfigFile.ModifyACL ConfigFile.Read ConfigurationObjectClass.* ConfigurationObjectClass.Create ConfigurationObjectClass.CreateACL
Description Modify component group information Modify ACL for component group Read contents of a component group Add objects to component group Component template authorizations Break component templates dependencies Create new component template Create ACL for component template Delete component template Modify component template information Modify ACL for component template Modify component template properties Read component template Component template authorizations Create new component template folder Create ACL for component template folder Delete component template folder Modify component template folder information Modify ACL for component template folder Read contents of a component template folder Add to a component template folder Component template group authorizations Create new component template group Create ACL for component template group Delete component template group Modify component template group information Modify ACL for component template group Read contents of a component template group Add to a component template group Configuration file management Create configuration file Create ACL for configuration file Delete configuration file Modify configuration file Modify ACL for configuration file Read/open configuration file Custom configuration object management Create new custom configuration object Create ACL for new custom configuration object
Appendix A
1071
Name ConfigurationObjectClass.Delete ConfigurationObjectClass.Modify ConfigurationObjectClass.ModifyACL ConfigurationObjectClass.Read CustomCommand.* CustomCommand.Create CustomCommand.CreateACL CustomCommand.Delete CustomCommand.Execute CustomCommand.Modify CustomCommand.ModifyACL CustomCommand.Read CustomIcon.* CustomIcon.Create CustomIcon.Delete CustomIcon.Modify CustomSoftware.* CustomSoftware.Create CustomSoftware.CreateACL CustomSoftware.Delete CustomSoftware.Modify CustomSoftware.ModifyACL CustomSoftware.ModifyProperties CustomSoftware.Read DeployJob.* DeployJob.Break DeployJob.Cancel DeployJob.Create DeployJob.CreateACL DeployJob.Delete DeployJob.Execute DeployJob.Modify DeployJob.ModifyACL DeployJob.ModifyProperties DeployJob.ModifySchedule DeployJob.ModifyTargets DeployJob.Read DeployJob.Undo DepotFile.*
Description Delete custom configuration object Modify custom configuration object Modify ACL for custom configuration object Read custom configuration object Custom command management Create new custom command Create ACL for custom command Delete custom command Execute custom command Modify custom command Modify ACL for custom command Open custom command Configuration file management Create configuration file Delete configuration file Modify configuration file Software authorizations Create new depot software Create ACL for depot software Delete depot software Modify depot software Modify ACL for depot software Modify software properties Open depot software Deploy Job management Break Deploy Jobs dependencies Cancel Deploy Job Create new Deploy Job Create ACL for Deploy Job Delete Deploy Job Execute Deploy Job Modify Deploy Job Modify ACL for Deploy Job Modify Deploy Job properties Modify Deploy Job schedule Modify Deploy Job targets Read Deploy Job Undo Deploy Job Depot file authorizations
1072
Name DepotFile.Create DepotFile.CreateACL DepotFile.Delete DepotFile.Modify DepotFile.ModifyACL DepotFile.ModifyProperties DepotFile.Read DepotFolder.* DepotFolder.Create DepotFolder.CreateACL DepotFolder.Delete DepotFolder.Modify DepotFolder.ModifyACL DepotFolder.Read DepotFolder.Write DepotGroup.* DepotGroup.Create DepotGroup.CreateACL DepotGroup.Delete DepotGroup.Modify DepotGroup.ModifyACL DepotGroup.Read DepotGroup.Write DeregisterConfigurationObjects.* DeregisterConfigurationObjects.Cancel DeregisterConfigurationObjects.Create DeregisterConfigurationObjects.CreateACL DeregisterConfigurationObjects.Delete DeregisterConfigurationObjects.Execute DeregisterConfigurationObjects.Modify DeregisterConfigurationObjects.ModifyACL DeregisterConfigurationObjects.ModifySchedule DeregisterConfigurationObjects.ModifyTargets DeregisterConfigurationObjects.Read Device.* Device.Create Device.CreateACL Device.Delete
Description Create new depot file Create ACL for depot file Delete depot file Modify depot file Modify ACL for depot file Modify depot file properties Open depot file Depot folder management Create new depot folder Create ACL for depot folder Delete depot folder Modify depot folder Modify ACL for depot folder Open depot folder Add new objects into depot folder Depot group management Create new depot group Create ACL for depot group Delete depot group Modify depot group Modify ACL for depot group Open depot group Add new objects into depot group Deregister Configuration Objects Job management Cancel Deregister Configuration Objects Job Create Deregister Configuration Objects Job Create ACL for Deregister Configuration Objects Job Delete Deregister Configuration Objects Job Execute Deregister Configuration Objects Job Modify Deregister Configuration Objects Job Modify ACL for Deregister Configuration Objects Job Modify Deregister Configuration Objects Job schedule Modify Deregister Configuration Objects Job targets Read Deregister Configuration Objects Job Devices Create device Create ACL for device Delete device from provisioning manager
DeregisterConfigurationObjects.ModifyProperties Modify Deregister Configuration Objects Job properties
Appendix A
1073
Name Device.Modify Device.ModifyACL Device.ModifyProperties Device.Provision Device.Read Device.ReProvision Device.SetAsProvisioned DeviceFolder.* DeviceFolder.Create DeviceFolder.CreateACL DeviceFolder.Delete DeviceFolder.Modify DeviceFolder.ModifyACL DeviceFolder.Read DeviceFolder.Write DeviceGroup.* DeviceGroup.Create DeviceGroup.CreateACL DeviceGroup.Delete DeviceGroup.Modify DeviceGroup.ModifyACL DeviceGroup.Read DeviceGroup.Write DiscoveryJob.* DiscoveryJob.Break DiscoveryJob.Cancel DiscoveryJob.Create DiscoveryJob.CreateACL DiscoveryJob.Delete DiscoveryJob.Execute DiscoveryJob.Modify DiscoveryJob.ModifyACL DiscoveryJob.ModifyProperties DiscoveryJob.ModifySchedule DiscoveryJob.ModifyTargets DiscoveryJob.Read DistributeConfigurationObjects.* DistributeConfigurationObjects.Cancel DistributeConfigurationObjects.Create
Description Modify a device Modify ACL for device Modify the properties of a device Provision devices Read devices Re-provision devices Set devices as provisioned Device folder management Create new Device folder Create ACL for Device folder Delete device folder Modify device folder Modify ACL for device folder Open device folder Add new objects into device folder Device group management Create new device group Create ACL for device group Delete device group Modify device group Modify ACL for device group Open device group Add new objects into device group Discovery Job management Break Discovery Jobs dependencies Cancel Discovery Job Create new Discovery Job Create ACL for Discovery Job Delete Discovery Job Execute Discovery Job Modify Discovery Job Modify ACL for Discovery Job Modify Discovery Job properties Modify Discovery Job schedule Modify Discovery Job targets Read Discovery Job Distribute Configuration Objects Job management Cancel job Create Distribute Configuration Objects Job
1074
Name DistributeConfigurationObjects.CreateACL DistributeConfigurationObjects.Delete DistributeConfigurationObjects.Execute DistributeConfigurationObjects.Modify DistributeConfigurationObjects.ModifyACL DistributeConfigurationObjects.ModifySchedule DistributeConfigurationObjects.ModifyTargets DistributeConfigurationObjects.Read ExecutionTask.* ExecutionTask.Create ExecutionTask.CreateACL ExecutionTask.Delete ExecutionTask.Execute ExecutionTask.Modify ExecutionTask.ModifyACL ExecutionTask.ModifyProperties ExecutionTask.ModifySchedule ExecutionTask.ModifyTargets ExecutionTask.Read ExtendedObject.* ExtendedObject.Create ExtendedObject.CreateACL ExtendedObject.Delete ExtendedObject.Modify ExtendedObject.ModifyACL ExtendedObject.Read FileServer.* FileServer.Create FileServer.Delete FileServer.Modify FileServer.Read HPUXSoftware.* HPUXSoftware.Create HPUXSoftware.CreateACL HPUXSoftware.Delete HPUXSoftware.Modify HPUXSoftware.ModifyACL HPUXSoftware.ModifyProperties
Description Create ACL for Distribute Configuration Objects Job Delete Distribute Configuration Objects Job Execute Distribute Configuration Objects Job Modify Distribute Configuration Objects Job Modify ACL for Distribute Configuration Objects Job Modify Distribute Configuration Objects Job schedule Modify Distribute Configuration Objects Job targets Read Distribute Configuration Objects Job Execution task management Create new execution task Create ACL for execution task Delete execution task Execute execution task Modify execution task Modify ACL for execution task Modify execution task properties Modify execution task schedule Modify execution task targets Read execution task Extended object management Create extended object definition Create ACL for extended object definition Delete extended object definition Modify extended object definition Modify ACL for extended object definition Read extended object definition File server management Create new file server Delete file server Modify file server information Read file server information Software authorizations Create new depot software Create ACL for depot software Delete depot software Modify depot software Modify ACL for depot software Modify depot software properties
DistributeConfigurationObjects.ModifyProperties Modify Distribute Configuration Objects Job properties
Appendix A
1075
Name HPUXSoftware.Read JobFolder.* JobFolder.Create JobFolder.CreateACL JobFolder.Delete JobFolder.Modify JobFolder.ModifyACL JobFolder.Read JobFolder.Write JobGroup.* JobGroup.Create JobGroup.CreateACL JobGroup.Delete JobGroup.Modify JobGroup.ModifyACL JobGroup.Read JobGroup.Write LdapConnection.* LdapConnection.Create LdapConnection.CreateACL LdapConnection.Delete LdapConnection.Modify LdapConnection.ModifyACL LdapConnection.ModifyProperties LdapConnection.Read LinuxSoftware.* LinuxSoftware.Create LinuxSoftware.CreateACL LinuxSoftware.Delete LinuxSoftware.Modify LinuxSoftware.ModifyACL LinuxSoftware.ModifyProperties LinuxSoftware.Read MacPool.* MacPool.Create MacPool.CreateACL MacPool.Delete MacPool.Modify MacPool.ModifyACL
Description Open depot software Job folder management Create new job folder Create ACL for job folder Delete job folder Modify job folder Modify ACL for job folder Open job folder Add objects to job folder Job group management Create new job group Create ACL for job group Delete job group Modify job group Modify ACL for job group Open job group Add objects to job group LDAP connection management Create new LDAP connection Create ACL for LDAP connection Delete LDAP connection Modify LDAP connection information Modify ACL for LDAP connection Modify LDAP connection properties Read LDAP connection information Software authorizations Create new depot software Create ACL for depot software Delete depot software Modify depot software Modify ACL for depot software Modify depot software properties Open depot software MAC pool management Create MAC pool Create ACL for Create MAC pool Delete Create MAC pool Modify Create MAC pool Modify ACL for Create MAC pool
1076
Name MacPool.ModifyProperties MacPool.Read NSHScript.* NSHScript.Create NSHScript.CreateACL NSHScript.Delete NSHScript.Modify NSHScript.ModifyACL NSHScript.ModifyProperties NSHScript.Read NSHScriptJob.* NSHScriptJob.Break NSHScriptJob.Cancel NSHScriptJob.Create NSHScriptJob.CreateACL NSHScriptJob.Delete NSHScriptJob.Execute NSHScriptJob.Modify NSHScriptJob.ModifyACL NSHScriptJob.ModifyParameters NSHScriptJob.ModifyProperties NSHScriptJob.ModifySchedule NSHScriptJob.ModifyTargets NSHScriptJob.Read PatchAnalysisConfig.Modify PatchCatalog.* PatchCatalog.Cancel PatchCatalog.Create PatchCatalog.CreateACL PatchCatalog.Delete PatchCatalog.Modify PatchCatalog.ModifyACL PatchCatalog.ModifyProperties PatchCatalog.ModifySchedule PatchCatalog.Read PatchCatalog.Update PatchCatalog.Write PatchDownloadJob.* PatchDownloadJob.Break
Description Modify Create MAC pool properties Read Create MAC pool NSH script management Create NSH script Create ACL for NSH script Delete NSH script Modify NSH script Modify ACL for NSH script Modify NSH script properties Read NSH script NSH Script Job management Break NSH Script Jobs dependencies Cancel NSH Script Job Create NSH Script Job Create ACL for NSH Script Job Delete NSH Script Job Execute NSH Script Job Modify NSH Script Job Modify ACL for NSH Script Job Modify parameters for NSH Script Job Modify NSH Script Job properties Modify NSH Script Job schedule Modify NSH Script Job targets Read NSH Script Job Patch analysis configuration management Patch catalog management Cancel job Create new patch catalog Create ACL for patch catalog Delete patch catalog Modify patch catalog Modify ACL for patch catalog Modify patch catalog update job properties Schedule patch catalog update job Open patch catalog Add new objects into patch catalog Add new objects into patch catalog Patch download job management Break patch download jobs dependencies
Appendix A
1077
Name PatchDownloadJob.Cancel PatchDownloadJob.Create PatchDownloadJob.CreateACL PatchDownloadJob.Delete PatchDownloadJob.Execute PatchDownloadJob.Modify PatchDownloadJob.ModifyACL PatchDownloadJob.ModifyProperties PatchDownloadJob.ModifySchedule PatchDownloadJob.ModifyTargets PatchDownloadJob.Read PatchingJob.* PatchingJob.Break PatchingJob.Cancel PatchingJob.Create PatchingJob.CreateACL PatchingJob.Delete PatchingJob.Execute PatchingJob.Modify PatchingJob.ModifyACL PatchingJob.ModifyProperties PatchingJob.ModifySchedule PatchingJob.ModifyTargets PatchingJob.Read PatchRemediationJob.* PatchRemediationJob.Break PatchRemediationJob.Cancel PatchRemediationJob.Create PatchRemediationJob.CreateACL PatchRemediationJob.Delete PatchRemediationJob.Execute PatchRemediationJob.Modify PatchRemediationJob.ModifyACL PatchRemediationJob.ModifyProperties PatchRemediationJob.ModifySchedule PatchRemediationJob.ModifyTargets PatchRemediationJob.Read PatchSmartGroup.* PatchSmartGroup.Create
Description Cancel job Create patch download job Create ACL for patch download job Delete patch download job Execute patch download job Modify patch download job Modify ACL for patch download job Modify patch download job properties Modify patch download job schedule Modify patch download job targets Read patch download job Patching job management Break patching job Cancel job Create patching job Create ACL for patching job Delete patching job Execute patching job Modify patching job Modify ACL for patching job Modify patching job properties Modify patching job schedule Modify patching job targets Read patching job Patch remediation job management Break patch remediation jobs dependencies Cancel job Create patch remediation job Create ACL for patch remediation job Delete patch remediation job Execute patch remediation job Modify patch remediation job Modify ACL for patch remediation job Modify patch remediation job properties Modify patch remediation job schedule Modify patch remediation job targets Read patch remediation job Patch smart group management Create patch smart group
1078
Name PatchSmartGroup.CreateACL PatchSmartGroup.Delete PatchSmartGroup.Modify PatchSmartGroup.ModifyACL PatchSmartGroup.Read PatchSmartGroup.Write PropertyClass.* PropertyClass.CreateACL PropertyClass.CreateCustom PropertyClass.CreateInstance PropertyClass.CreateSubClass PropertyClass.Delete PropertyClass.ExportDictionary PropertyClass.ImportDictionary PropertyClass.Modify PropertyClass.ModifyACL PropertyInstance.* PropertyInstance.CreateACL PropertyInstance.Delete PropertyInstance.Modify PropertyInstance.ModifyACL PropertyInstance.Read ProvisionConfig.* ProvisionConfig.Modify ProvisionConfig.Read ProvisionJob.* ProvisionJob.Break ProvisionJob.Cancel ProvisionJob.Create ProvisionJob.CreateACL ProvisionJob.Delete ProvisionJob.Execute ProvisionJob.Modify ProvisionJob.ModifyACL ProvisionJob.ModifyProperties ProvisionJob.ModifySchedule ProvisionJob.ModifyTargets ProvisionJob.Read Repeater.*
Description Create ACL for patch smart group Delete patch smart group Modify patch smart group Modify ACL for patch smart group Open patch smart group Add new objects into patch smart group Property class management Create ACL for property class Create new custom property class Create instance of property class Create property sub-class Delete property class Export Property Dictionary Import Property Dictionary Modify property class Modify ACL for property class Property instance management Create ACL for property instance Delete property instance Modify property instance Modify ACL for property instance Read property instance Provisioning Manager configurations Modify Provisioning Manager configurations Access Provisioning Manager configurations Provisioning Job management Break Provisioning Jobs dependencies Cancel Provisioning Job Create new Provisioning job Create ACL for Provisioning Job Delete Provisioning Job Execute Provisioning Job Modify Provisioning Job Modify ACL for Provisioning Job Modify Provisioning Job properties Modify Provisioning Job schedule Modify Provisioning Job targets Read Provisioning Job Repeater management
Appendix A
1079
Name Repeater.Create Repeater.Delete Repeater.Modify Repeater.Read Reports.Administration Reports.QueryStudio Reports.Studio Reports.Viewer Role.* Role.Create Role.CreateACL Role.Delete Role.ManageUsers Role.Modify Role.ModifyACL Role.ModifyProperties Role.Read RoutingPolicy.* RoutingPolicy.Create RoutingPolicy.CreateACL RoutingPolicy.Delete RoutingPolicy.Modify RoutingPolicy.ModifyACL RoutingPolicy.ModifyProperties RoutingPolicy.Read Server.* Server.Audit Server.Browse Server.Create Server.CreateACL Server.Decommission Server.Deploy Server.Discover Server.ExecuteNSHScript Server.FileCreate Server.FileDelete Server.FileModify Server.Modify Server.ModifyACL
Description Create new repeater server Delete repeater server Modify repeater information Read repeater information Reports management Access to Query Studio Access to Reports Studio Access to Cognos Connection Role management Create new role Create ACL for role Delete role Manage users for role Modify role information Modify ACL for role Modify role properties Read role information Routing policy management Create new routing policy Create ACL for routing policy Delete routing policy Modify routing policy information Modify ACL for routing policy Modify routing policy properties Read routing policy information Server authorizations Allow audits on this server Browse server assets Add new server into system Create ACL for server Decommission server Allow deploys on this server Discover this server Execute NSH scripts on server Create files on server Delete files on server Modify files on server Modify server metadata Modify ACL for server
1080
Name Server.ModifyProperties Server.PushACL Server.Read Server.Snapshot Server.StartService Server.StopService ServerGroup.* ServerGroup.Create ServerGroup.CreateACL ServerGroup.Delete ServerGroup.Modify ServerGroup.ModifyACL ServerGroup.Read ServerGroup.Write SnapshotJob.* SnapshotJob.Break SnapshotJob.Cancel SnapshotJob.Create SnapshotJob.CreateACL SnapshotJob.Delete SnapshotJob.Execute SnapshotJob.Modify SnapshotJob.ModifyACL SnapshotJob.ModifyProperties SnapshotJob.ModifySchedule SnapshotJob.ModifyTargets SnapshotJob.Read SolarisSoftware.* SolarisSoftware.Create SolarisSoftware.CreateACL SolarisSoftware.Delete SolarisSoftware.Modify SolarisSoftware.ModifyACL SolarisSoftware.ModifyProperties SolarisSoftware.Read SystemPackage.* SystemPackage.Create SystemPackage.CreateACL SystemPackage.Delete
Description Modify server properties Push ACLs to agent Read server properties and other metadata Allow snapshots on this server Start server services Stop server services Server group management Create new server group Create ACL for server group Delete server group Modify server group Modify ACL for server group Open server group Add objects to server group Snapshot Job management Break Snapshot Jobs dependencies Cancel Snapshot Job Create new Snapshot Job Create ACL for Snapshot Job Delete Snapshot Job Execute Snapshot Job Modify Snapshot Job Modify ACL for Snapshot Job Modify Snapshot Job properties Modify Snapshot Job schedule Modify Snapshot Job targets Read Snapshot Job Software authorizations Create new depot software Create ACL for depot software Delete depot software Modify depot software Modify ACL for depot software Modify depot software properties Open depot software System package management Create new system package Create ACL for system package Delete system package
Appendix A
1081
Name SystemPackage.Modify SystemPackage.ModifyACL SystemPackage.ModifyProperties SystemPackage.Read SystemPackageFolder.* SystemPackageFolder.Create SystemPackageFolder.CreateACL SystemPackageFolder.Delete SystemPackageFolder.Modify SystemPackageFolder.ModifyACL SystemPackageFolder.Read SystemPackageFolder.Write SystemPackageType.* SystemPackageType.Create SystemPackageType.Delete SystemPackageType.Modify SystemPackageType.Read UCSProvisionJob.* UCSProvisionJob.Cancel UCSProvisionJob.Create UCSProvisionJob.CreateACL UCSProvisionJob.Delete UCSProvisionJob.Execute UCSProvisionJob.Modify UCSProvisionJob.ModifyACL UCSProvisionJob.ModifyProperties UCSProvisionJob.ModifySchedule UCSProvisionJob.ModifyTargets UCSProvisionJob.Read UCSTemplate.* UCSTemplate.Create UCSTemplate.CreateACL UCSTemplate.Delete UCSTemplate.Modify UCSTemplate.ModifyACL UCSTemplate.ModifyProperties UCSTemplate.Read UpdatePropertiesJob.* UpdatePropertiesJob.Break
Description Modify system package Set system package ACL Modify system package properties Open system package System package folder management Create new system package folder Create ACL for system package folder Delete system package folder Modify system package folder Set system package folder ACL Open system package folder Add to a system package folder System package type management Create new system package type Delete system package type Modify system package type Open system package type UCS Provision Job management Cancel job Create new UCS Provision Job Create ACL for UCS Provision Job Delete UCS Provision Job Execute UCS Provision Job Modify UCS Provision Job Modify ACL for UCS Provision Job Modify UCS Provision Job properties Modify UCS Provision Job schedule Modify UCS Provision Job targets Read UCS Provision Job UCS template management Create new UCS template Create ACL for UCS template Delete UCS template Modify UCS template Modify ACL for UCS template Modify UCS template properties Open UCS template Update Server Properties Job management Break Update Server Properties Jobs dependencies
1082
Name UpdatePropertiesJob.Cancel UpdatePropertiesJob.Create UpdatePropertiesJob.CreateACL UpdatePropertiesJob.Delete UpdatePropertiesJob.Execute UpdatePropertiesJob.Modify UpdatePropertiesJob.ModifyACL UpdatePropertiesJob.ModifyProperties UpdatePropertiesJob.ModifySchedule UpdatePropertiesJob.ModifyTargets UpdatePropertiesJob.Read UpgradeModelObjects.* UpgradeModelObjects.Break UpgradeModelObjects.Cancel UpgradeModelObjects.Create UpgradeModelObjects.CreateACL UpgradeModelObjects.Delete UpgradeModelObjects.Execute UpgradeModelObjects.Modify UpgradeModelObjects.ModifyACL UpgradeModelObjects.ModifyProperties UpgradeModelObjects.ModifySchedule UpgradeModelObjects.ModifyTargets UpgradeModelObjects.Read User.* User.Create User.CreateACL User.Delete User.Modify User.ModifyACL User.ModifyProperties User.Read User.SetPassword UuidPool.* UuidPool.Create UuidPool.CreateACL UuidPool.Delete UuidPool.Modify UuidPool.ModifyACL
Description Cancel Update Server Properties Job Create new Update Server Properties Job Create ACL for Update Server Properties Job Delete Update Server Properties Job Execute Update Server Properties Job Modify Update Server Properties Job Modify ACL for Update Server Properties Job Modify Update Server Properties Job properties Modify Update Server Properties Job schedule Modify Update Server Properties Job targets Read Update Server Properties Job Upgrade Model Objects Job management Break Upgrade Model Objects Jobs dependencies Cancel job Create Upgrade Model Objects Job Create ACL for Upgrade Model Objects Job Delete Upgrade Model Objects Job Execute Upgrade Model Objects Job Modify Upgrade Model Objects Job Modify ACL for Upgrade Model Objects Job Modify Upgrade Model Objects Job properties Modify Upgrade Model Objects Job schedule Modify Upgrade Model Objects Job targets Read Upgrade Model Objects Job User management Create new user Create ACL for user Delete user Modify user information Modify ACL for user Modify user properties Read user information Set user password Uuid pool management Create new uuid pool Create ACL for uuid pool Delete uuid pool Modify uuid pool Modify ACL for uuid pool
Appendix A
1083
Name UuidPool.ModifyProperties UuidPool.Read VirtualGuestJob.* VirtualGuestJob.Cancel VirtualGuestJob.Create VirtualGuestJob.CreateACL VirtualGuestJob.Delete VirtualGuestJob.Execute VirtualGuestJob.Modify VirtualGuestJob.ModifyACL VirtualGuestJob.ModifyProperties VirtualGuestJob.ModifySchedule VirtualGuestJob.ModifyTargets VirtualGuestJob.Read VirtualGuestPackage.* VirtualGuestPackage.Create VirtualGuestPackage.CreateACL VirtualGuestPackage.Delete VirtualGuestPackage.Modify VirtualGuestPackage.ModifyACL VirtualGuestPackage.ModifyProperties VirtualGuestPackage.Read VSMDiscoveryJob.* VSMDiscoveryJob.Break VSMDiscoveryJob.Cancel VSMDiscoveryJob.Create VSMDiscoveryJob.CreateACL VSMDiscoveryJob.Delete VSMDiscoveryJob.Execute VSMDiscoveryJob.Modify VSMDiscoveryJob.ModifyACL VSMDiscoveryJob.ModifyProperties VSMDiscoveryJob.ModifySchedule VSMDiscoveryJob.ModifyTargets VSMDiscoveryJob.Read WindowsSoftware.* WindowsSoftware.Create WindowsSoftware.CreateACL WindowsSoftware.Delete
Description Modify uuid pool properties Open uuid pool Virtual Guest Job management Cancel job Create Virtual Guest Job Create ACL for Virtual Guest Job Delete Virtual Guest Job Execute Virtual Guest Job Modify Virtual Guest Job Modify ACL for Virtual Guest Job Modify Virtual Guest Job properties Modify Virtual Guest Job schedule Modify Virtual Guest Job targets Read Virtual Guest Job Virtual Guest Package management Create Virtual Guest Package Create ACL for Virtual Guest Package Delete Virtual Guest Package Modify Virtual Guest Package Modify ACL for Virtual Guest Package Modify Virtual Guest Package properties Read Virtual Guest Package VSM Discovery Job management Break VSM Discovery Jobs dependencies Cancel job Create new VSM Discovery Job Create ACL for VSM Discovery Job Delete VSM Discovery Job Execute VSM Discovery Job Modify VSM Discovery Job Modify ACL for VSM Discovery Job Modify VSM Discovery Job properties Modify VSM Discovery Job schedule Modify VSM Discovery Job targets Read VSM Discovery job Software authorizations Create new depot software Create ACL for depot software Delete depot software
1084
Name WindowsSoftware.Modify WindowsSoftware.ModifyACL WindowsSoftware.ModifyProperties WindowsSoftware.Read WwnPool.* WwnPool.Create WwnPool.CreateACL WwnPool.Delete WwnPool.Modify WwnPool.ModifyACL WwnPool.ModifyProperties WwnPool.Read
Description Modify depot software Modify ACL for depot software Modify depot software properties Open depot software Wwn pool management Create new wwn pool Create ACL for wwn pool Delete wwn pool Modify wwn pool Modify ACL for wwn pool Modify wwn pool properties Read wwn pool
Appendix A
1085
1086
Appendix
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
Appendix B
1087
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
1088
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
Appendix B
1089
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
1090
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*
Appendix B
1091
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
1092
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*
Appendix B
1093
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
1094
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
Appendix B
1095
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
1096
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 B
1097
1098
Appendix
Security settings for Windows 2008, 2003, and 2000

C
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 Accounts: Administrator account status Windows 2000 Setting Not available Passprop.exe is used for this setting on Windows 2000. Not available Not available Rename administrator account Rename guest account Audit the access of global system objects Audit the use of Backup and Restore privilege Shut down system immediately if unable to log security audits
Accounts: Guest account status Accounts: Limit local account use of blank passwords to console logon only Accounts: Rename administrator account Accounts: Rename guest account Audit: Audit the access of global system objects Audit: Audit the use of Backup and Restore privilege Audit: Shut down system immediately if unable to log security audits
Devices: Allow undock without having to log Not available on
Appendix C
1099
Windows 2003 or 2008 Setting Devices: Allowed to format and eject removable media
Windows 2000 Setting Allowed to eject removable NTFS media
Devices: Prevent users from installing printer Prevent users from installing printer drivers drivers Devices: Restrict CD-ROM access to locally logged-on user only Devices: Restrict floppy access to locally logged-on user only Devices: Unsigned driver installation behavior Not available in Windows 2008. Domain controller: Allow server operators to Domain controller: Allow server operators to schedule tasks schedule tasks (Domain controllers only) Domain controller: LDAP server signing requirements Domain controller: Refuse machine account password changes Domain member: Digitally encrypt or sign secure channel data (always) Domain member: Digitally encrypt secure channel data (when possible) Domain member: Digitally sign secure channel data (when possible) Domain member: Disable machine account password changes Domain member: Maximum machine account password age Domain member: Require strong (Windows 2000 or later) session key Interactive logon: Display user information when the session is locked Not available in Windows 2008. Interactive logon: Do not display last user name Interactive logon: Do not require CTRL+ALT+DEL Interactive logon: Message text for users attempting to log on Interactive logon: Message title for users attempting to log on Do not display last user name in logon screen Disable CTRL+ALT+DEL requirement for logon Message text for users attempting to log on Message title for users attempting to log on Not available Not available Secure channel: Digitally encrypt or sign secure channel data (always) Secure channel: Digitally encrypt secure channel data (when possible) Secure channel: Digitally sign secure channel data (when possible) Prevent system maintenance of computer password Not available Secure channel: Require strong (Windows 2000 or later) session key Not available Restrict CD-ROM access to locally logged-on user only Restrict floppy access to locally logged-on user only Unsigned driver installation behavior
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)
1100
Windows 2003 or 2008 Setting Interactive logon: Prompt user to change password before expiration
Windows 2000 Setting Prompt user to change password before expiration
Interactive logon: Require Domain Controller Not available authentication to unlock workstation Interactive logon: Require smart card Interactive logon: Smart card removal behavior Microsoft network client: Digitally sign communications (always) Microsoft network client: Digitally sign communications (if server agrees) Microsoft network client: Send unencrypted password to third-party SMB servers Microsoft network server: Amount of idle time required before suspending session Microsoft network server: Digitally sign communications (always) Microsoft network server: Digitally sign communications (if client agrees) Microsoft network server: Disconnect clients when logon hours expire Network access: Allow anonymous SID/Name translation Network access: Do not allow anonymous enumeration of SAM accounts Network access: Do not allow anonymous enumeration of SAM accounts and shares Note: Shows as Enabled and Disabled Not available Interactive logon: Smart card removal behavior Digitally sign client communication (always) Digitally sign client communication (when possible) Send unencrypted password to connect to third-party SMB servers Amount of idle time required before disconnecting session Digitally sign server communications Digitally sign server communication (when possible) Automatically logoff users when logon time expire (local) Not available Not available Additional restrictions for anonymous accounts. 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 credentials or .NET Passports for network authentication Network access: Let Everyone permissions apply to anonymous users Not available
Not available
Appendix C
1101
Windows 2003 or 2008 Setting Network access: Named Pipes that can be accessed anonymously
Windows 2000 Setting Not available
Network access: Remotely accessible registry Not available paths and sub-paths Network access: Restrict anonymous access to Named Pipes and Shares Network access: Shares that can be accessed anonymously Network access: Sharing and security model for local accounts Network security: Do not store LAN Manager hash value on next password change Network security: Force logoff when logon hours expire Network security: LAN Manager authentication level Network security: LDAP client signing requirements Not available Not available Not available Not available
Automatically log off users when logon time expires LAN Manager authentication level Not available
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 administrative logon Recovery console: Allow floppy copy and access to all drives and all folders Shutdown: Allow system to be shut down without having to log on Shutdown: Clear virtual memory page file System cryptography: Force strong key protection for user keys stored on the computer System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing System objects: Default owner for objects created by members of the Administrators group Not available in Windows 2008. System objects: Require case insensitivity for Not available non-Windows subsystems 1102 BMC BladeLogic User Guide Recovery console: Allow automatic administrative logon Recovery console: Allow floppy copy and access to all drives and all folders Allow system to be shut down without having to log on Clear virtual memory page file when system shuts down Not available
Not available
Not available
Windows 2003 or 2008 Setting System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links) System settings: Optional subsystems System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies Not available
Windows 2000 Setting Strengthen default permissions of global system objects (e.g. Symbolic Links) Not available Not available
Unsigned non-driver installation behavior
Appendix C
1103
1104
Appendix
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 XMLbased 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 operators grammars
Description A list of available operators used within rules or signatures. A list of grammar files used by configuration files and extended objects.
Appendix D
Content format
1105
Overview of content format XML files
Entity in content format packages
Description 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. Definitions for the following types of data used in BMC BladeLogic (as accepted, for example, by rules, properties, or configuration objects):

types
primitivesbuilt-in data types, such as Date or Boolean enumerations ranges lists property classes configuration objects
data instances rule library
Definitions of a property class instance. A library of compliance rules or discovery signatures. No corresponding entity exists in the BMC BladeLogic GUI.
services service instances policies
A group of definitions for a component template. Each defined service corresponds to a single component template. Each service instance corresponds to an instance of a local property set defined for a component template. 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.
1106
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).
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.
NOTE
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" shortid="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.
Appendix D
Content format
1107
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>
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.
NOTE
1108
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
<primitives> <primitive name="Decimal" id="Primitive:Decimal"> <operators> <operator-ref id="greater than or equal to"/> <operator-ref rhs-type="Range:Primitive:Decimal Range" id="between"/> <operator-ref id="equals"/> <operator-ref id="does not equal"/> <operator-ref rhs-backing-type="Primitive:Decimal" rhs-type="List" id="is not one of"/> <operator-ref rhs-backing-type="Primitive:Decimal" rhs-type="List" id="is one of"/> <operator-ref id="greater than"/> </operators> </primitive> </primitives>
Description Primitives are the most basic data forms, such as those based on simple strings or numbers. For each primitive you specify an ID and a name, as well as a list of operators supported by the primitivea. The ID of a primitive always begins with the Primitive: prefix.
Appendix D
Content format
1109
Types
XML code
<enumerations> <enumeration name="ServiceErrorControlEnumeration" id="Enumeration:ServiceErrorControlEnumeration" type="Primitive:String" built-in="true"> <value name="IGNORE" id="IGNORE">IGNORE</value> <value name="NORMAL" id="NORMAL">NORMAL</value> <value name="SEVERE" id="SEVERE">SEVERE</value> <value name="CRITICAL" id="CRITICAL">CRITICAL</value> </enumeration> </enumerations> <ranges> <range name="Integer Range" id="Range:Primitive:Integer Range" type="Primitive:Integer"> <operators> <operator-ref id="equals"/> <operator-ref id="does not equal"/> </operators> </range> <range name="Date Range" id="Range:Primitive:Date Range" type="Primitive:Date"> <operators> <operator-ref id="equals"/> <operator-ref id="does not equal"/> </operators> </range> <range name="Decimal Range" id="Range:Primitive:Decimal Range" type="Primitive:Decimal"> <operators> <operator-ref id="equals"/> <operator-ref id="does not equal"/> </operators> </range> </ranges> <lists> <list type="Class://SystemObject/Device"> <operators> <operator-ref rhs-type="Class://SystemObject/Device" id="contains"/> <operator-ref id="equals"/> <operator-ref id="does not equal"/> </operators> </list> <list type="Primitive:Encrypted String"> <operators> <operator-ref rhs-type="Primitive:Encrypted String" id="contains"/> <operator-ref id="equals"/> <operator-ref id="does not equal"/> </operators> </list> </lists>
Description The enumeration data type enforces a choice of values from a closed list. The ID of an enumeration always begins with the Enumeration: prefix.
A range defines values between two points. Supported operators are listed for each range. Currently, BladeLogic supports only the three ranges presented here. The ID of a range always begins with the Range: prefix.
The list data type accepts multiple values provided by the user. For each list you specify the list type and provide a list of operators supported by the lista.
1110
Types
XML code
<property-classes> <class visible="true" deprecated="false" name="Class://SystemObject/User" id="Class://SystemObject/User" built-in="true"> <description>Every User is an Instance of this Class</description> <operators> <operator-ref rhs-type="Primitive:String" id="not instance of"/> <operator-ref rhs-type="Primitive:String" id="instance of"/> <operator-ref id="equals"/> <operator-ref id="does not equal"/> </operators> <properties> <property deprecated="false" editable="false" builtin="true" required="true" used-in-report="false" id="DEFAULT_ROLE" type="Class://SystemObject/Role"> <description>Default Role</description> </property> <property deprecated="false" editable="false" builtin="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" builtin="false" required="false" used-in-report="false" id="MY_INTEGER_ENUM" type="enumeration"> <description></description> <enumeration type="Primitive:Integer"> <value name="intvalue1" id="intvalue1">1</value> <value name="intvalue2" id="intvalue2">2</value> </enumeration> <default> <value>1</value> </default> </property> </properties> </class> </property-classes>
Description Definitions of property classes as configured in the Property Dictionary (see Using the Property Dictionary on page 118). For each property class you provide a list of operators supported by the property classa, as well as an optional list of properties included in the class. The ID of a property class always begins with the Class: prefix, and includes the full path to the property class within the Property Dictionary (for example: //SystemObject/User).
Appendix D
Content format
1111
Data instances
XML code
<configuration-objects> <extended-objects> <extended-object id="Groups"> <description></description> <grammar-data grammar-ref="ini.gm" os="Windows" encoding="Default"/> <command remote-execution="false">blquery $server:host$ -E "/C/Program Files/BMC Software/BladeLogic/ 8.0/share/sensors/extended_objects/groups.blq"</command> </extended-object> </extended-objects> <server-objects> <class root="false" version="1" name="Extended Object" id="Extended Object" built-in="true"> <properties> <property name="Path" id="Path" type="Primitive:String"/> <property name="Name" id="Name" type="Primitive:String"/> </properties> </class> </server-objects> <configuration-files> <configuration-file id="??TARGET.WINDIR??/desktop.ini"> <grammar-data grammar-ref="ini.gm" os="Windows" encoding="Default"/> <path>??TARGET.WINDIR??/desktop.ini</path> </configuration-file> </configuration-files> </configuration-objects> a
Description Definitions of configuration objects (extended objects, server objects, or configuration files), as defined in the Configuration Object Dictionary (see Using the Configuration Object Dictionary on page 627).
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.
1112
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"> <value>Non-Applicable</value> </property> <property id="VIRTUAL_DIR"> <value>Non-Applicable</value> </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.
Appendix D
Content format
1113
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:
1114
Services
XML code
<services> <folder name="Component Template Group"> <service id="internal_service_id"> <notes>notes for service</notes> </service> </folder> </services> <allowed-operations> <operation id="Discover"/> <operation id="Snapshot"/> <operation id="Audit"/> <operation id="Deploy"/> <operation id="Compliance"/> <operation id="Allow_Remediation"/> <operation id="Allow_Auto_Remediation"/> </allowed-operations> <configuration-objects> <extended-objects> <extended-object id="Groups"> <description></description> <grammar-data grammar-ref="ini.gm" os="Windows" encoding="Default"/> <command remote-execution="false">blquery $server:host$ -E "/C/Program Files/BMC Software/BladeLogic/8.0/share/sensors/ extended_objects/groups.blq"</command> </extended-object> </extended-objects> <server-objects> <class root="false" version="1" name="Extended Object" id="Extended Object" built-in="false"> <properties> <property name="Path" id="Path" type="Primitive:String"/> <property name="Name" id="Name" type="Primitive:String"/> </properties> </class> </server-objects> <configuration-files> <configuration-file id="??TARGET.WINDIR??/desktop.ini"> <grammar-data grammar-ref="ini.gm" os="Windows" encoding="Default"/> <path>??TARGET.WINDIR??/desktop.ini</path> </configuration-file> </configuration-files> </configuration-objects> <properties> <property id="AUTO_GENERATED"> <value>true</value> </property> </properties>
Equivalent BladeLogic configuration The folder corresponds to a component template group. The service ID is used internally in the file for associating other objects, such as entities, to services. Allowed operations for a component template, as defined on the General panel (see General on page 261)
Local configuration objects for a component template (extended objects, server objects, or configuration files), as defined on the Local Configuration Objects panel (see Local configuration objects on page 293)
Properties assigned to the component template, not including local properties.
Appendix D
Content format
1115
Services
XML code
<local-properties> <property deprecated="false" editable="true" built-in="false" required="false" used-in-report="false" id="MY_INTEGER_ENUM" type="enumeration"> <description></description> <enumeration type="Primitive:Integer"> <value name="intvalue1" id="intvalue1">1</value> <value name="intvalue2" id="intvalue2">2</value> </enumeration> <default> <value>1</value> </default> </property> <property deprecated="false" editable="true" built-in="false" required="false" used-in-report="false" id="TEST_INTEGER" type="Primitive:Integer"> <description></description> <default> <value>10</value> </default> </property> </local-properties> <parts> <part id="File:??EXTPROC_HOME??/extproc.exe"> <notes>My part notes</notes> <item> <type>File</type> <path>??EXTPROC_HOME??/extproc.exe</path> </item> <allowed-operations> <operation id="Discover"/> <operation id="Snapshot"/> <operation id="Audit"/> <operation id="Compliance"/> </allowed-operations> <includes-excludes recurse-subfolders="true"/> </part> <part id="Windows Service:BladeLogic RSCD Agent"> <notes></notes> <item> <type>Windows Service</type> <path>BladeLogic RSCD Agent</path> </item> <allowed-operations> <operation id="Browse"/> <operation id="Snapshot"/> <operation id="Audit"/> <operation id="Compliance"/> </allowed-operations> <includes-excludes recurse-subfolders="true"/> </part> </parts>
Equivalent BladeLogic configuration Local properties assigned to the component template, as defined on the Local Properties panel (see Local properties on page 291)
The server objects that make up the component template, as defined on the Parts panel (see Parts on page 262)
1116
Service instances
XML code
<signature> <rule name="Template Signature" service="xml test service"> <expression><![CDATA[??TARGET.OS?? is one of ["AIX", "Linux", "HP-UX", "Windows"]]]></expression> </rule> </signature>
Equivalent BladeLogic configuration The component signature used in discovery, as defined on the Discovery panel (see Discover on page 264) 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"> <description></description> <property id="NAME"> <value>oracle1</value> </property> <property id="DESCRIPTION"> <value>oracle1 description</value> </property> <property id="ORACLE_HOME"> <value>/C/Program Files/Oracle</value> </property> <property id="PATH"> <value>My Path</value> </property> </instance> <instance id="oracle2"> <description></description> <property id="NAME"> <value>oracle2</value> </property> <property id="DESCRIPTION"> <value>null</value> </property> <property id="ORACLE_HOME"> <value>/D/Program Files/Oracle</value> </property> </instance> </service-ref> </service-instances>
Appendix D
Content format
1117
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.
1118
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.
Appendix D
Content format
1119
Policies
1120
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.
1121
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.
1122
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).
1123
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.
1124
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 subclass 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 subclasses. 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.
1125
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.
1126
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.
1127
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.
BMC BladeLogic Glossary 1129
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.
1130
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.
1131
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.
1132
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.
1133
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
1134
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.
1135
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 provisioning process. time-out A maximum period of time that can elapse before a job or job part is automatically canceled. You assign properties to jobs that specify time-out values for the job or for job parts. Transport Layer Security (TLS) A protocol providing confidentiality, authentication, and integrity for stream-like connections. TLS is typically used to secure HTTP connections. TLS is the successor to the Secure Socket Layer (SSL) protocol. BMC 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.
1136
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.
BMC BladeLogic Glossary 1137
1138
Index
Symbols
%f macro 406 %h macro 406 SNMP notification options 201 Targets panel 197 ACL templates creating 148, 161 general information 162 modifying 164 permissions 164 template contents 162 ACLs avoiding common mistakes 191 for files 235 for one or more system objects 190 for property classes 138 for registry keys 235 for system objects 99, 186, 191 previewing 194 pushing to agents 192, 194, 195 pushing to servers 194 setting up for roles 175 action on failure in BLPackages 391 Active Directory browsing 231 custom configuration objects 237 defined 1121 objects 239 synchronizing with RBAC 184, 185 activity view of jobs 438 AD/Kerberos authentication defined 1121 Add Depot Software wizard Add Software panel 354, 366 Permissions panel 365, 372 Properties panel 364, 372 Add File to Depot wizard General panel 410 Permissions panel 411 Properties panel 410 Add Install Client script Solaris system package 980 Add NSH Script to Depot wizard Parameters panel 406 Permissions panel 408 Properties panel 408 Script Options panel 405
A
access control enforcing 151 managing 145 overview 145 system package sharing 1005 understanding 145 access control list templates 161, 162, 164 access control lists for ACL policies 166, 167 for ACL templates 164 for authorization profiles 160 for automation principals 171 for files 235 for one or more system objects 190 for property classes 138 for registry keys 235 for roles 178 for system objects 99, 186, 191 for users 183 Accessibility general preference setting 78 accessing views 63 ACL policies access control list 166 adding a maintenance window 168 creating 149, 165 general information 166 modifying 167 permissions 167 ACL Push Jobs creating 195 Default Notifications panel 198 email notification options 201 General panel 196 modifying 203 Permissions panel 203 Properties panel 202 schedule options 200 Schedules panel 199
Index
1139
Script panel 409 Add Software panel for Add Depot Software wizard 354, 366 add_install_client command customizing 980 administrative tools 623 configuration files 629 Configuration Object Dictionary 627 custom commands 623, 624, 627 custom configuration objects 628, 640, 641 custom icons 639 extended objects 636 server objects 628, 641 SOCKS proxy servers 667 Advanced Options panel File Deploy Job 513 AES defined 1121 agent ACLs pushing during provisioning 946, 958, 969, 982, 992, 1003 pushing to agents 192, 194, 195, 197 setting up for roles 175 understanding 192 agents 29 AIX packages 353 patches 353 AIX system package basic configuration 987 control flow 995 firstboot script/agent install 992 local properties 994 localization settings 989 network settings 991 NIM scripts 994 optional Bosinst attributes 996 Post bos_inst script 997 Pre bos_inst script 996 Pre machine definition scripts 996 preview 997 target disk 989 All perspective 61 Annotations general preference setting 78 Appearance 76 Application Automation described 24 Application Servers connecting to BMC BladeLogic console 40 information about 665 introduced 31 limiting configuration file records 627 reporting information about 666 tier 30 Approval Information panel setting approval type 424 setting change request parameters 422 Using existing Change Ticket option 426 architecture of BMC BladeLogic 30 assets importing into BLPackages 402 Associated Compliance Rules panel for component exception wizard 311 asymmetric encryption defined 1122 Audit Jobs Component Templates for Filtering panel 478 creating 475 Default Notifications panel 485 email notification options 489 General panel 477 includes and excludes 480 master 479 Masters panel 478 modifying 491 options list 482 Permissions panel 491 Properties panel 490 Schedules panel 487 server objects list 479 Server Objects panel 479 SNMP notification options 489 Targets panel 484 wizard 475 audit options for component templates 257 audit results 492 exporting 472 packaging 502 using to group servers 498 using to sync servers 499 viewing by object 493 viewing by server 495 viewing text file differences 497 Audit Trail view 98, 99 audit trails for system authorizations 156, 158 managing 152 viewing 99 auditing and symbolic links 450 components 268, 269, 475, 477 configuration files 498 exporting results 472 master 492 schedule options 487 snapshots 475 understanding 450 viewing results 492, 493, 495 viewing text file differences 497 Authentication Profiles setting up 38
1140
authorization profiles assigning to roles 174 creating 148, 159 modifying 160 permissions 160 selecting authorizations 160 authorizations 151 command 156, 157, 158 complete list 1067 creating policies for managing 165 creating profiles of 159 effective 147 enforcing 151 managing 147 modifying profiles of 160, 167 object-based 146 resource-based 147 role 146, 174 selecting for authorization profiles 160 setting up 148, 156 system 156, 158 understanding 145 automation principals creating 149, 169, 172 general information 170 modifying 171 permissions for 171 properties 171 auto-remediation for Compliance Jobs 316 Auto-remediation panel for Compliance Jobs 316 AutoYaST entries Linux system package 956 email notification options 587 including in Provision Jobs 924 Permissions panel 584 Properties panel 584 schedule options 586 Schedules panel 585 SNMP notification options 587 begin script Solaris system package 981 when provisioning servers 1030 BL Editor editing text files 69 viewing text files 69 bladduser utility 204, 205 BLAdmin user 153, 156 adding 204 BLAdmins role 153 BLPackage Deploy Jobs creating 527 Default Notifications panel 535 deploying security settings 556 General panel 529 Job Options panel 543 Package panel 530 Permissions panel 555 Phase Options panel 551 Phases and Schedules panel 536 Properties panel 554 BLPackages 349 adding custom actions 401 adding external commands 403 adding local properties 396 adding to Depot 375 caveats 528 closing an edited package 404 commenting out assets 403 creating from audit results 499, 502 creating from components 343 creating from snapshot results 469 creating RPM groups 402 deleting objects while editing 398 deploying 521, 528 deploying to multiple components 532 deploying to remediate compliance results 316, 340, 342 editing 383, 385, 387, 388, 389, 391, 393, 395, 396, 397 exporting 101, 102 finding and replacing text in instruction file 399 importing 101, 104 importing assets into 401, 402 includes and excludes 379 Map Missing 112 opening for edit 385 overview 351 packaging a component 343 setting action on failure 391 verifying 404
B
backgrounding operations 67 backup options for deploying files 511 basic conditions in compliance rules 275, 276, 277 in signatures 264, 265, 277 basic configuration AIX system package 987 HP-UX system package 998 Linux system package 951 Solaris system package 974 VMware system package 964 when provisioning servers 1028 Windows system package 931 Batch Job Options panel for Batch Jobs 581 Batch Jobs 579 Batch Job Options panel 581 creating 579
Index
1141
BMC BladeLogic administrative tools 623 architecture 30, 31, 32 BLPackages 349 component templates 243 components 243 deploying BLPackages 521 deploying files 505 deploying packages 521 deploying software 521 described 23 exporting 101, 102 folder 73 folders 84 getting started 37 importing 101, 104 managing access 145 managing jobs 413 managing properties 117 managing servers 207 managing the console 73 overview 29, 29, 33 snapshots 449 software packages 349 starting 40 Tasks in Progress view 67, 427 viewing dependencies 68, 99 BMC BladeLogic console 84 content editor 57 customizing preferences 73 editor 57 elements 51 global menu bar 54 global tool bar 54 managing 73 menus 58 perspective 55 perspectives 58 provisioning 72 Quick Access 57 quick tour 57 tab group 56 title bar description 54 tool bars 58 view 56 views 58 BMC Preferences Display Options 75 File Deploy Options 75 Live Browse Results Option 76 Paging Options 76 BMC Software, contacting 2 boot image files assigning to a device 1008 configuring 919 copy of WinPE 1.6 image to TFTP server 897 copy of WinPE 2.x image to a location for provisioning 884 creating 868 for booting from local media 1045 for booting from PXE server with local data store 1048 placeholders for 869 broken dependencies finding 98 browsing virtual machines 593
C
canceling jobs 428 cardinality conditions in compliance rules 275, 278 in signatures 264 catalogs for patches 697, 701, 707, 711, 712, 732, 736, 742, 743, 747, 748, 764, 769, 778, 782, 783, 800, 806, 811, 812, 828, 834, 839, 840 certificate authority defined 1123 certificates defined 1124 untrusted 43 viewing or deleting 45 viewing untrusted 43 change a perspective 63 change tracking 459, 463 changes removing 468 tracking internal and external 468 using the compare editor 469 Changing perspectives 59 changing the sort order of a column 83 character encoding for text files 69, 70 Child Explorer tables customizing 81 choosing editors 71 Classic perspective 61 perspectives Classic 61 Classic2 perspective 61 clearing filters 67 client tier 30 of BMC BladeLogic 31 Colors and Fonts general preference setting 76 columns changing sort order 83 customizing 81 formatting 83 commands adding 157
1142
authorizing for roles 174 deleting 158 modifying 157 commit options for deploying packages 552 Compare Editor for viewing changes 469 Compare/Patch general preference setting 77 compliance and remediation 289 exceptions 305, 307 of components 273, 290, 312, 330 Compliance Exceptions panel for New Component wizard 305 Compliance Job results 331, 340, 342, 344 acting on remediation results 338 defining exceptions 337 undoing remediation 339 using to edit compliance rule 336 viewing by rule 332 viewing by server 333 viewing for compliance rules 334 viewing remediation results 338 Compliance Jobs and component templates 271 automatically remediating results 316 Component Templates for Filtering panel 315 component templates list 315 Components panel 315 creating 312 Default Notifications panel 324 email notification options 328 exporting results 344 General panel 314 manually remediating results 340 modifying 330 Permissions panel 330 Properties panel 329 remediating results 342 results 331, 340, 344 schedule options 326 Schedules panel 326 setting deploy values for remediation jobs 318 SNMP notification options 328 viewing and using results 331 Compliance Rule Editor General panel 274 Remediation Options panel 289 Rule Definition panel 275 compliance rules commenting and uncommenting 290 copying, cutting, and pasting 290 creating or editing 273, 276 defining exceptions 309, 310, 311, 312, 337 editing 274, 275 editing from compliance results 336 elements within 275 operand data types 283 operators 283 viewing as part of Compliance Job results 334 Component Discovery Jobs 248 Component Templates panel 296 creating 294 Default Notifications panel 298 email notification options 301 General panel 295 modifying 302 Permissions panel 302 Properties panel 302 schedule options 300 Schedules panel 299 SNMP notification options 301 Targets panel 298 Component folder 85 component groups 90, 91 adding components 312 smart 92 Component Template folder 85 component templates 243 adding local properties 291, 292 adding parts 253 and Compliance Jobs 271 auto-remediation 289 compliance 290 compliance rule groups 273 compliance rules 273, 274, 275, 290 creating 251 defining a signature 264 defining in a content format file 1114 discovering 264, 296, 298 editing 260 editing compliance rules 336 includes and excludes 255 list of snapshot and audit options 257 local properties 291 modifying parts 255, 262 parts 252, 253, 262 remediation options 289 snapshots and audits 268, 269 testing a signature 266 Component Templates folder 34, 85, 86, 250 adding folders 90, 91 adding smart groups 250 copying, cutting, and pasting 250 creating component templates 251 deleting 250 editing component templates 260 organizing contents 250 smart component template groups 92 Component Templates for Filtering panel for Audit Jobs 478 for Compliance Jobs 315 for Snapshot Jobs 454
Index
1143
component templates list for Audit Jobs 478 for Compliance Jobs 315 for Snapshot Jobs 454 Component Templates panel for Component Discovery Jobs 296 components 230, 243 adding manually 303 adding to component groups 312 auditing 475, 477, 478 browsing 268 checking compliance 312, 315, 330 compliance exceptions 307 compliance of 315 defining exceptions to compliance rules 309, 310, 311, 312, 337 discovering 248, 294, 302 exporting 101, 102 importing 101, 104 modifying 307 packaging and deploying 343 process for using 245, 248 running audits on 268, 269 snapshots of 268, 269, 452, 454 templates for 251, 260 Components folder 34, 85, 250 adding groups 90, 91 adding smart groups 250 copying, cutting, and pasting 250 deleting 250 organizing contents 250 smart component groups 92 Components panel for Compliance Jobs 315 for component exception wizard 312 for Create BLPackage wizard 378 computer settings HP-UX system package 999 Linux system package 952 Solaris system package 975 VMware system package 966 Windows system package 933 conditional constructs defining for compliance rule or signature 281 in compliance rules 275, 276, 280 in signatures 264, 265 conditions in compliance rules 275, 276, 277 in signatures 264, 265 configuration files auditing 498 exporting 101, 102 grammars for creating 632 identifying 627, 629 importing 101, 104 limiting records processed 627 paths to 48 configuration for provisioning custom system package types 907 image files 919 installation file locations 913 PXE server 915 TFTP server 916 configuration for provisioning servers 902 Configuration Object Dictionary 627, 639 adding custom configuration objects 628 configuration files 629 deleting custom configuration objects 640 extended objects 636 grammar files 632 server objects 628 configuration objects 236 deregistering 656 distributing 642 in content format files 1109 local 293 updating 649 console BMC BladeLogic 84 Component Templates folder 85 Components folder 85 content editor 57 customizing preference settings 73 Depot folder 85 Devices folder 86 editor 57 elements 51 global menu bar 54 global tool bar 54 Jobs folder 86 managing 73 menus 58 perspective 55 perspectives 58 Quick Access 57 quick tour 57 RBAC Manager folder 87 Search 88 Servers folder 88 tab group 56 Tasks in Progress view 67, 427 title bar description 54 tool bars 58 view 56 views 58 content editor 57 content editors BL Editor 69 selecting 71 setting preferences 71 ShellEd 70 working with 68 content format 1105 Content Types
1144
general preference setting 77 conventions documentation 26 Create BLPackage wizard Components panel 378 Depot Files panel 378 Master Snapshot panel 379 Package Contents panel 377 Package Options panel 381 Package Types panel 376 Permissions panel 382 Properties panel 382 Select Server Objects panel 377 Snapshots panel 378 Software panel 378 creating a maintenance window 168 creating folders or groups 91 creating new objects 88 custom actions for BLPackage assets 401 custom commands administering 623 creating and modifying 624 defining 623 deleting 627 executing 240 custom configuration object tables customizing 82 custom configuration objects 236, 238, 239 adding 628 deleting 640 using jobs to manage 641 versioning 237 custom icons defining 639 custom property classes adding 123 deprecating 131 removing 131 custom software adding to Depot 353 custom system package types 907 customer support 3 customize a perspective 63 customizing Child Explorer tables 81 columns from a pop-up menu 83 fixed-column tables 81 tables and columns 81 customizing custom configuration object tables 82 customizing keystroke combinations 79 customizing preferences 73 refreshing 84 data store 1027 configuring 903 data store instances local data store 1044 properties 1064 provisioning strategies 1064 databases connecting to Application Server 31 information about 667 decommissioning servers 228 Default Notifications panel for ACL Push Jobs 198 for Audit Jobs 485 for BLPackage Deploy Jobs 535 for Compliance Jobs 324 for Component Discovery Jobs 298 for Deregister Configuration Object Jobs 658 for Distribute Configuration Objects Jobs 644 for File Deploy Jobs 514 for Network Shell Script Jobs 571 for Snapshot Jobs 459, 584 for Software Deploy Jobs 535 for Update Server Properties Jobs 215 for Upgrade Model Objects Jobs 651 deleting groups and folders 96 system objects 96 dependencies between properties 126 broken 98 viewing 99 deploy activity and internal changes 469 showing 469 Deploy Jobs 521 commit options 552 controlling 561 controlling for servers 564 deploying to multiple components 532 email notification options 542 modifying 556 phase scheduling 538 phase selection 538 pre/post commands 553 Properties panel 554, 555 rebooting servers 563 running after packaging component 343 schedule options 541 servers not targeted by 564 setting options 318 simulate and stage options 551 SNMP notification options 542 states 559, 562 taking action on 561 taking actions on 560
D
data
Index
1145
Targets panel 535 undoing 562 using for uninstalling 557 using results 559 DEPLOY_ALLOW_NFS_DURING_SUM server property 565 Depot adding BLPackages 375 adding custom software 353 adding files 409, 410 adding folders 90, 91, 350 adding hotfixes 365, 366, 372 adding Network Shell scripts 404 adding smart groups 350 adding software packages 353 copying, cutting, and pasting 350 deleting 350 folder 34, 85 modifying Network Shell scripts 408 organizing contents 350 smart depot groups 92 Depot Files panel for Create BLPackage wizard 378 Depot folder Folders view 85 depot objects adding depot files 409 creating 349 Deregister Configuration Object Jobs 656 Default Notifications panel 658 email notification options 661 General panel 657 Permissions panel 663 Properties panel 662 schedule options 660 Selected Configuration Objects panel 658 Targets panel 658 detaching a view from the perspective 64 device permissions 1020 properties 1020, 1057 settings 1020 Devices folder Folders view 86 directories backup options when deploying 511 copying and pasting 233 deleting 234 discovery of components 264, 294, 302 testing for component templates 266 disk partition HP-UX system package 999 Linux system package 949 Solaris system package 972 VMware system package 962 Windows system package 929 Display Options for BMC Preferences 75 Distribute Configuration Object Jobs General panel 642 Permissions panel 648 Properties panel 648 schedule options 646 Selected Configuration Objects panel 643 Targets panel 644 Distribute Configuration Objects Jobs 642 Default Notifications panel 644 Distribute Configuration Update Jobs email notification options 647 docking a view 63 domain controller defined 1126 DOS scripting in system package 928
E
editing BLPackages 383 adding custom actions 401 adding external commands 403 adding local properties 396 changing file ownership attributes 395 changing network-based software deploy options 391 changing object attributes 385 changing object properties 393, 396 closing a package 404 commenting out assets 403 creating RPM groups 402 defining action on failure 391 deleting an object 398 finding text 399 importing assets 402 moving objects within 397 opening a BLPackage 385 ordering by dependency 397 providing password information 398 replacing text 399 setting a reboot 389 setting single user mode 388 verifying an object 404 working with soft links 387 editing component templates 260 browsing 268 compliance 271 discovery 264 general information 261 local configuration objects 293 local properties 291 parts 262 snapshots and audits 268 editor content editor 57 Editors
1146
general preference setting 78 editors BL Editor 69 selecting 71 setting preferences 71 ShellEd 70 working with 68 email notification options for ACL Push Jobs 201 for Audit Jobs 489 for Batch Jobs 587 for Compliance Jobs 328 for Component Discovery Jobs 301 for Deploy Jobs 542 for Execution Tasks 433 for File Deploy Jobs 517 for Network Shell Script Jobs 574 for Snapshot Jobs 463 for Update Server Properties Jobs 218, 647, 654, 661 encoding of characters 69, 70 entries in configuration files 48 ESX provisioning 960 ESX servers configuring properties 211 exceptions to compliance rules 309, 310, 311, 312, 337 excludes list for Audit Jobs 480 for BLPackages 379 for component templates 255 for Snapshot Jobs 455 Execution Tasks creating and fully defining 430 creating through jobs 429 deleting job runs 437 email notification options 433 executing 436 for managing job runs 429 modifying 435 schedule options 432 viewing history 436 Explorer perspective 61 export of Audit Job results 472 of Compliance Job results 344 of Snapshot Job results 472 of system packages 1006 exporting 102 exporting objects 101 extended objects 230 creating icons 639 creating or modifying 627, 636 exporting 101, 102 grammars for creating 632 importing 101, 104 limiting records processed 627 external changes removing 468 tracking 468
F
fdisk partitions 984 File Associations general preference setting 78 File Deploy Jobs 505 Advanced Options panel 513 Default Notifications panel 514 email notification options 517 General panel 507 global deployment options 512 modifying 519 Options panel 509 Permissions panel 519 pre/post commands 513 Properties panel 518 schedule options 516 Schedules panel 515 Targets panel 508 File Deploy Options 75 File Deploy Options for BMC Preferences 75 file deploys 506 backup options 511 global deployment options 512 indirect push 510 pre/post commands 513 synchronized push 509 file ownership attributes changing in BLPackage 395 file paths rules for entering 47 file properties security 235 viewing 234 file servers 451 files adding to Depot 409, 410 backup options when deploying 511 copying and pasting 233 deleting 234 editing 69, 70 exporting 101, 102 grammar 632 importing 101, 104 filter 57 filters 66, 67 finding system objects with broken dependencies 98 fixed-column tables customizing 81 folder content
Index
1147
organizing 89 folders adding 250 adding groups or folders 89 adding smart groups 89 Component Templates 34, 85 Components 34, 85 copying, cutting, and pasting within 89 creating 89, 91 cutting and pasting 95, 96 deleting 96 Depot 34, 85 Devices 86 in BMC BladeLogic 84 Jobs 34, 86 organizing content 89 RBAC Manager 35, 87 Servers 33, 88 Folders view 85 Depot folder 85 Devices folder 86 Jobs folder 86 RBAC Manager folder 87 Search 88 Servers folder 88 formatting columns 83 Compare/Patch 77 Content Types 77 Editors 78 File Associations 78 Hyperlinking 78 Keys 79 Label Decorations 76 Quick Diff 78 Text Editors 78 General preferences Colors and Fonts 76 general preferences Appearance 76 Gentoo pre-installation image skipping during provisioning 901 getting started 37 Authentication Profiles 38 BMC BladeLogic 40 changing passwords 47 logging in 40 session credentials 44, 45 stored certificates 45 switching roles 46 global configuration parameters for patching 693, 727, 761, 797, 825 global deployment options for deploying files 512 global menu bar description 54 global preference settings 76 global tool bar 54 grammar files 632 importing 106 in content format files 1107 groups copying, cutting, and pasting 95, 96 creating 89, 90, 91 deleting 96
G
General panel for ACL Policy wizard 166 for ACL Push Jobs 196 for ACL Template wizard 162 for Add File to Depot wizard 410 for Audit Jobs 477 for Compliance Jobs 314 for Compliance Rule Editor 274 for Component Discovery Jobs 295 for component exception wizard 310 for Deploy Jobs 529 for Deregister Configuration Object Jobs 657 for Distribute Configuration Objects Jobs 642 for Execution Tasks 431 for File Deploy Job 507 for Network Shell 568 for New Component wizard 304 for Role wizard 174 for Snapshot Jobs 452 for Update Server Properties Jobs 213 for Upgrade Model Objects Jobs 650 General Preference 76 general preference setting Spelling 78 general preference settings 78 Accessibility 78 Annotations 78
H
Help Desk perspective 61 history viewing for jobs 438 hotfixes adding to Depot 365, 366, 372 deploying 525 modifying 372 HP-UX bundles 353 patches 353 products 353 provisioning 860 HP-UX system package basic configuration 998 boot script 1003
1148
computer settings 999 disk partition settings 999 Ignite commands/scripts 1001 Ignite parameters 1002 local properties 1004 network settings 1000 post-install script/agent install 1003 preview 1004 software selection 1002 hung jobs 443 Hyperlinking general preference setting 78 Hyper-V specifying in Windows system package 941 Map Missing Compliance Jobs 114 Map Missing Component Discovery Jobs 114 Map Missing Component Templates 113 Map Missing Deploy Jobs 115 Map Missing Depot Objects 113 Map Missing Network Shell Scripts 115 map missing properties 109 Map Missing Servers and Server Groups 108 Map Missing System Packages 112 Property Values Mapping 111 remediation group 107 servers 223 system packages 112, 1006 importing objects 101, 104 includes list for Audit Jobs 480 for BLPackages 379 for component templates 255 for Snapshot Jobs 455 indirect push for Deploy Jobs 536 for File Deploy Jobs 510 information for users in RBAC 180 infrastructure management Application Servers 665 database 667 job execution 683 PXE servers 666 routing rules 688 SOCKS proxy servers 667, 668 Infrastructure Management window 663, 673 InstallShield packages adding to Depot 353 installing 525 instances deprecating property class 131 of component template local properties 292 of property classes 120, 129 removing property class 131 internal changes removing 468 tracking 468 intrinsic properties 208, 1056 complete list 1087 IS_DEPLOYABLE server property 564
I
IBM Frame browsing 611 managing 610, 612 icons defining 639 Import Contents panel for Import wizard 106 Import wizard Import Contents panel 106 Map Existing System Package Types panel 112 Map Missing BLPackages panel 112 Map Missing Compliance Jobs panel 114 Map Missing Component Discovery Jobs panel 114 Map Missing Component Templates panel 113 Map Missing Deploy Jobs panel 115 Map Missing Depot Files panel 113 Map Missing Network Shell Scripts panel 115 Map Missing Properties panel 109 Map Missing Servers and Server Groups panel 108 Property Values Mapping panel 111 Select Destination Group panel 106, 107 Select Import Source Directory panel 106 imported devices adding 1007 importing a list of devices 1011 overview 1006 viewing 1019 imported servers deleting 1023 importing 101, 109, 111 contents 106 destination grammars 106 destination group 107 file format for servers 225 import source directory 106 MAC address file 1017 MAC address list 1011 MAC address list and configuration values 1012 Map Missing BLPackages 112
J
Job Options panel for Deploy Jobs 543 job parts canceling 445 time-outs for 444, 445 job schedule log for change management approval jobs 425
Index
1149
job schedules viewing 443 jobs 413 and properties 416, 421 avoiding hung 443 canceling 428 executing 418, 683, 684 executing a job with change management approval 422 executing against failed targets 419 executing against specific targets 418 executing as specific role and user 421 exporting 101, 102 exporting logs 442 for managing custom configuration objects 641 for managing custom server objects 641 importing 101, 104 in progress 67, 427, 428 managing 413, 417 opening 417 setting approval type 424 time-outs for 444, 445 updating server status before running 446 viewing activity 438 viewing definitions 417, 441 viewing history 438 viewing logs 441 viewing schedules 443 Jobs folder 34, 86 adding folders 90, 91, 416 adding smart groups 416 copying, cutting, and pasting 416 deleting 416 Folder view 86 managing jobs 413 organizing jobs 416 smart job groups 92 JumpStart provisioning 851, 856 Jumpstart rules file customizing 980 customizing 79 Kickstart entries VMware system package 967 kickstart entries Linux system package 955 VMware system package 967
L
Label Decorations general preference setting 76 limiting objects displayed in smart groups 95 limiting objects using a text filter 66 Linked Mode 78 general preference setting 78 Linux system package 948 AutoYaST entries 956 basic configuration 951 computer settings 952 disk partition settings 949 kickstart entries 955 local properties 959 network settings 954 OS components 953 OS components for Red Hat Linux 953 OS components for SUSE Linux 954 post-install configuration settings 958 Live Browse Results Option 76 Live node contents for virtual environments 593 local boot 1045 local configuration objects adding to component templates 293 local data store 1044 local groups viewing properties 234 local properties adding to BLPackages 396 adding to component templates 291, 292 AIX system package 994 creating in system package 1014 HP-UX system package 1004 Linux system package 959 Solaris system package 986 VMware system package 971 Windows system package 948 local users viewing properties 234 localization settings AIX system package 989 login 40 logs exporting for jobs 442 viewing for jobs 441 loops defining for compliance rule 282
K
Kerberos defined 1129 kernel parameters x86 985 key bindings customizing 79 keyboard combinations customizing 79 keyboard shortcuts viewing 79 Keys general preference setting 79 keystroke combinations
1150
in compliance rules 275, 276, 282 minimum disk space for deploying files 512 mistakes when defining permissions 191 moving a Tab Group 63 moving and docking a view 63 MSI packages adding to Depot 353 deploying 525 multiple objects paging 67
M
MAC addresses creating file of 1015 importing file of 1017 importing list of 1011 macros %f 406 %h 406 maintenance window 429, 564 creating 168 specifying the time window 168 managing virtual environments 591 managing with the BMC BladeLogic console 73 Map 109 Map Existing System Package Types panel for Import wizard 112 Map Missing BLPackages panel for Import wizard 112 Map Missing Compliance Jobs panel for Import wizard 114 Map Missing Component Discovery Jobs panel for Import wizard 114 Map Missing Component Templates panel for Import wizard 113 Map Missing Deploy Jobs panel for Import wizard 115 Map Missing Depot Files panel for Import wizard 113 Map Missing Network Shell Scripts panel for Import wizard 115 Map Missing Properties panel for Import wizard 109 Map Missing Servers and Server Groups panel for Import wizard 108 master 475 for Audit Jobs 478, 479, 492 Master Snapshot panel for Create BLPackage wizard 379 Masters panel for Audit Jobs 478 matching patterns 629 maximize a view or tab group 64 menus quick tour 58 Microsoft Hyper-V browsing 613 managing 613, 614 middle tier of BladeLogic 30 of BMC BladeLogic 31 minimize a view or tab group views minimizing 64
N
navigating perspectives 62 navigating views 62 network configuration Linux system package 954 Solaris system package 976 VMware system package 966 when provisioning servers 1029 Windows system package 942 network definition AIX system package 991 HP-UX system package 1000 Network Routing Wizard 669 Network Shell 29 creating scripts 567 modifying scripts 576 Network Shell Script Jobs 567 Default Notifications panel 571 email notification options 574 General panel 568 Parameters panel 570 permissions 576 Permissions panel 576 properties 576 Properties panel 576 schedule options 573 Schedules panel 572 SNMP notification options 574 Targets panel 569 Network Shell scripts adding to Depot 404 modifying 408 New Component wizard 303 Compliance Exceptions panel 305 General panel 304, 310 Permissions panel 304 Properties panel 304 nexec commands adding 157 deleting 158 modifying 157 NIM provisioning 858 no access nodes 152
Index
1151
notifications for BLPackage Jobs 535 for Compliance Job results 324 for Compliance Jobs 324 for Component Discovery Jobs 298 for Software Deploy Jobs 535 nouser option 192 Package Options panel 503 Package Type panel 503 Package Options panel for bundling snapshot results 470 for Create BLPackage wizard 381 for Package Delta wizard 503 for Sync wizard 501 Package panel for BLPackage Deploy Jobs 530 package specifications Solaris system package 978 Package Type panel for Create BLPackage wizard 376, 470 of Package Delta wizard 503 packages 349 adding BLPackages 375 adding software 353 adding to Depot 353 creating 349 deploying 521 in content format files 1108 modifying software 372 overview 350 Paging Options 76 paging through multiple objects 67 Parameter panel for Add NSH Script to Depot wizard 406 parameters 208 adding to BLPackages 385 inserting 142 using for extended objects 638 using in provisioning 1056, 1059 using to reference scripts 1063 Parameters panel for Network Shell Script Jobs 570 parts component template 252, 253, 262 modifying component template 255, 262 specifying for compliance 272 passwords changing 47 defining 179 providing for BLPackages 398 patch management creating patch catalog 707, 743, 778, 806, 834 creating patching jobs 715, 750, 785, 813, 841 defining catalog 800, 828 defining offline catalog 701, 736, 742, 769 defining online catalog 697, 732, 764 deploying patches 723, 758, 792, 820, 848 for Microsoft Office 723 global configuration parameters 693, 727, 761, 797, 825 grouping catalog contents 712, 747, 783, 811, 839 maintaining catalogs 712, 748, 783, 812, 840 Oracle Enterprise Linux 823 permission for patch catalogs 692 permissions for patch catalogs 726, 760, 796, 824
O
object view of audit results 493 object-based permissions 146, 186 objects assigning permissions 151 creating new 88 custom 636 exporting 102 extended 636 importing and exporting 101 limiting 95 refreshing 84 searching for 90 user-defined 636 opening a new view 63 opening a perspective 62 operating systems supported by provisioning 852 operations running in background 67 operators in content format files 1107 options list for Audit Jobs 482 for component templates 257 for Snapshot Jobs 457 Options panel for File Deploy Jobs 509 Oracle Enterprise Linux patching 823 organizing folder content 89 OS components Linux system package 953 Linux system package for Red Hat Linux 953 Linux system package for SUSE Linux 954 Windows system package 940 overview of access control 145 of BMC BladeLogic 29, 33 of this guide 24
P
Package Contents panel for Create BLPackage wizard 377 Package Delta wizard 502
1152
Red Hat Enterprise Linux 759 remediating servers 720, 755, 790, 817, 846 reporting 724, 758, 793, 821, 849 Solaris 725 SUSE Linux Enterprise 795 viewing catalog 711, 747, 782, 811, 839 viewing patching job results 717, 787, 815, 843 viewing published patches 696, 731, 763, 799, 827 viewing remediation results 722, 757, 792, 820, 848 Windows 691 patches adding to Depot 365, 366, 372 creating patch catalog 707, 743, 778, 806, 834 creating patching jobs 715, 750, 785, 813, 841 defining catalog 800, 828 defining offline catalog 701, 736, 742, 769 defining online catalog 697, 732, 764 deploying 723, 758, 792, 820, 848 for Microsoft Office 723 global configuration parameters 693, 727, 761, 797, 825 grouping catalog contents 712, 747, 783, 811, 839 maintaining catalogs 712, 748, 783, 812, 840 Oracle Enterprise Linux 823 permissions for patch catalogs 692, 726, 760, 796, 824 Red Hat Enterprise Linux 759 remediating servers 720, 755, 790, 817, 846 reporting for 724, 758, 793, 821, 849 Solaris 725 SUSE Linux Enterprise 795 viewing catalog 711, 747, 782, 811, 839 viewing patching job results 717, 787, 815, 843 viewing published 696, 731, 763, 799, 827 viewing remediation results 722, 757, 792, 820, 848 Windows 691 patching jobs creating 715, 750, 785, 813, 841 viewing results 717, 787, 815, 843 paths rules for entering 47 Perl scripts 405 permissions 99 assigned when cutting and pasting 96 assigning to automation principals 171 assigning to multiple objects 151, 190 assigning to objects 99, 151, 186, 191 assigning to property classes 138 assigning to roles 178 avoiding mistakes 191 default 96 delegating authority 186 enforcing 151 for ACL policies 167 for ACL Push Jobs 203 for ACL templates 164 for authorization profiles 160 for Compliance Jobs 330 for Component Discovery Jobs 302 for component templates 260 for files 411 for jobs 219, 576, 648, 655, 663 for manual components 304 for system objects 152 granting access to users 183 managing 147 modifying 99 object-based 146, 186 pushing to servers 194, 195 resource-based 147 role-based 146 understanding 145 updating for groups 151 updating for objects 151 viewing 99 Permissions panel for ACL Policy wizard 167 for ACL Push Jobs 203 for Add Depot Software wizard 365, 372 for Add File to Depot wizard 411 for Add NSH Script to Depot wizard 408 for Audit Jobs 491 for Batch Jobs 584 for Compliance Jobs 330 for Component Discovery Jobs 302 for Create BLPackage wizard 382 for Deploy Jobs 555 for Deregister Configuration Object Jobs 663 for Distribute Configuration Objects Jobs 648 for Execution Tasks 432 for File Deploy Jobs 519 for Network Shell Script Jobs 576 for New Component wizard 304 for Snapshot Jobs 465 for Update Server Properties Jobs 219 for Upgrade Model Objects Jobs 655 Permissions view 98, 99 Perspectives 58 perspectives 55, 60 All 61 changing 59 Classic 61 Classic2 61 customizing 63 detaching a view 64 Explorer 61 Help Desk 61 navigating 62 opening 62 preconfigured 61 reattaching a view 64 resetting defaults 62 saving a customized 63 working with 62 Phase Options panel for Deploy Jobs 551
Index
1153
phases for deploying packages 538, 561 Phases and Schedules panel for Deploy Jobs 536 PKI defined 1132 platforms supported by provisioning 852 Policy Access Control List panel for ACL Policy wizard 166 post-disk partition Windows system package 931 post-install configuration AIX system package 992 HP-UX system package 1003 Linux system package 958 Solaris system package 982 VMware system package 969 when provisioning servers 1030 Windows system package 946 Pre Install script VMware system package 961 pre/post commands for Deploy Jobs 553 for File Deploy Jobs 513 preconfigured 61 preferences Accessibility 78 Annotations 78 BMC Display Options 75 BMC File Deploy Options 75 BMC Live Browse Results Option 76 BMC Paging Options 76 Colors and Fonts 76 Compare/Patch 77 Content Types 77 customizing 73 Editors 78 File Associations 78 general appearance settings 76 global settings 76 Hyperlinking 78 Keys 79 Label Decorations 76 Linked Mode 78 Quick Diff 78 Spelling 78 Text Editors 78 Pre-install scripts Windows system package 928 preview Solaris system package 986 private keys defined 1132 process for using components 245, 248 product support 3 profile entries Solaris system package 979 profiles creating authorization 148 properties 98, 117, 208, 212, 1056 adding or modifying 125 and jobs 416 and parameters 142 assigning when provisioning servers 1027 changing for one or more objects 141 creating instances of property classes 129 defining for automation principals 171 defining for roles 178 defining for users 183 dependencies 126 deprecating 131 for ACL Push Jobs 202 for Compliance Jobs 329 for Component Discovery Jobs 302 for component templates 259 for files 410 for jobs 464, 576 for manual components 304 for Network Shell scripts 408 importing 109, 111 intrinsic 208, 1056, 1087 local 291, 396 modifying 140 overview 117 property class 126 referencing scripts 1063 removing 131 server 210, 211, 212 setting values 140 using in provisioning 1056 using to access data store 1027 using to rename servers 212 viewing 98, 140 Properties panel for ACL Push Jobs 202 for Add Depot Software wizard 364, 372 for Add File to Depot wizard 410 for Add NSH Script to Depot wizard 408 for Audit Jobs 490 for Batch Jobs 584 for Compliance Jobs 329 for Component Discovery Jobs 302 for Create BLPackage wizard 382 for Deploy Jobs 554, 555 for Deregister Configuration Object Jobs 662 for Distribute Configuration Objects Jobs 648 for Execution Tasks 432 for File Deploy Jobs 518 for Network Shell Script Jobs 576 for New Component wizard 304 for Snapshot Jobs 464 for Update Server Properties Jobs 219
1154
for Upgrade Model Objects Jobs 654 Properties view 98 property class properties 126 property classes adding custom 123, 132, 133, 134 built-in 118 creating instances of 129 custom 118, 120 defining permissions for 138 example 120 importing and exporting 132, 133, 134 in content format files 1109 removing custom 131 synchronizing 138 Property Dictionary adding custom property classes 123 adding properties 125 deprecating custom classes 131 deprecating instances 131 deprecating properties 131 importing and exporting 132, 133, 134 modifying properties 125 removing custom classes 131 removing instances 131 removing properties 131 using 118 using custom property classes 120 Property Values Mapping panel for Import wizard 111 PropertySync importing and exporting properties 132 provisioned servers classifying 1023 deleting 1023 viewing 1020 provisioning device properties for 1057 properties for 1056 provisioning history viewing 1022 viewing system package history 1023 provisioning servers 867, 1024 assigning properties 1027 basic configuration 1028 basics 851 begin script 1030 classifying servers as provisioned 1023 configuration for 902, 907, 913, 915, 916, 919 configuring data store for 903 creating custom system package type 907 creating system packages 925 data store instances 1064 integration with server management 862 monitoring provisioning status 1019 network configuration 1029 organizing system packages 1005 overview 862 post-install configuration 1030 preparing jobs for 924 re-provisioning servers 1042 server ACL 1032 server properties 1032 starting and stopping provisioning jobs 1031 strategies for 1064 supported operating systems 852 system package properties for 1057 system package selection 1027 understanding process 852 using parameterized properties in wizard 1058 viewing history of 1022 viewing provisioning history 1022 viewing system package history 1023 provisioning strategies using data store instances 1064 provisioning with BMC BladeLogic 72 provisioning wizard using 1024 public key cryptography defined 1132 public key infrastructure defined 1132 public keys defined 1132 PXE protocol 851 PXE server configuring 915 information about 666 starting and stopping 917
Q
Quick Access 57 Quick Diff general preference setting 78 quick tour changing perspectives 59 content editor 57 menus 58 tool bars 58 views 58 quick tour of console 57
R
RAID controller drivers unattended entries for 943 RBAC 32, 151 audit trails 152 authorizations 145, 146, 147, 1067 automation principals 169, 171 built-in roles 153 built-in users 153, 156
Index
1155
creating ACL templates 161 creating authorization profiles 159, 165 creating roles 173 creating users 179 Manager folder 35, 87, 147 managing 145 modifying ACL templates 164 modifying authorization profiles 160, 167 modifying roles 179 modifying users 183 overview 145 pushing agent ACLs 192 setting up authorizations 156 synchronizing users with Active Directory 184, 185 RBAC Manager folder 87 RBACAdmin user 153, 156 adding 204 RBACAdmins role 153 reattaching a view to the perspective 64 reboot script Solaris 983 reboots for servers 563 setting in BLPackages 389 Red Hat adding RPMs to Depot 353 provisioning 948 Red Hat Enterprise Linux patching 759 refreshing the data 84 registry editing multi-value 396 viewing properties 234 viewing security 235 remediation creating packages for 342 of Compliance Job results 316, 318, 340, 342 of patch configurations 720, 722, 755, 757, 790, 792, 817, 820, 846, 848 remediation jobs setting values for 318 undoing 339 Remediation Options panel for Compliance Rule Editor 289 remediation view of Compliance Job results 338 remote servers 667 rename of servers 212 repeaters deleting 681 for indirect pushes 510, 536 for indirect staging 675 managing 680 routing rules for 677 rule evaluation for 682 server objects for 676 status of 682 viewing 680 re-provisioned servers 1042 resetting perspective defaults 62 resizing a view 64 resources creating 88 restoring a view 64 restoring perspective settings 62 results of Audit Jobs 472, 492, 498 of change tracking 466 of Compliance Jobs 331, 340, 342, 344 of Deploy Jobs 559 of Snapshot Jobs 466, 472 role-based access control 32 roles agent ACLs 175 assigning to users 182 assigning users 178 authorizations for 146, 174 creating 150, 173 general information 174 modifying 179 permissions for 146, 178 pre-packaged 153 properties 178 summary information 178 rollback files 523, 545, 552, 564 routing rules 687 assigning SOCKS proxy servers to 674 creating 669 creating complex rules 685 deleting 689 evaluating job execution rules 684 evaluating repeater rules 682 evaluation of 688 for determining repeater server 677 for job execution 683 re-ordering 689 viewing 688 RPM groups in BLPackages 402 RSCD agents 29 installing during provisioning 946, 958, 969, 982, 992, 1003 Rule Definition panel for Compliance Rule Editor 275 rule groups for component compliance 273 rules creating or editing 276 defining in a content format file 1113, 1118 elements within 275 for component compliance 273, 274, 275, 290 for routing to remote servers 669 operand data types 283
1156
operators 283 rules view of Compliance Job results 332 running operations in background 67 secure remote password defined 1134 security BMC BladeLogic 33 for files 235 security settings editing 393 effective 375 in BLPackages 375, 556 limitations when deploying 556 local 375 viewing 234 Select Destination Grammars panel for Import wizard 106 Select Destination Group panel for Import wizard 107 Select Import Source Directory panel for Import wizard 106 Select Remediation Groups panel for Import wizard 107 Select Server Objects panel for Create BLPackage wizard 377 Selected Configuration Objects panel for Deregister Configuration Object Jobs 658 for Distribute Configuration Objects Jobs 643 Selected Objects panel for Upgrade Model Objects Jobs 650 selecting editors 71 server ACL when provisioning servers 1032 server groups creating from audit results 498 smart 92 server objects 230 adding to component templates 253 copying and pasting files and directories 233 creating for repeaters 676 creating for SOCKS proxy servers 668 deleting files and directories 234 for snapshots and audits 450 included in Audit Jobs 479 included in Snapshot Jobs 454 listing 627 managing 232 modifying in component templates 255, 262 starting and stopping services 234 using jobs to manage custom 641 viewing 234 Server Objects panel for Audit Jobs 479 for Snapshot Jobs 454 server properties when provisioning servers 1032 server tier of BladeLogic 30 of BMC BladeLogic 32 server view
S
saving a customized perspective 63 schedule options for ACL Push Jobs 199, 200 for Audit Jobs 487 for Batch Jobs 586 for Compliance Jobs 326 for Component Discovery Jobs 299, 300 for Deploy Jobs 541 for Deregister Configuration Object Jobs 659 for Distribute Configuration Objects Jobs 645, 652 for Execution Tasks 432 for File Deploy Jobs 516 for Network Shell Script Jobs 572 for Snapshot Jobs 461 for Update Server Properties Jobs 216 schedules viewing for jobs 443 Schedules panel for ACL Push Jobs 199 for Audit Jobs 487 for Batch Jobs 585 for Compliance Jobs 326 for Component Discovery Jobs 299 for Deregister Configuration Object Jobs 659 for Distribute Configuration Objects Jobs 645 for Execution Tasks 431 for File Deploy Jobs 515 for Network Shell Script Jobs 572 for Snapshot Jobs 461 for Update Server Properties Jobs 216 for Upgrade Model Objects Jobs 652 Script Options panel for Add NSH Script to Depot wizard 405 Script panel for Add NSH Script to Depot wizard 409 scripts adding to Depot 404 creating 567 defining parameters 406 exporting 101, 102 importing 101, 104 modifying 408, 576 using properties to reference 1063 viewing 409 SCSI controller drivers unattended entries for 943 Search Folders view 88 searching for objects 90
Index
1157
of audit results 495 of Compliance Job results 333 servers and properties 208 assigning to a server group 226 browsing 229 communicating through SOCKS proxy server 667 configuring for use of repeater servers 675 decommissioning 228 defining properties for VMware servers 211 deleting 1023 executing custom commands on 240 import file format 225 importing 223 limiting access 32 master 475 monitoring provisioning status 1019 mounting with NFS 565 moving and copying between server groups 227 obtaining status before running jobs 446 organizing 220 provisioned 1023 provisioning 1024 provisioning history 1022 rebooting 563 receiving agent ACLs 197 removing from system 228 renaming 212 re-provisioned 1042 system package history 1023 taking snapshots of 452 updating properties 210, 211, 212 Servers folder 33, 88, 207 adding a new virtual machine 601 adding remote servers 671 adding servers 221, 222 assigning servers to server groups 226 browsing servers 229 components 230 copying, cutting, and pasting 220 deleting 220 extended objects 230 Folders view 88 importing servers 223 managing jobs 417 managing server objects 232 organizing servers 220 saving a virtual servers state 599 server objects 230 smart server groups 92 starting and stopping services 234 viewing file properties 234 viewing local groups 234 viewing local user properties 234 viewing registry properties 234 viewing security settings 234 viewing server objects 234 viewing services 234 service packs adding to Depot 365, 366 deploying 525 modifying 372 services starting and stopping 234 viewing properties 234 session credentials deleting 44 viewing 45 session key defined 1134 setting preferences for text editors 71 sharing objects 186 ShellEd editing Network Shell Scripts 70 viewing Network Shell Scripts 70 showing deploy activity 469 signatures creating or editing 265 elements within 264 for components 248, 264, 266 operand data types 283 operators 283 testing 266 simulate options for deploying packages 551 single-user mode 546, 565 setting in BLPackages 388 Skip Linux Pre-Install image 901 smart groups and properties 118, 208 component 92 component template 92 copying, cutting, and pasting 95, 96 defining 92 deleting 96 depot 92 exporting 101, 102 importing 101, 104 job 92 limiting contents 95 limiting objects displayed 95 server 92 Snapshot Jobs 452 Component Templates for Filtering panel 454 component templates list 454 creating 452 Default Notifications panel 459, 584 email notification options 463 General panel 452 includes and excludes 455 modifying 465 options list 457 Permissions panel 465
1158
properties 464 Properties panel 464 schedule options 461 Schedules panel 461 server objects list 454 Server Objects panel 454 SNMP notification options 463 Targets panel 458 snapshot jobs viewing changes using Compare Editor 469 snapshot options for component templates 257 snapshots 449 adding results to Depot 471 and symbolic links 450 auditing 475 bundling results into BLPackages 469 change tracking 466 contents of 451 exporting results 472 location of contents 451 of components 268, 269, 452, 454 storing 451 understanding 450 viewing results 466 Snapshots panel for Create BLPackage wizard 378 SNMP notification options for ACL Push Jobs 201 for Audit Jobs 489 for Batch Jobs 587 for Compliance Jobs 328 for Component Discovery Jobs 301 for Deploy Jobs 542 for Execution Tasks 433 for File Deploy Jobs 517 for Network Shell Script Jobs 574 for Snapshot Jobs 463 for Update Server Properties Jobs 218, 647, 654, 661 SOCKS proxy servers assigning to routing rules 674 creating objects for 668 deleting 674 setting up 667 status of 674 viewing properties of 673 soft links using in BLPackages 387 software adding to Depot 67, 353, 471 changing network deploy options 391 deploying 521, 525, 565 exporting 101, 102 importing 101, 104 matching with depot item 373 modifying packages 372 ordering by dependency in BLPackage 397 overview of packaging 350 uninstalling 557 Software Deploy Jobs creating 525 Default Notifications panel 535 General panel 529 Job Options panel 543 Permissions panel 555 Phase Options panel 551 Phases and Schedules panel 536 Properties panel 554 Software panel 534 Software panel for Create BLPackage wizard 378 for Software Deploy Jobs 534 for uninstall jobs 559 Solaris packages 353 patch clusters 353 patches 353 patching 725 provisioning 971, 1052 rules file customization 980 WAN boot installation of 1052 Solaris system package 971 Add Install Client script 980 additional profile entries 979 additional sysidcfg entries 979 basic configuration 974 begin script 981 computer settings 975 disk partition settings 972 local properties 986 network settings 976 package specifications 978 post-install configuration settings 982 preview 986 reboot script 983 rules file 980 x86 parameters 984 Solaris Zones browsing 609 managing 610 sort order changing 83 specifying parts compliance 272 Spelling general preference settings 78 SQL Server installing 525 SRP defined 1134 staging directory 523 staging options for deploying packages 551 states
Index
1159
of Deploy Jobs 559, 561, 562 status applicable status types for jobs requiring approval 439 of servers 446 support, customer 3 SuSE provisioning 948 SUSE Linux Enterprise patching 795 switching roles 46 symbolic links in BLPackages 375 in snapshots and audits 450 Sync Details panel of Sync wizard 501 Sync wizard 499 Package Options panel 501 Sync Details panel 501 synchronized pushes for files and directories 509 syntax for network data transmission 362 sysidcfg entries Solaris system package 979 system authorizations 156 audit trails 156, 158 system objects assigning permissions 151 copying, cutting, and pasting 95, 96 defining permissions for 99, 186, 190, 191 deleting 96 permissions for 146, 147 setting property values 140 system packages AIX settings 987, 989, 991, 992, 994, 995, 996, 997 creating 925 creating custom system package type 907 defining ESX settings 960 defining Linux settings 948 defining Solaris settings 971 defining Windows settings 927 disk partition 929 exporting 1006 fields that accept property references 1059 HP-UX settings 998, 999, 1000, 1001, 1002, 1003, 1004 importing 112, 1006 inserting parameters 1059 Linux settings 949, 951, 952, 953, 954, 956, 958, 959 organizing 1005 properties 1057 Red Hat 948 selecting when provisioning servers 1027 setting access control on folders 1005 Solaris 983 Solaris settings 972, 974, 975, 976, 978, 979, 980, 981, 982, 984, 986 SuSE 948 VMware settings 961, 962, 964, 966, 967, 969, 971 Windows settings 927, 928, 931, 933, 940, 942, 943, 946, 948
T
tab group 98 moving 63 Properties, Permissions, and Audit Trail 98 tab groups 56 maximizing 64 minimizing 64 tables customizing 81 customizing Child Explorer 81 customizing columns from a pop-up menu 83 customizing custom configuration object 82 customizing fixed-column 81 tailor a perspective 63 Targets panel 535 for ACL Push Jobs 197 for Audit Jobs 484 for BLPackage Deploy Jobs 535 for Component Discovery Jobs 298 for Deregister Configuration Object Jobs 658 for Distribute Configuration Objects Jobs 644 for Execution Tasks 431 for File Deploy Jobs 508 for Network Shell Script Jobs 569 for Snapshot Jobs 458 for Software Deploy Jobs 535 for Update Server Properties Jobs 214 tasks in progress 67 Tasks in Progress view 67, 427 closing 428 hiding 428 technical support 3 templates ACL 161, 164 for components 251, 260 testing compliance 290 compliance rules 287 component discovery 266 Text Editors general preference setting 78 text files adding to Depot 409 viewing and editing 69, 70 text filters 66 TFTP server configuring 916 starting and stopping 918 three-tier architecture 30 time-outs
1160
for Deploy Jobs 555 for jobs 444, 445 job part 444, 445 job-level 444, 445 tool bars quick tour 58 tracking internal and external changes 468 Transactions directory 523, 564, 565 TRANSACTIONS_DIR server property 564 types of preconfigured perspectives 61 general information 180 modifying 183 permissions to access 183 pre-packaged 153, 156 properties 183 RBACAdmin 156, 204 users.local file 192 using filters to limit objects 66
V
validation, of components 308 values for properties 141 viewing dependencies 99 viewing keyboard shortcuts 79 views 56, 58, 60 accessing 63 detaching from perspective 64 maximizing 64 moving and docking 63 navigating 62 opening 63 preconfigured 61 reattaching to the perspective 64 restoring 64 tab group 63 working with 62 virtual environments contents of the Live node 593 IBM Frame 610 managing Solaris Zones 608 Microsoft Hyper-V 613 supported platforms 592 Virtual Guest Job creating 606 Virtual Guest Package creating 604 editing 605 overview 604 Virtual Infrastructure Discovery Job Auto-register discovered ESX Hosts/Virtual Systems 617 creating 616 Discover Unregistered Virtual Systems 617 Import Lifecycle Properties 618, 620 overview 596 viewing results 620 virtual machines adding 601 browsing 593 cloning 384 saving a virtual servers state 599 virtualization sprawl identifying 615 managing 615
U
unattended entries Windows system package 943 undo files 552 for a Deploy Job 562 for a remediation job 339 uninstall jobs 557 Software panel 559 UNIX objects 236 UNIX objects 238 Update Server Properties Jobs 212 Default Notifications panel 215 email notification options 218 General panel 213 permissions 219, 648, 655, 663 Permissions panel 219, 648, 655, 663 Properties panel 219 schedule options 217 Schedules panel 216, 645, 652, 659 SNMP notification options 218, 647, 654, 661 Targets panel 214 Upgrade Model Objects Jobs 649 Default Notifications panel 651 email notification options 654 General panel 650 Permissions panel 655 Properties panel 654 schedule options 652 Selected Objects panel 650 URL syntax for network data transmission 362 user synchronizing with Active Directory 184, 185 user impersonation 149 user mapping 149 user privilege mapping 149 users assigning roles 178, 182 BLAdmin 156, 204 creating 150, 179, 205 creating without RBAC 204 file 192, 194
Index
1161
overview 615 VMware browsing virtual machines 596 creating a Virtual Guest Job 606 discovering virtual machines 596 managing 596, 598 saving a virtual servers state 599 viewing server properties 600 VMware system package basic configuration 964 computer settings 966 disk partition settings 962 Kickstart entries 967 kickstart entries 967 local properties 971 network settings 966 post-install configuration settings 969 Pre Install script 961 Snapshot Job 452 Software Deploy Job 525 Update Server Properties Job 212 working with content editors 68 working with perspectives 62
X
x86 kernel parameters 985 x86 parameters 984 XML content format files 1105 XML instruction file 351 editing 383
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
1162
*107213* *107213* *107213* *107213*

*107213*

BMCBladeLogicUserGuide v800

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BMCBladeLogicUserGuide v800

Uploaded by

Copyright:

Available Formats

BMC BladeLogic Server Automation User Guide

Contacting BMC Software

United States and Canada

Outside United States and Canada

Restricted rights legend

Support by telephone or e-mail

Before contacting BMC

License key and password information

BMC BladeLogic User Guide

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

BMC BladeLogic User Guide

BMC BladeLogic User Guide

BMC BladeLogic User Guide

Appendix A Appendix B Appendix C Appendix D

1067 1087 1099 1105

BMC BladeLogic User Guide

Overview of this guide

BMC BladeLogic User Guide

Overview of this guide

Windows and UNIX paths

BMC BladeLogic User Guide

BMC BladeLogic User Guide

Overview of BMC BladeLogic Server Automation

Overview of BMC BladeLogic Server Automation

BMC BladeLogic console

reports client (web browser)

PXE / TFTP Server

Network Shell Proxy Server

(optional) BMC BladeLogic core database reporting data warehouse

Agent File Server

BMC BladeLogic User Guide

Overview of BMC BladeLogic Server Automation

BMC BladeLogic User Guide

Using BMC BladeLogic A brief overview

Overview of BMC BladeLogic Server Automation

BMC BladeLogic User Guide

Overview of BMC BladeLogic Server Automation

BMC BladeLogic User Guide

Preparing for user logins

Preparing for user logins

Setting up an authentication profile

BMC BladeLogic User Guide

Setting up an authentication profile

3 Click the Authentication Profile tab. 4 Do one of the following:

5 On the Authentication Profile dialog, enter values for the following:

example, you could assign a name such as QAServer1SRP or DevServerADK.

Starting the BMC BladeLogic console

BMC BladeLogic User Guide

Starting the BMC BladeLogic console

1 To open the BMC BladeLogic login dialog, do one of the following:

3 Do one of the following:

If you have a valid cached session credential, skip this step.

Starting the BMC BladeLogic console

A Click Options. The login window expands to show additional options in a

BMC BladeLogic User Guide

Viewing an untrusted certificate

8 Click OK. The BMC BladeLogic console displays. NOTE

Viewing an untrusted certificate

2 Click View Certificate.

Deleting cached session credentials

Deleting cached session credentials

2 Click Delete Cached Credentials.