BBCA - Installation Guide

BMC BladeLogic Client Automation Installation Guide
Supporting
BMC BladeLogic Client Automation 8.2.02
January 2013
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 20052012 BMC Software, 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. AIX is the trademark or registered trademark of International Business Machines Corporation in the United States, other countries, or both. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office, and is used here by BMC Software, Inc., under license from and with the permission of OGC. Linux is the registered trademark of Linus Torvalds. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. UNIX is the registered trademark of The Open Group in the US and other countries. The information included in this documentation is the proprietary and confidential information of BMC Software, Inc., its affiliates, or licensors. Your use of this information is subject to the terms and conditions of the applicable End User License agreement for the product and to the proprietary and restricted rights notices included in the product documentation.
Restricted rights legend

U.S. Government Restricted Rights to Computer Software. 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
s s s s s s s s
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:
s
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
s s s
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
Contents
Part 1 Planning your installation
Chapter 1 BMC BladeLogic Client Automation infrastructure
17
19 19 20 20 20 20 21 21 21 25 25 25 26 33 35 35 36 36 37 37 38 39 43 44 44 45 45
BMC BladeLogic Client Automation components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Console server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Master distribution server (transmitter). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mirrors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Repeaters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How the components fit together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 2 Designing your BMC BladeLogic Client Automation environment
Determining the requirements for the infrastructure setup . . . . . . . . . . . . . . . . . . . . . Identifying business objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding infrastructure components to your architectural diagram . . . . . . . . . . . . Determining the infrastructure platforms and hardware . . . . . . . . . . . . . . . . . . . . . . . Chapter 3 Performance considerations
Deciding whether to use repeaters, mirrors, or proxies . . . . . . . . . . . . . . . . . . . . . . . . . Common capabilities of replication mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . Repeater strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mirror strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proxy strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MESH-enabled tuner strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining if your system can support the logging feature . . . . . . . . . . . . . . . . . . . . Issue 1: Determining the database insertion rate . . . . . . . . . . . . . . . . . . . . . . . . . . . Issue 2: Determining the volume of log entries generated . . . . . . . . . . . . . . . . . . . Issue 3: Controlling the queue size on the transmitter. . . . . . . . . . . . . . . . . . . . . . . Issue 4: Controlling the size of the database table . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 2
Installation
Chapter 4 Installation overview
47
49
About the product architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Contents 5
Installation terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Overview of installation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Chapter 5 Before you install 53
System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Database requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Database types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Database disk space requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Prerequisites for Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Prerequisites for Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Firewall considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Restrictions for remote deployment on Windows XP . . . . . . . . . . . . . . . . . . . . . . . 58 Windows XP Firewall exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Ports for other firewalls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Internet access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 User requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Requirement for installing on Microsoft Windows computers . . . . . . . . . . . . . . . . . . . 62 Configuring DEP to recognize the installation program . . . . . . . . . . . . . . . . . . . . . 62 Installing the root certificate on Windows computers . . . . . . . . . . . . . . . . . . . . . . . 63 Microsoft Software Update Services considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Requirements for UNIX X11 libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 AIX requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 HP-UX requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Linux requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Solaris requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Chapter 6 How to install the basic components 67
Installation worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Downloading the installation files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Installing the basic components on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Installing the master transmitter and tuner on Windows . . . . . . . . . . . . . . . . . . . . 73 Installing the CMS console on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Installing the basic components on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Installing the master transmitter and tuner on Solaris or Linux. . . . . . . . . . . . . . . 76 Installing the CMS console on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Installing the basic components on HP-UX and AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Creating a platform-specific installer to install the master transmitter . . . . . . . . . 79 Creating a profile for the master transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Creating an installer for the master transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Creating an installer deployment for the master transmitter . . . . . . . . . . . . . . . . . 84 Copying channels from the staging transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Installing the BMC BladeLogic Client Automation modules. . . . . . . . . . . . . . . . . . . . . 86 Logging in to the CMS console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Using the Install Products workflow to install modules . . . . . . . . . . . . . . . . . . . . . 87 Using Channel Manager versus Infrastructure Administration to manage channels 91 Using Channel Manager to manage channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Using the Infrastructure Administration runchannel program . . . . . . . . . . . . . . . 92
Part 3
Postinstallation activities
Chapter 7 Setting up Inventory Management
95
97
Inventory Management components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Overview of Inventory Management setup process. . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Installing the Inventory database schema modules and query libraries . . . . . . . . . . 100 Installation options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Available schema modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Installation order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Database roles and users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Using the Easy install option to install the Inventory database schema modules and query libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Using the Custom install option to install the database schema modules and query libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Verifying the availability of the Query Library queries . . . . . . . . . . . . . . . . . . . . . . . . 108 Configuring the inventory and logging plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Configuring user and group access to the console . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Chapter 8 Setting up the Infrastructure Status Monitor 113
Overview of the Infrastructure Status Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Installation guidelines for the Infrastructure Status Monitor schema . . . . . . . . . . . . 114 Installing the Infrastructure Status Monitor database schema . . . . . . . . . . . . . . . . . . 114 Chapter 9 Setting up Policy Management 117 118 118 118 118 118 119 119 119 120 120 122 122 126 130 132 134 136 137 137 139
Overview of Policy Management components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directory service schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy Service plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integration with a database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of the Policy Management installation process. . . . . . . . . . . . . . . . . . . . . . Prerequisites for installing Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing the directory service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites for Active Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites for Sun Java System Directory Server. . . . . . . . . . . . . . . . . . . . . . . . Prerequisites for ADAM / AD LDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connecting to the directory service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the directory service schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directory service schema options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up Sun Java System Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Policy Manager and the Policy Service plug-in . . . . . . . . . . . . . . . . . . . Whats next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 10 Setting up Patch Management
Overview of Patch Management components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Contents
Patch Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Patch Source channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Patch Service plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Patch Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Configuring the Patch Repository and installing the Patch Sources . . . . . . . . . . . . . 141 Configuring Patch Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Chapter 11 Setting up Security Compliance modules 149
Overview of the Security Compliance modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 FDCC Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Security Policy Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Configuring the FDCC Reporting module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Specifying the transmitter for the FDCC Reporting channel . . . . . . . . . . . . . . . . 151 Specifying a folder for saving benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Enabling benchmark scanning on the endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Scheduling vulnerability scanning on the endpoints . . . . . . . . . . . . . . . . . . . . . . . 152 Configuring the Security Policy Manager module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Configuring the master transmitter and email notification properties . . . . . . . . 154 Configuring the remediation repository for McAfee remediation content . . . . . 154 Chapter 12 Setting up Deployment Manager and Content Replicator 157
Overview of Deployment Manager components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Deployment Service and Content Replicator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Deployment Manager extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Command-line options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Logging in to Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Configuring Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Setting the root directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Chapter 13 Creating profiles, installers, and running deployments 163
Overview of the setup and deployment components . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Installers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Installer Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Creating profiles for various components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Creating a profile for desktop endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Creating a profile from the Profiles tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Loading a profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Creating a profile for a mirror or repeater transmitter. . . . . . . . . . . . . . . . . . . . . . 170 Creating a profile for a proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Creating a profile for a Deployment Manager endpoint . . . . . . . . . . . . . . . . . . . . 175 Creating installers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Installer location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Platform-specific installer templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 CAR files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Platform dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Creating installer deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disabling UAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installer installation path on targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installer deployment timeout period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running and monitoring installer deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Credentials for starting a deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring a running deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stopping a deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining if you have a successful deployment . . . . . . . . . . . . . . . . . . . . . . . . Troubleshooting failed deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Failed deployment details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ports used by remote deployer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limitation of remote deployment on Microsoft Windows Server 2008 . . . . . . . Remote deployment on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stub installer failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding mrbapsexec errors for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . Uninstalling tuners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
182 182 182 182 185 185 186 186 187 188 188 190 190 190 191 191 192
Part 4
Upgrade
Chapter 14 Integrating tuner installation with OS provisioning
195
197 198 198 198 199 199 200 200 200 200 201 201 201 202 203 205 206 206 207 207 208 208 209
Overview of the tuner integration with OS provisioning . . . . . . . . . . . . . . . . . . . . . . Tuner installers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OS provisioning tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy group model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Custom keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Script inserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifying the OS provisioning method to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Image-based method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scripted installation method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview steps for provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites for provisioning machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installed and configured the BMC BladeLogic Client Automation system . . . . Created profiles and installers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating the script insert for provisioning machines. . . . . . . . . . . . . . . . . . . . . . . . Using the script insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HP Ignite-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IBM Network Install Manager (NIM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Red Hat Linux Kickstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solaris Jumpstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unattended Windows 2000/XP/2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrating with Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reboot behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 15
Verifying that BMC BladeLogic Client Automation is set up correctly 211
Using Report Center to run a report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Using Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Contents
Whats next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Chapter 16 Preparing for the upgrade 215
Supported upgrade paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Overview of the upgrade process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Creating a test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Verifying that you can log in as a primary administrator . . . . . . . . . . . . . . . . . . . . . . 218 Backing up workspaces and databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Preparing for the transmitter upgrades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Preparing for database schema upgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Disk space requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Preparing for the Report Center upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Preparing for the Patch Management upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Verifying disk space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Saving patch edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Printing repository and Patch Service configuration settings . . . . . . . . . . . . . . . . 227 Changing the update schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Archiving the channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Upgrading channels from an earlier release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Whats next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Chapter 17 Upgrading transmitters and proxies 233
Upgrade order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Upgrading the master transmitter and its tuner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Upgrading mirror transmitters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Upgrading a few mirrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Upgrading many mirrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Upgrading repeater transmitters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Upgrading a few repeaters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Upgrading many repeaters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Upgrading proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Upgrading a few proxies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Upgrading many proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Whats next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Chapter 18 Upgrading the CMS console 251
Upgrading the tuner on the console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Upgrading the CMS console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Upgrading Infrastructure Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Upgrading Schema Manager module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Upgrading the directory services schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Updating the Inventory database schema modules, query libraries, and custom objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Using the Easy update option to update the Inventory database schema modules and query libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
10
Using the Custom update option to update the Inventory database schema modules and query libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding custom objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Updating the Infrastructure Status Monitor schema . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Easy update option to update the Infrastructure Status Monitor database schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Custom update option to update the Infrastructure Status Monitor database schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Whats next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 19 Upgrading Report Center
262 264 264 264 265 266 267
Overview of upgrading Report Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Updating Report Center and the Inventory and Logging plug-ins . . . . . . . . . . . . . . 268 Chapter 20 Upgrading Policy Management 273
Overview of upgrading Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Updating Policy Manager and the Policy Service plug-in . . . . . . . . . . . . . . . . . . . . . . 274 Chapter 21 Installing or upgrading Patch Management 277 278 278 279 280 281 284 285 286 286 289 291 293 294 296 299 300 301 302 302 303 305
Overview of installing or upgrading Patch Management . . . . . . . . . . . . . . . . . . . . . . If you are installing Patch Management for the first time. . . . . . . . . . . . . . . . . . . If you are upgrading Patch Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before you install or update Patch Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites for the Red Hat Enterprise Linux Patch Source channel . . . . . . . . Recommendations for machine roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patch repository update times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing Patch Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the Patch Management channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the patch repository and installing the Patch Sources . . . . . . . . . . Configuring the Patch Service plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying the Patch Service channel to endpoints . . . . . . . . . . . . . . . . . . . . . . . . Upgrading Patch Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading the Patch Source channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rebuilding the patch repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading Patch Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Updating the endpoints to Patch Service 8.2.02 . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying that the upgrade is in place . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying the success of the upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Whats next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 22 Upgrading Deployment Manager
Compatibility with Application Packager and Content Replicator . . . . . . . . . . . . . . 305 Upgrading Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 Chapter 23 Updating endpoints 311
Disk space requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Contents
11
Enabling MESH in tuners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Automatically upgrading the endpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Manually upgrading endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Troubleshooting endpoint updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 When to use debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Before you turn on debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Turning on debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Using the debugging log messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Turning off debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Part 5
Appendices
Appendix A Database tuning
321
323
SQL Server database tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Oracle database tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Setting recommended configuration parameter values . . . . . . . . . . . . . . . . . . . . . 324 Selecting an Oracle licensing model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Appendix B Using a ghost image to deploy product modules 329
Preparing a machine to create a ghost image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Using the Software Usage component and ghosting . . . . . . . . . . . . . . . . . . . . . . . . . . 332 Appendix C Manual database schema installation and updates 333
Manually installing or reinstalling the database schema . . . . . . . . . . . . . . . . . . . . . . . 333 Schema patch level upgrade support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Downloading the database schema scripts to install the schema modules. . . . . 334 Configuring Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 Configuring Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Using scripts to update the Inventory database schema . . . . . . . . . . . . . . . . . . . . . . . 341 Update considerations for installation scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 Changes that are supported from the command line . . . . . . . . . . . . . . . . . . . . . . . 342 Updating the Inventory database schema using a single script . . . . . . . . . . . . . . 342 Updating the Inventory database schema using multiple scripts . . . . . . . . . . . . 346 Using a script to update the Infrastructure Status Monitor database schema . . . . . 353 Monitoring the progress of a schema update on Oracle. . . . . . . . . . . . . . . . . . . . . . . . 354 Reporting database using SQL Server replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Replication configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 Appendix D Migrating to more recent versions of the database type 363
Migrating from Microsoft SQL Server 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Migrating from Oracle 9i to Oracle 10g. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Index 369
12
Figures
Recommended system architecture for standard environments . . . . . . . . . . . . . . . . . 22 Network diagram example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Round robin redirection strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Basic strategy for using proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Basic strategy for MESH-enabled tuners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Reverse proxy outside a firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Mirror at one of your customer sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Install Products workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 sp_change_users_login script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 prepare_for_import.sql script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 gather_status.sql script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Figures
13
14
Tables
Hardware and software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Advantages and disadvantages to using repeaters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Advantages and disadvantages to using mirrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Advantages and disadvantages to using proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Advantages and disadvantages to using MESH-enabled tuners . . . . . . . . . . . . . . . . . 39 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Ports on computers that host BMC BladeLogic Client Automation servers . . . . . . . 61 Installation prompts for master transmitter and console on Windows . . . . . . . . . . . 68 Recommended Custom Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Inventory Management components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Steps to install and set up Inventory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Database roles and users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Inventory database connection attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Inventory database data and index files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Other directory service schema options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Profile types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 mrbapsexec error codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Disk space requirements for database upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Database file names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Database file space requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Disk space requirements for specific file names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Preparation checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Upgrade checklist for the master transmitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Upgrade checklist for mirrors using Tuner Administrator and Transmitter Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Upgrade checklist for repeaters using Tuner Administrator and Transmitter Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Upgrade checklist for proxies using Tuner Administrator and Proxy Administrator . 248 Checklist for a CMS console update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Inventory schema module update options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Upgrade checklist for Report Center and Inventory and Logging plug-ins . . . . . . 268 Upgrade checklist for Policy Manager and Policy Service plug-in . . . . . . . . . . . . . . 274 Summary of Patch Management installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Summary of Patch Management upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 Recommendations for machine roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Channel installation checklist for Patch Management . . . . . . . . . . . . . . . . . . . . . . . . 286 Upgrade checklist for Patch Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Upgrade checklist for Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 Upgrade checklist for endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Tables 15
Debug levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Recommended configuration values for Oracle parameters . . . . . . . . . . . . . . . . . . . 324 Recommendations for RAID disks with Oracle database files . . . . . . . . . . . . . . . . . . 326 Database settings required to connect to the Inventory database . . . . . . . . . . . . . . . 343 Database settings required to connect to the Inventory database . . . . . . . . . . . . . . . 346 Schema scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
16
Part
Part 1
Planning your installation

This part presents the following chapters: Chapter 1 BMC BladeLogic Client Automation infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . 19 Chapter 2 Designing your BMC BladeLogic Client Automation environment . . . . . . . . . . . . 25 Chapter 3 Performance considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Part 1 Planning your installation
17
18
Chapter
BMC BladeLogic Client Automation infrastructure

1
This chapter describes the standard topology that BMC recommends for a typical enterprise, and defines the hardware and software components required for most installations. This chapter presents the following topics: BMC BladeLogic Client Automation components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Console server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Master distribution server (transmitter). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mirrors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Repeaters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How the components fit together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 20 20 20 20 21 21 21
BMC BladeLogic Client Automation components

The following definitions help you become familiar with the components of the BMC BladeLogic Client Automation infrastructure.
Chapter 1
19
Console server
Console server
The machine on which you install the CMS console is the console server. Administrators use the CMS console to manage software changes, manage content changes, configure endpoints, and collect inventory information. The browser-based user interface enables you to access the BMC BladeLogic Client Automation infrastructure management tools, including Report Center and Policy Manager. You use the CMS console to configure most components.
Master distribution server (transmitter)

The master distribution server (also known as the master transmitter in a BMC BladeLogic Client Automation infrastructure) functions like a web server, except that instead of serving web pages, it serves applications and content that are packaged into channels. The channel format enables cross-platform support and byte-level updates to software and content. Because the transmitter hosts all the content and applications that you distribute to endpoints, it is the heart of your BMC BladeLogic Client Automation infrastructure.
Mirrors
Mirrors and repeaters are regular transmitters with some simple configuration changes that enable them to function in a new capacity. You can set up mirror transmitters to regularly auto-replicate all the content from the master transmitter (or master/mirror farm). Mirrors provide high availability and scalability.
Repeaters
Repeaters regularly auto-replicate some or all of the content from a master/mirror farm. You can set up a master to redirect client requests to a repeater transmitter. The client redirection enables clients to communicate with the nearest server, and it provides built-in fault tolerance.
20
Proxies
Proxies
Proxies are a good choice in remote locations where endpoints do infrequent updates or do not require a majority of corporate channels (either initially or on an ongoing basis). You can also use a proxy in a remote location where hardware resources are limited. In this situation, you can host the proxy on a desktop-class machine to service up to 50 endpoints.
Endpoints
Endpoints refers to target desktops (and laptops) and servers. You place a BMC BladeLogic Client Automation agent (commonly known as a tuner) on every endpoint. The agent enables targeting, installation, and updates on the endpoints. The tuners multi-endpoint sychronized host (MESH) capabilities enable you to reduce the number of dedicated servers required to maintain your BMC BladeLogic Client Automation infrastructure. When enabled, MESH allows a tuner on an endpoint to function as a transmitter (mirror or repeater) by allowing it to request content and provide that content to other MESH-enabled endpoints. MESH-enabled tuners can also replace proxies except when the proxy is used route network traffic around a firewall. Enabling the MESH functionality in endpoint tuners is a good choice in remote locations or other places where hardware resources are limited. The MESH functionality enables tuners to act as a local mirror or repeater for a group of endpoints. For more information on using and enabling MESH in tuners, see the BMC BladeLogic Client Automation CMS and Tuner Guide.
How the components fit together

The diagram in Figure 1 on page 22 shows the recommended architecture for deploying the BMC BladeLogic Client Automation environment. After you study the diagram and text that follows it, you can proceed to Chapter 2, Designing your BMC BladeLogic Client Automation environment, which helps you determine how to configure your BMC BladeLogic Client Automation environment. If your company requires a different setup, contact BMC Customer Support. BMC can help you to design a setup that is more suitable for your environment.
Chapter 1
21
Figure 1
Recommended system architecture for standard environments

9 8 Console Server Test/QA Transmitter 1 11 7 Master 3 2 10 Directory Service
Corporate Headquarters
(New York)
7 Mirror
Load Balancer 4 6 4 Mirror (off-site)
Lima
Hamburg
San Jose
Chicago
Denver
Atlanta
Proxy 5
Proxy
Repeater 6 5
Repeater
Repeater
Repeater
endpoints
endpoints
endpoints
endpoints
endpoints
endpoints
22
The numbers in this diagram correspond to the step numbers in the following description of the system architecture:
1 After testing and deploying channels (packaged applications and content), copy
the channels from your distribution server (transmitter) in the testing lab to the master production transmitter. You copy channels from the test or QA lab to your production environment on an ongoing basis, usually weekly or monthly, or when new content is available.
2 Use the CMS console to publish the following plug-ins to the master transmitter:
s
The Report Center publishes the Inventory and Logging plug-ins to the master transmitter. The plug-ins contain schedules for inventory scanning and log collection. You can also publish these plug-ins if you need to change a configuration setting, such as the schedule for an inventory scan or log collection from endpoints.
The Policy Manager publishes the Policy Service plug-in to the master transmitter.
3 Channels (and their plug-ins) are then automatically replicated to the mirror
transmitters (according to a schedule). In the diagram, two of the mirrors and the master transmitter are placed behind a load balancer. A third mirror, located at a different site for disaster recovery, can be promoted into use in the event of a master transmitter or data center failure.
NOTE
(Alternative) If you do not want to use a load balancer to provide fault tolerance, you can have only one master that replicates to repeaters and then have a mirror that is not part of the rotation. In this case, the mirror is not used by endpoints unless the master goes down. Then you quickly convert the mirror to a master by using Transmitter Administrator, a fairly simple operation.
4 At scheduled times, channels are replicated to the repeaters at branch offices.

Channels are cached on proxies at remote sites (on an on-demand basis). Plug-ins are replicated to repeaters but not to proxies. In this scenario, the master and mirrors are placed behind a load balancer. The load balancer is identified by a single IP address. When repeaters connect to that IP address for replication, they are automatically routed to the master or one of the mirrors.
Chapter 1
23
NOTE
If you use Deployment Manager, you probably will not use repeaters because you want to control the distribution server that endpoints use for content installation and updates.
5 The endpoints download new channels and update current channels:

s
If the endpoints use Policy Manager, the endpoints get the channels according to their policies. If the endpoints are part of a Deployment Manager system, the endpoints get their channels according to the job schedule set in Deployment Manager.
6 Inventory scan reports and log messages are sent back from the endpoints to the
plug-ins on the repeaters. The repeaters then forward the data to the plug-ins on the master and mirrors.
7 The master and mirror plug-ins insert the data collected from endpoints into the
database.
8 Report Center retrieves specified data from the database. You specify this data in
one or more of the following ways:
s
You create queries for hardware and software inventories, software usage (if you have the Software Usage component), policy compliance, and so on. You can create your own queries or use predefined queries from the Query Library. Your previously created queries are automatically run according to schedules, and the results are e-mailed to the appropriate people. You build queries that return a group of machines, and you save these queries in special predefined folders. Other management tools, such as Deployment Manager, Transmitter Administrator, Tuner Administrator, use these queries so that you can manage multiple machines simultaneously.
9 Report Center runs scheduled queries to create collections in a directory service.

The Policy Management module then targets these collections.
10 To authenticate users, the CMS console retrieves user information from the
directory service.
11 The Policy Service plug-in resolves group membership and retrieves policies from
your directory service.
24
Chapter
Designing your BMC BladeLogic Client Automation environment

2
This chapter helps you determine if the recommended configuration works in your environment. If the plan requires modifications, you might need to contact BMC Customer Support and to arrange for assistance from BMC Professional Services. The following topics are provided: Determining the requirements for the infrastructure setup . . . . . . . . . . . . . . . . . . . . . Identifying business objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding infrastructure components to your architectural diagram . . . . . . . . . . . . Determining the infrastructure platforms and hardware . . . . . . . . . . . . . . . . . . . . . . . 25 25 26 33
Determining the requirements for the infrastructure setup

To get started, you must identify your requirements to determine how to set up the BMC BladeLogic Client Automation infrastructure in your environment. This section helps you make those decisions.
Identifying business objectives

Writing down the basic business requirements for your BMC BladeLogic Client Automation infrastructure helps you determine the hardware and software requirements for your environment. For example, updating 100 GB of web content on 500 servers every day requires more hardware than updating a 100 MB custom application on 2000 desktops once a month.
Chapter 2
25
Adding infrastructure components to your architectural diagram
Your business objectives can include one or more of the following objectives:
s
Maintain accurate asset inventories of all hardware and software. Distribute OS patches to UNIX servers. Deploy and manage applications on remote desktops and laptops. These applications can consist of both custom applications and shrink-wrapped applications, such as Microsoft Office. Streamline the current software distribution process. Reduce support costs.

To create an architectural plan for your BMC BladeLogic Client Automation infrastructure, complete the following steps: 1. Estimate how many of each component you need, as described in Machine count and location requirements. 2. Consider some issues that can affect those original estimates, as described in Estimated service load on page 29 and Security requirements on page 32. 3. Ensure that your existing hardware and software meet the minimum system requirements, as described in Determining the infrastructure platforms and hardware on page 33.
Machine count and location requirements

Determine if the setup shown in Figure 1 works for your enterprise. That diagram shows a master transmitter, mirrors, and repeater distribution servers at regional and branch offices. The required number of distribution servers and proxies depends on the number of endpoints and the number of remote sites in your enterprise.
26
Therefore, create a system diagram similar to the one in Figure 1 that shows the following information:
s s s s s
Corporate headquarters and the various regional and branch sites. Speed of the network connections between the sites. Location of the database and directory service. Sites that replicate the directory service. Number of endpoints located at each site. Network diagram example
Figure 1
Corporate HQ
Branch office A
Database 256 Kbps
Directory services
2000 desktops and laptops
100 server endpoints
T1 line
T1 line 256 kbps
Regional office #1
Regional office #2
Branch office B
Replicated directory services
Replicated directory services
Use the number of remote sites and the number of endpoints at each site to help you determine how many mirrors, repeaters, and proxies you need, as described in the following paragraphs.
Requirements for the master/mirror farm

The process shown in Figure 1 begins with the distribution servers (transmitters). To help you determine how many transmitters you need, use the following formula: Number of endpoints/7500=number of transmitters (with a minimum of 2)
Chapter 2
27
NOTE
You can reduce the need for mirror transmitters by enabling the MESH capability of tuners on endpoints. For more information on the tuner's MESH capabilities, see the BMC BladeLogic Client Automation CMS and Tuner Guide.
NOTE
This formula provides a rough estimate. You must also consider the update frequency and the size of the updates. With infrequent updates and small changes, a master transmitter might be able to handle 50,000 endpoints. If the total number of endpoints is under 5,000 and you do not have or do not want to use a load balancer, you can use one master and then use one mirror as a backup or hot spare transmitter. The mirror provides fault tolerance by maintaining workspace backups of the master and can quickly be promoted to master in the event that the master system failure. However, this strategy requires a manual DNS alias change when you promote the mirror to a master.
Requirements for the console server

Figure 1 shows only one console server, which hosts one Report Center. When users run queries, the reports can contain results from endpoints in one or more domains, depending on how the query is constructed. If your enterprise uses Active Directory and supports a multi-domain forest, and you want to restrict administrators in one domain from seeing queries that the administrators in another domain use, you can install multiple console servers (and Report Centers). The setup described in this guide assumes you have only one console server. If you want to use more than one, contact Customer Support for assistance.
Requirements for a directory service

You can also use access control lists, which allow Report Center to limit the endpoints that display in query results. You can set up access control lists for the groups (for example, countries, companies, divisions, or operating units) established in your directory service. If you plan your directory service implementation (or reimplementation) when you plan your implementation, consider organizing the endpoints in your directory service into the groups you need for access control lists.
Requirements for repeaters

For each remote site, plan to use one or two repeaters. Although a repeater has the same capacity as a master (and can handle 7,500 endpoints), for disaster recovery purposes, you should have a second repeater at a site.
28
Requirements for proxies

Consider using a proxy at remote locations under one of the following conditions:
s
Endpoints do infrequent updates or do not require a majority of corporate channels (either initially or on an ongoing basis). Hardware resources are limited. In this situation, you can host the proxy on a desktop-class machine to service up to 50 endpoints, and you can perhaps also use the machine to run additional applications and services.
NOTE
In this case, consider enabling the MESH feature in the affected tuners rather than using a proxy. For more information on the tuner's MESH capabilities, see the BMC Configuration Automation CMS and Tuner Guide.
The site has a slow link (such as a dial-up modem) to the main corporate data center.
Taking these considerations into account, determine the number of machines required to host proxies. After you work through these questions, read the next section to determine if you need to adjust your plan.
Estimated service load

Consult the topics that follow to estimate the service load.
Load on the Policy Service plug-in and master/mirrors

To determine if your current estimate for master, mirrors, and repeaters is sufficient, answer these questions:
s
How often do updates and new distributions need to be sent to endpointsdaily? weekly? hourly? Is there a time window during which distributions can be made, or can they be made anytime? The answers to these questions affect how often Policy Service runs and contacts the Policy Service plug-in on the distribution servers. If you determine that, for example, the Policy Service plug-in will get 10,000 requests every 90 minutes (90 minutes is the default policy schedule), you might need to change your plan.
Chapter 2
29
In this scenario, if you plan to have all 10,000 endpoints contact the Policy Service plug-in on the master, then there can be a problem. To solve it, you can increase the policy schedule so that endpoints contact the plug-in every 180 or 360 minutes. Or you can have the repeaters replicate the Policy Service plug-in. This way, all 10,000 endpoints do not contact one plug-in.
s
How many queries will be made to the directory service per day? Use the following formula for each instance of the directory service: (Number of times per day Policy Service runs) x (number of endpoints)=queries Desktop and laptop endpoints are most likely to get new software distributions and updates by using a policy. In order for endpoints to get the plan (and their updates and new software), the endpoints need to run the Policy Service at regularly scheduled times. How often this service runs depends on how quickly you want software to be deployed when it is ready. By default, the service runs at 90-minute intervals. If you use this default for 1,000 endpoints, the directory service receives 1,000 requests every 90 minutes. When you use the formula, if the resulting number is greater than 10,000 every 90 minutes, increase the interval to 180 or 360 minutes.
How many megabytes (estimated range) will be sent for each distribution? This question is more important for Deployment Manager systems, which can replicate large files and large numbers of files in a single channel. To see the limits regarding channel size and number of channels a distribution server can host, see the release notes for Deployment Manager, available on the BMC Customer Support website. If your master will host large channels or large numbers of channels, ensure that the machine hosting the master has adequate processing power and space.
Load on the console server and directory service

To determine if your current plans for the console server and directory service are sufficient, answer these questions:
s
How often will collections be scheduled to run? Report Center runs collections according to a schedule and then saves the results in your directory service. (Policy Manager uses the results as target groups when sending policies to endpoints.) Therefore, running collections involves the console server, the directory service, and the database. BMC Software recommends that you run collections no more often than once a day during off-peak hours so that the directory service is not overburdened.
Will repeaters be able to query a locally replicated directory service to limit WAN traffic and provide faster service to endpoints?
30
If not, you might need to configure repeaters so that they do not replicate the Policy Service plug-in. That way, all endpoints contact a plug-in from the master/mirror farm and thereby query only the main directory service.
Load on the Inventory plug-in and master/mirrors

To determine if your current plan for the master/mirror farm is sufficient, answer this question: How often will inventory scans be run? It is recommended that scans be run once a day. Each time an inventory scan is done on an endpoint, a scan report is sent to the Inventory plug-in on the repeater, and then the scan is usually forwarded to the master/mirror farm. If you anticipate having more than 10,000 scan reports sent at the same time (that is, using the same schedule), consider one of the following options:
s
Schedule different components to be scanned according to different schedules. For example, you can set the system/hardware components to be scanned daily, but set the applications to be scanned only once a week. Set repeaters to insert scan reports directly into the database, instead of forwarding them to the master. This option is not recommended if the repeater must go across a WAN to insert data in the database. When a repeater inserts data directly, it uses the databases native network protocol to communicate with the database, which uses more bandwidth than the BMC BladeLogic Client Automation protocol. The BMC BladeLogic Client Automation protocol is used when forwarding data to a master.
NOTE
To improve performance, BMC Software recommends that you place transmitters that insert data in the database on the same subnet as the database server.
Load on the database

To determine if you need to have a database dedicated to your infrastructure, make the following calculations:
s
Use this formula to calculate the required space for initial inventory scans: (Number of endpoints) x (200 KB). Use this formula to calculate the required space for subsequent scans (differential scans): (Number of endpoints) x (40 KB). Use this formula to calculate the total required database storage for inventory scans: (Initial scan space) + (diff scan space). A minimum of 3 GB is recommended.
Chapter 2 Designing your BMC BladeLogic Client Automation environment 31
Also, determine if the database can accommodate centralized logging data. For more information, see Determining if your system can support the logging feature on page 43. Depending on your calculations, you might need to increase the capacity of your database server, or, conversely, you might discover that you do not need to dedicate the database to the BMC BladeLogic Client Automation infrastructure. If the volume of centralized logging data is an issue, you might be able to adjust the level of log collection to avoid overloading your database.
Security requirements
Firewall issues can affect which components you install and where you install them. For example, your environment might require you to place a reverse proxy outside the firewall, instead of allowing endpoints to contact a distribution server directly through the firewall. In general, the following ports must be open:
s
Listener port (default of 5282). This port must be open so that the master/mirror farm can be contacted for new channels and updates. (For Deployment Manager systems) Deployment Manager status port (default of 8000). This port must be open so that endpoints can send status messages back to Deployment Manager. (Rarely) Administration port (default of 7717). This port must be open only if you are trying to manage a component or to publish a channel from outside the firewall.
If having these ports open is a problem for your environment, contact BMC Customer Support to discuss alternatives. For more information about reverse proxies, see Figure 6 on page 42.
Additional suggestions
After you determine the types of components to use, you need to ascertain if your current hardware and software can support these components. For more information about the component requirements, see Determining the infrastructure platforms and hardware on page 33. For more information about masters, mirrors, repeaters, and proxies and which ones to use in which locations, see Deciding whether to use repeaters, mirrors, or proxies on page 35.
32
Determining the infrastructure platforms and hardware

As you worked through Machine count and location requirements on page 26, you created an architectural diagram of your enterprise. At this point, you should add to that diagram the BMC BladeLogic Client Automation components that you want to place at the various company sites. After the diagram is complete, determine if you already have the required hardware or if you need to purchase new hardware or upgrade existing machines. Use Table 1 to determine if your existing machines satisfy the minimum system requirements for the type of component that you want to install. Unless stated otherwise, you can find the minimum requirements for these components in the BMC BladeLogic Client Automation Release Notes document, available on the BMC Customer Support website. Table 1
Component Master/mirror farm Test and QA distribution server Repeaters Proxies Console server Endpoints
Hardware and software requirements (part 1 of 2)

Number of machines Description Make a list of the machines that you want to use for the master and mirrors. Make a list of the machine or machines that you want to use for hosting channels during testing and QA. Make a list of the machines that you want to use for repeaters. If you plan to use proxies, make a list of machines that will host proxies. Does the machine that you want to use for hosting the CMS console satisfy the system requirements? Make a list of the various operating systems on your endpoints. If some of the operating systems are not supported, either upgrade the endpoint to a supported version or determine if some other version of BMC BladeLogic Client Automation products supports that operating system.
Packaging machine for creating software packages.
Packaging machines convert existing applications to BMC BladeLogic Client Automation channels. When you package software, the packaging machine must use the same operating system as the endpoints that receive the software packages.
Chapter 2
33
Table 1
Component
Hardware and software requirements (part 2 of 2)

Number of machines Description The system requirements of this machine depend in part on how much content (data files) you want to convert into BMC BladeLogic Client Automation data channels. This machine is usually just one of your Deployment Manager endpoints, so the system requirements are the same. After you design your environment, you are ready to install the components and deploy distribution agents to your endpoints.
Packaging machine for creating content packages (for Deployment Manager)
Database system requirements
If you have a large number of endpoints, the machine that hosts your database needs to be comparable to the following example:
s s s s
Windows machine with dual-processors A processor speed of 1 GHz (2 GHz if used for policy compliance) 2 GB of RAM Ultra-SCSI 10K RPM Raid level 0 array
Several BMC BladeLogic Client Automation products use the database, and so your disk space requirements depend in part on how many and which products you use. For more information about database sizing, see Database requirements on page 54.
NOTE
If you have more than 3,000 endpoints that you want to manage by using BMC BladeLogic Client Automation, consider working with BMC Professional Services to create an architectural plan, instead of relying solely on this guide. You can contact BMC Customer Support to arrange for a customer environment assessment. Regardless of the number of endpoints, BMC Professional Services validate your design to ensure that it meets the needs of your infrastructure.
34
Chapter
3
35 36 36 37 37 38 39 43 44 44 45 45
Performance considerations
This chapter explores some of the performance questions raised in previous chapters and discusses some alternative choices for architecture. If you have already successfully made an infrastructure architectural diagram, you might be able to skip this chapter. The following topics are provided: Deciding whether to use repeaters, mirrors, or proxies . . . . . . . . . . . . . . . . . . . . . . . . . Common capabilities of replication mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . Repeater strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mirror strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proxy strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MESH-enabled tuner strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining if your system can support the logging feature . . . . . . . . . . . . . . . . . . . . Issue 1: Determining the database insertion rate . . . . . . . . . . . . . . . . . . . . . . . . . . . Issue 2: Determining the volume of log entries generated . . . . . . . . . . . . . . . . . . . Issue 3: Controlling the queue size on the transmitter. . . . . . . . . . . . . . . . . . . . . . . Issue 4: Controlling the size of the database table . . . . . . . . . . . . . . . . . . . . . . . . . .
Deciding whether to use repeaters, mirrors, or proxies

Although earlier chapters provide recommendations about these components, you might have some special circumstances. This section provides several architecture examples for additional situations. This section helps you use replication effectively in your environment, whether to achieve load balancing, to bring channel content geographically closer to your users, or to protect sensitive information behind a firewall. Replication is the transfer of channels from a master to a mirror or repeater. For the purposes of this discussion,
Chapter 3
35
Common capabilities of replication mechanisms
replication can also include the caching of channels on a proxy. Because you choose between replication mechanisms or a combination of them, this section gives an overview of their differences and then gives examples of various architecture solutions.
Common capabilities of replication mechanisms

To appreciate the differences among repeaters, mirrors, and proxies, you must first understand the capabilities they have in common.
s
They can all retrieve content from a master distribution server (transmitter). They can all cache data geographically closer to endpoints so that, for example, no endpoint has to leave the LAN for data. For all three, you always publish updates to one locationthe master. Repeaters and mirrors automatically replicate content from the master. Proxies cache content from the master when an endpoint requests a channel.
Repeater strategy
When an endpoint sends a request to the master, that transmitter does not usually service the request itself but instead sends a list of repeaters back to the endpoint. The endpoint then contacts the first repeater on the redirection list. If that repeater is unavailable, the client contacts the next repeater on the list. Table 1 lists the advantages and disadvantages to this strategy. Table 1
s
Advantages and disadvantages to using repeaters

Disadvantages
Advantages Because a group of repeaters is available, if one or more become unavailable, the endpoint can still get the request serviced by another repeater on the list.
The list of repeaters that the master sends to endpoints contains either a DNS name or an IP address for each repeater. The problem with this strategy is that third-party redirectors that perform DNS round robin can associate one DNS name with any one of several revolving IP addresses. An equally The entire redirection process is completely problematic situation arises with another type of transparent to endpoints. That is, if you add or remove repeaters, you do not need to change any third-party redirector, which can hide a pool of servers under one IP address. settings on the endpoints.
36
Mirror strategy
NOTE
Although repeaters are usually used to replicate channels from a master, you can also publish a channel directly to a repeater. In this case, the channel that you publish to the repeater stays local to that repeater and does not get replicated back to the master or to other repeaters.
Mirror strategy
Mirrors are like regular (master) transmitters, except in the way that they get their content. At preconfigured intervals, a mirror copies all the channels from a master. You can also configure a mirror to replicate the publish and subscribe permissions of the master. Table 2 lists the advantages and disadvantages of this strategy. Table 2 Advantages and disadvantages to using mirrors
Disadvantages
s
Advantages Mirrors can be used by third-party load-balancing products that support such strategies as DNS round robin and by routing products that hide a pool of servers under one IP address. The recommended strategy is to place one or two mirrors and a master behind a load balancer.
When a new mirror is added, existing endpoints cannot use it until they explicitly switch to that transmitter. There is no automatic redirection (unless a third-party redirector is used). A mirror can mirror channels from only one master, whereas repeaters can replicate channels from many masters. Publishing is disabled for mirrors. That is, you cannot use a mirror to simultaneously mirror a master and host other channels that are not on the master. Publishing is not disabled for repeaters.
Proxy strategy
When an endpoint requests a channel, the proxy gets the channel from the master, saves a copy in its cache, and then delivers the channel to the endpoint. The next time an endpoint requests the channel, the proxy sends the copy that is in its cache if the copy is still current. If the copy in the cache is not current, the proxy updates it and then sends the updated copy to the endpoint. Table 3 on page 38 lists the advantages to using proxies.
Chapter 3
37
MESH-enabled tuner strategy
Table 3
s
Advantages and disadvantages to using proxies

Disadvantages
s
Advantages You can use proxies to cache content from an unspecified number of transmitters, whereas repeaters can work only with channels that are specified as repeatable. Mirrors only mirror the channels from one master. Proxies require less administration time than mirrors or repeaters. Normal (forward) proxies can handle all channel update requests from any transmitter. Proxies use bandwidth more efficiently than repeaters and mirrors because proxies only request files from the master when an endpoint requests an update. Therefore, if channels are republished frequently (for example, once a day), but endpoints check for updates only occasionally (for example, once a week), the proxy contacts the master for updates less frequently than a repeater.
Requests for files must first go to the master (to determine if the proxy has the latest version of the files). Proxies do not perform plug-in processing. All plug-in processing must be done by the master, whereas repeaters and mirror transmitters can run plug-ins. Proxies require settings to be explicitly made on the endpoints that use them, whereas repeaters can be added or removed without requiring any changes to be made on endpoints.
MESH-enabled tuner strategy

When all the endpoint tuners on a subnet have the MESH feature enabled, only one endpoint gets the channel from the master (or mirror or repeater) which sends the request first. Then the endpoint allows the other MESH-enabled tuners in the subnet to retrieve the channel from the first endpoint. Table 4 on page 39 lists the advantages and disadvantages of this strategy. For more information on MESH, see the BMC BladeLogic Client Automation CMS and Tuner Guide.
38
Deployment scenarios
Table 4
s
Advantages and disadvantages to using MESH-enabled tuners

Disadvantages
Advantages With MESH, the number of connections for content requests from a server could dramatically decrease, reducing load. Consequently, the number of servers required to service the same number of endpoints could be reduced, which reduces the costs associated with maintaining such servers in an organization. When MESH is enabled on all the tuners in a subnet, it is possible to increase the number of managed endpoints without the need for adding new (mirror or repeater) servers to service those endpoints. For existing users, you only need to update your tuners to version 7.5 or later to get the MESH feature.
The following scenarios show how you can use a combination of proxies, reverse proxies, repeaters, and mirrors to address common infrastructure requirements.
Scenario 1
You have some channels that use CPU-intensive plug-ins, and you want to deploy these channels over an intranet at a single site. You also want to provide automatic redirection if one or more transmitters become unavailable.
Chapter 3
39
Figure 1
Round robin redirection strategy

Master
Repeater (or Mirror + Redirector)
Endpoints (Tuners)
In this situation, you use round robin repeaters or mirrors with third-party redirectors that can perform DNS round robin, as illustrated in Figure 1 on page 40. Proxies are not able to distribute the plug-in load.
Scenario 2
You have a remote office on another continent, and you want to reduce the overseas bandwidth between that office and the central site. The channels are not updated frequently. Figure 2 Basic strategy for using proxies
Master (in London)
One or More Proxies (in Tokyo)
Tokyo Endpoints (Tuners)
40
As illustrated in Figure 2, using proxies means that files are transferred overseas only when they are requested. If you use a mirror instead, files are transferred according to regularly scheduled times, even if no endpoints request an update. Proxies require less management than repeaters and mirrors, and if you add one or more transmitters to the central office in London, no special configuration is needed in Tokyo.
Scenario 3
You have two remote offices that do not have server-class computers to use as a transmitter. Figure 3 Basic strategy for MESH-enabled tuners
Transmitter (home office)
Remote office 1
Remote office 2
MESH-enabled Tuners
As illustrated in Figure 3, using MESH-enabled tuners, the transmitter picks a seed tuner to act as a local transmitter for each site. This removes the need for a local proxy or server-class computer for a mirror or repeater at the remote sites. For more information on MESH, see the BMC BladeLogic Client Automation CMS and Tuner Guide.
Scenario 4
You want to make channels available to endpoints outside your firewall, but you do not want to allow direct, unmonitored access to your internal master, which can contain sensitive information, such as a database of credit card numbers.
Chapter 3
41
Figure 4
Reverse proxy outside a firewall
Master
One or More Reverse Proxies
Endpoints (Tuners)
As illustrated in Figure 4, the reverse proxy acts much like a mirror. You give endpoints the URL of the proxy instead of the master, and the endpoints do not know that the proxy forwards requests to a (possibly secure) master. If necessary for load balancing, you can use multiple reverse proxies with a third-party redirector (for example, to accomplish DNS round robin). You can use an SSL connection between the master and the reverse proxy, between the reverse proxy and the endpoints, or both. You can also preload channels on the reverse proxy so that even the first time a channel is requested, the download is quick.
Scenario 5
You want to put a transmitter in one of your customer sites. You want all downloads, including the first one, to be as quick as possible, and you want the customer endpoints to point to the transmitter at the customer site.
42
Determining if your system can support the logging feature
Figure 5
Mirror at one of your customer sites

Master in London
Tokyo mirror Tokyo Repeater (or Mirror + Redirector) Tokyo Repeater (or Mirror + Redirector)
Tokyo Endpoints (Tuners)
As illustrated in Figure 5, only one mirror uses overseas bandwidth to replicate channels from the master. Additional transmitters provide load balancing by replicating channels from the Tokyo mirror. You can alternatively use proxies instead of, or in addition, to the load-balancing mirrors or repeaters.
NOTE
(Regarding security settings) Subscribe permissions work differently for repeaters than for mirrors. With repeaters, the endpoint sends the subscribe password to the master. No permissions check is then made on the repeaters. With mirrors, subscribe permissions are replicated on each mirror because endpoints contact the mirror directly. You can use SSL connections with both repeaters and mirrors.
Determining if your system can support the logging feature

In a BMC BladeLogic Client Automation environment, log messages generated on endpoints can be regularly collected in a central database. This feature is powerful but must be used correctly so that your database does not fill up too quickly. This section covers the issues involved in configuring log collection on endpoints. If you use the logging feature that is part of the Inventory module, endpoints collect log entries in a file and then send the file to a Logging plug-in on the master transmitter. The Logging plug-in then inserts the log entries into a database. But the database can insert only a limited number of entries per second. If too many log files
Chapter 3 Performance considerations 43
Issue 1: Determining the database insertion rate
are sent to the Logging plug-in simultaneously, then some files are placed in the transmitters disk-based queue until they can be inserted in the database. To keep the system running smoothly, you must keep the queue from growing too large and the database from getting too full.
Issue 1: Determining the database insertion rate

The first step in managing your system is to determine how many entries your database can insert per second. If your database cannot insert entries fast enough, the log files in the queue build up over time. If the number of files in the queue or the amount of disk space that the queue uses grows too large, your transmitter can run out of memory. For example, a Windows machine running Microsoft SQL Server 2005 with dualprocessors, a processor speed of 1 GHz, and 2 GB of RAM with an ultra-SCSI 10K RPM Raid level 0 array can insert 2,200 log entries per second. This insertion rate assumes that no other plug-ins, such as the Inventory plug-in, are inserting records into the database at the same time.
Issue 2: Determining the volume of log entries generated

After you determine your database insertion rate, determine if that insertion rate is sufficient to handle the number of log entries generated by your system. Gather the following information about your endpoints:
s s
the total number of endpoints that will generate logs the number of log entries generated by one endpoint when one Policy Service runs (assuming you use the Policy Management module to install packaged applications) When you configure logging, the log severity level setting has the greatest impact.
WARNING
Either use the MAJOR severity level or, if you use the AUDIT level, set specific ranges of log entries to collect. The AUDIT severity level collects a large volume of log entries and can cause your database to fill up quickly.
number of retries that the Policy Management module performs in the event of a failure to install a packaged application The default is 5 retries.
44
Issue 3: Controlling the queue size on the transmitter
time period between retries This time period determines if the queue can be processed before the next influx of log entries is created when the Policy Management module runs again. The default is 1 minute.
policy schedule By default, Policy Service runs every 90 minutes on the endpoints.
To help you determine these numbers, contact BMC Customer Support. These numbers help you determine if the database can handle the insertion rate and if a queue will accumulate on the transmitter or transmitters in your system.
Issue 3: Controlling the queue size on the transmitter

If you anticipate that a queue will build up, gather the following information to help you determine how to configure the queue size:
s s
the number of transmitters that will insert log entries directly into the database the number of endpoints per transmitter that will insert logs directly into the database (for repeaters that forward log files to a master, count the endpoints for all the repeaters that forward files to the master)
BMC Customer Support can help you determine these numbers. To prevent the transmitter from running out of memory, use a Logging plug-in configuration setting that limits the number of files allowed in the queue; the default is 500,000 files. You can also use a setting to limit the amount of disk space that the queue uses; the default is 100 MB. When each limit is met, no more log files are accepted into the queue. Information about how to use these configuration settings is provided in the BMC BladeLogic Client Automation Report Center Guide, available on the BMC Customer Support website.
Issue 4: Controlling the size of the database table

You also need to monitor how quickly the database grows, in terms of both disk space used and number of records. By default, the database table for the logging feature (the mastlog table) can accommodate up to 10 million records, which can require up to 10 GB of disk space.
Chapter 3
45
Issue 4: Controlling the size of the database table
By default, a delete script runs that creates a regularly scheduled job to delete records from your database on an hourly basis (because the Policy Management module runs every 90 minutes by default). To change the schedule for deleting records, see the BMC BladeLogic Client Automation Report Center Guide, available on the BMC Customer Support website. If you set the log message severity level to AUDIT and collect log entries for all ranges, the speed at which the database uses up disk space can be 100 times faster than if you set the severity level to MAJOR. Therefore, to collect log entries at the AUDIT level, specify limited ranges of log entries.
EXAMPLE
If you set ranges so that only the channel state information is collected, then no matter how many files in a packaged application fail to be installed, you get only a single installation failure. If you set the range to collect all AUDIT-level log entries, then if there are 1,000 files in the packaged application, you get 4,000 log entries (that is, 4 log entries for each object, regardless of whether the object failed to install).
46
Part
Part 2
Installation
This part presents the following chapters: Chapter 4 Installation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Chapter 5 Before you install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Chapter 6 How to install the basic components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Part 2
Installation
47
48
Chapter
Installation overview
This chapter provides a high-level view of the installation and deployment process for a first-time installation of BMC BladeLogic Client Automation basic infrastructure and products. This chapter presents the following topics: About the product architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Installation terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Overview of installation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
About the product architecture

For an overview of the BMC BladeLogic Client Automation architecture, see the BMC BladeLogic Client Automation Product Introduction guide. This guide describes:
s
the components of the BMC BladeLogic Client Automation architecture, such as tuners, transmitters, and Common Management Services (CMS). CMS is also referred to as the CMS console. how the components function and work together
Chapter 4
49
Installation terminology
Installation terminology
This section describes terminology used in the BMC BladeLogic Client Automation installation process.
s
Download. Downloading the installation program from the BMC Electronic
Product Distribution (EPD) website to your machine.

s
Installation.
Running the installation program on your machine to install a master transmitter and the CMS console. Using the CMS console workflow to install BMC BladeLogic Client Automation products that you purchased.
s
Configuration. Performing tasks to create a functional, but minimally configured, BMC BladeLogic Client Automation product, such as Inventory and Report Center, Policy, Patch, or Deployment Manager. Deployment. Creating profiles, installers, and installer deployments to set up
endpoint tuners, additional master, mirror, or repeater transmitters on target machines throughout your enterprise.
Overview of installation process

This section contains an overview of the steps required for a fresh installation of BMC BladeLogic Client Automation. Detailed instructions for each high-level step are provided in subsequent chapters.
1 Perform the required pre-installation tasks as described in Chapter 5, Before you

install.
2 Download the BMC BladeLogic Client Automation installation files from the
Customer Support web site, as described in Downloading the installation files on page 71.
3 Refer to the Release Notes for any known issues for a fresh installation of the
product or individual components.
50
4 Install the master transmitter and CMS console, as described in the following
topics:
s
(Windows) Installing the basic components on Windows on page 73 (Solaris and Linux) Installing the basic components on Linux on page 76 (HP-UX and AIX) Installing the basic components on HP-UX and AIX on page 79
NOTE
Because CMS is not supported on HP-UX and AIX, from your initial host machine (Windows, Solaris, or Linux) you must create a profile, an installer, and remote deployment jobs specific to the HP-UX and AIX platforms to install the master transmitter.
5 Download the BMC BladeLogic Client Automation products to the master

transmitter.
6 Install Inventory Management, which includes the inventory database, Core

database schemas, Report Center, and the Report Center Query Library as described in Chapter 7, Setting up Inventory Management on page 97.
7 Configure your other purchased products (channels) as described in the following

sections:
s s s
Chapter 9, Setting up Policy Management on page 117 Chapter 10, Setting up Patch Management on page 139 Chapter 12, Setting up Deployment Manager and Content Replicator on page 157
Chapter 4
51
52
Chapter
5
53 54 54 54 55 55 57 57 58 60 61 61 62 62 63 63 63 63 64 65 66
Before you install

This chapter presents the following topics: System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Database requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Database types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Database disk space requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites for Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites for Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Firewall considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restrictions for remote deployment on Windows XP . . . . . . . . . . . . . . . . . . . . . . . Windows XP Firewall exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ports for other firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requirement for installing on Microsoft Windows computers. . . . . . . . . . . . . . . . . . . Configuring DEP to recognize the installation program . . . . . . . . . . . . . . . . . . . . . Installing the root certificate on Windows computers. . . . . . . . . . . . . . . . . . . . . . . Microsoft Software Update Services considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . Requirements for UNIX X11 libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AIX requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HP-UX requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Linux requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solaris requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System requirements
The BMC BladeLogic Client Automation Release Notes document lists changes to the supported platforms and the Product Availability and Compatibility website lists the hardware platforms that can host the BMC BladeLogic Client Automation infrastructure. You can access the Product Availability and Compatibility website at http://www.bmc.com/support/product-availability-compatibility. You can access the release notes from the Product Documentation website at http://www.bmc.com/support/product-documentation.
Chapter 5 Before you install 53
Database requirements
For production environments, BMC Software recommends that you install the Master Transmitter and CMS console on separate machines. For test environments, you can install all of the components on a single machine.
Database requirements
This section contains the database requirements for the Inventory database. When the schema is installed and the database is populated, Report Center can run queries and create reports and graphs. For more information about installing the Inventory database, see Chapter 7, Setting up Inventory Management, on page 97.
Database types
For detailed information about the supported versions, see the BMC BladeLogic Client Automation Supported Platforms and System Requirements document under section Database platforms.
Database disk space requirements

Several BMC BladeLogic Client Automation products use the database, and so your disk space requirements depend in part on how many and which products you use. The topics in this section can help you to determine the amount of required disk space for your Inventory database.
Disk space for collecting software usage information

The amount of disk space used depends on the number of endpoints, the average frequency of application launches on each endpoint, and the schedule on which old software usage records are deleted from the database. Each application launch uses 400 bytes. For example, if you have 25,000 endpoints, and each endpoint averages 50 application launches per day, and software usage data is kept in the database for one month, then the required disk space for software usage is: 25,000 endpoints x 50 launches per day x 400 bytes per launch x 30 days = 15 GB of disk space Software usage data is not automatically deleted from the database. Run a job to delete the data on a regular basis.
54
Prerequisites for Oracle
Disk space for Patch Management

If you have Patch Management, the database requires additional space. The default initial size of the data file in the database is 100 MB (but you can change this setting). Similarly, the initial size of the index file is 100 MB. You can also set the maximum size.
Disk space for collecting centralized logging messages

If you use the logging feature, by default a job runs hourly to keep the number of logging records in the database from exceeding 1 million, which uses approximately 500 MB of disk space.
Prerequisites for Oracle

You must have a dedicated database instance for the Inventory database. You must install Oracle database with single byte character set. All BBCA products are validated with the following Oracle NLS settings:
s s s
NLS_CHARACTERSET = WE8MSWIN1252 NLS_LANGUAGE = AMERICAN NLS_NCHAR_CHARACTERSET = AL16UTF16
Before installing Inventory Management and the Inventory database, verify your Oracle database instance is configured with the recommended settings as described in Appendix A, Database tuning. Upon completion of these prerequisites, use Schema Manager to install the database, as described in Installing the Inventory database schema modules and query libraries on page 100.
Prerequisites for Microsoft SQL Server

Before you create the Inventory database, your SQL Server database must adhere to the guidelines in this section. When your SQL Server database meets the prerequisites in this section, use Schema Manager to install the database, as described in Installing the Inventory database schema modules and query libraries on page 100.
Chapter 5
Before you install
55
Prerequisites for Microsoft SQL Server
Summary of Microsoft SQL Server disk space requirements

Each average endpoint inventoried requires approximately 75 KB of disk space if WMI-enabled (50 KB if not), the total of the three tablespaces (inv_data, inv_index, and inv_log). For example, if you have 100 endpoints, you need 7,500 KB of disk space if the endpoints are WMI-enabled (5,000 KB if not).
Memory allocation for SQL Server

No memory-allocation changes are required for SQL Server.
Authentication mode
Use mixed mode rather than the Windows-only authentication mode. If your database is currently running in Windows-only mode, change the mode to SQL Server and Windows.
To change the authentication mode 1 Using Enterprise Manager, right-click the database server name (not the database
invdb).
2 Choose Properties. 3 Click the Security tab. 4 For authentication type, select SQL Server and Windows. 5 Click OK.
Sort Order
Verify the default sort order for SQL Server. This is not necessary when using U.S. locale clients, or clients running Latin character sets. If your system is using double-byte character sets, change the sort order to Dictionary Order, Case-Sensitive.
56
Firewall considerations
To change sort order 1 When installing Microsoft SQL Server, choose the Custom installation option. 2 For sort order, select Dictionary Order, Case-Sensitive.
The default order, Dictionary Order, Case-Insensitive can cause problems on some systems.
Support for SQL Server named instance

Schema Manager supports named instance on SQL Server 2005 and SQL Server 2008. However, SQL Server replication with named instance is not supported.
To configure the named instance 1 Choose CMS System Settings => Datasource => Add Database. 2 In the Host name text box, type the hostname and the instancename, in the
<hostname>/<instancename> format.
3 Complete all the other required fields. 4 Click Check Connection.

The Add Database page displays the success message if the provided details are valid.
5 Click OK.
Firewall considerations
If your site is protected by a firewall, you might need to secure an HTTPS proxy for your installation. If you do not set an HTTPS proxy, the process of copying channels might fail.
Restrictions for remote deployment on Windows XP

On Windows XP (Service Pack 2 and later), you must turn off the firewall during remote deployment of the tuner installer. If you do not turn off the firewall, the remote deployment fails.
Chapter 5
Before you install
57
Windows XP Firewall exceptions

On Windows XP (Service Pack 2 and later), to run the Windows Firewall, you must add the firewall exceptions contained in this section.
Enabling printer and file sharing

Add this exception so that you can use the BMC CM Setup & Deployment system to deploy tuner installers to remote machines. To add this exception, in the Windows Firewall application, on the Exceptions tab, select the Printer and File Sharing check box. Alternatively, if you use Active Directory, you can use a group policy to specify this firewall exception.
Opening the tuner network detection port

This port is on a multicast group so that the tuner can detect network connectivity. This ability is useful when an endpoint does a scheduled inventory scan while the computer is not connected to the network. The tuner can detect when the computer comes back online and then send the scan to the database. To open the port for network detection (port 3344), in the Windows Firewall application, on the Exceptions tab, use the Add Port button. Alternatively, if you use Active Directory, you can use a group policy to specify this firewall exception.
Unblocking java.exe and minituner.exe

The tuner uses a java.exe application and minituner.exe application for communication. Therefore, if you add these applications to the firewalls exception list, you do not need to also add port numbers for BMC BladeLogic Client Automation modules. You can unblock java.exe and minituner.exe in several ways:
s
The user can respond to the Windows Security Alert box that appears when the tuner is installed on the endpoint and attempts to run for the first time. The alert prompts the user to block or unblock java.exe and minituner.exe. If the user unblocks java.exe, then an item for java is added to the Exceptions tab of the Windows Firewall. If the user unblocks minituner.exe, then an item for minituner is added to the Exceptions tab of the Windows Firewall.
58
When using the Setup & Deployment module to create a tuner installer, you can write a post-installation script that uses the netsh tool to add java.exe as an exception. For example: netsh firewall add allowedprogram program="C:\<tuner_install_dir>\lib\jre\bin\java.exe" name=java mode=ENABLE profile=ALL You can write a post-installation script that uses the netsh tool to add minituner.exe as an exception. For example: netsh firewall add allowedprogram program= "C:\<tuner_install_dir>\lib\minituner.exe" name=minituner mode=ENABLE profile=ALL In these examples, C:\Program Files\BMC Software\BBCA\Tuner\ is the default tuner installation path used when creating the installer. If you use this script, the user does not see a Windows Security Alert box. Conversely, if you do not want the Windows Security Alert to appear but you do want to block java.exe and minituner.exe, then you can write a similar post-install script that uses DISABLE in the syntax rather than ENABLE.
If your company manages Windows Firewall settings by using an Active Directory Computer Configuration Group Policy, you can use a group policy to specify firewall settings. You can define program exceptions, supplying the path to the java.exe application and the minituner.exe application. (The path is described in the preceding bullet item.)
NOTE
If you do not want to unblock the java.exe application, and open the ports that java.exe uses, you can open a port for Tuner Administration (default: 7717), and if a proxy is installed on the machine, open the proxy listener port (default: 8080). If you use this alternative, however, the network detection feature does not work. For network detection, open port 3344 and unblock java.exe. (For more information about ports, see Ports for other firewalls on page 60.) To restrict the scope further, you can edit the specific port or program exception. For example, you can use the Windows Firewall application to restrict the scope to only specific machines or subnets that can access the endpoint.
Chapter 5
Before you install
59
Ports for other firewalls
On Windows XP (Service Pack 2 and later), you can view profiles that contain registry entries for firewall settings. You can find the profiles in Table 1 in the following location:
HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy
Table 1
Profile
Profiles
Description applies to computers that are in a domain applies to computers that are not in a domain
DomainProfile StandardProfile
Do not change any registry entries in these profiles unless so advised by BMC Software Support.
Ports for other firewalls

This section describes the ports used by the BMC BladeLogic Client Automation products. If you have a machine that is protected by a firewall, open one or more of these ports, depending on which products are installed on the machine. (If the firewall is a Windows Firewall, which is included with Windows XP, Service Pack 2, you do not need to open the ports listed here. Instead, simply add an exception for the java.exe application that the tuner uses, as described in Windows XP Firewall exceptions on page 58.)
Administration port
Regardless of which BMC BladeLogic Client Automation components are installed on the machine, open the remote Tuner Administration port (default: 7717). This is the port that Tuner Administrator and Deployment Manager use to connect to the tuner.
60
Internet access
Additional port numbers on machines that host BMC BladeLogic Client Automation servers
The only BMC BladeLogic Client Automation server that is supported on Windows XP is the BMC BladeLogic Client Automation proxy server. You can have other BMC BladeLogic Client Automation servers hosted on a machine that has some type of firewall other than the Windows Firewall. Depending on which modules that you install, open one or more of the following ports: Table 2
Port CMS console listener port Deployment Manager listener port Deployment Manager status port
Ports on computers that host BMC BladeLogic Client Automation servers

Default Description 8888 The port number you use when entering the URL to log in to the CMS console and all its web-based applications (such as Report Center and Policy Manager). The machine hosting the console needs this port open. The port number you use when entering the URL to log in to Deployment Manager to create and run deployment jobs. The machine hosting Deployment Manager needs this port open. The port through which endpoints send status messages back to Deployment Manager. Although by default, this port number is the same as that for the listener port, you can change that configuration if you want to use separate ports for the listener and status. The port through which endpoints contact the proxy to request content and application packages. A machine hosting a BMC BladeLogic Client Automation proxy needs this port open. The port through which endpoints contact the transmitter to download content and application packages. If a machine hosting a transmitter is protected by a firewall, open this port. The port through which the Tuner Administrator and Deployment Manager connect to the tuner.
8000
8000
Proxy listener port
8080
Transmitter listener port Tuner Administration port
5282
7717
Internet access
You must run the installation wizard on machines that are connected to the Internet. The wizard downloads products from the BMC web site. If your companys security policy dictates that you install products from physical media, your BMC software sales representative can provide the installation media.
User requirements
When you run the installation wizard, you must log on with administrator rights.
Chapter 5
Before you install
61
Requirement for installing on Microsoft Windows computers
Requirement for installing on Microsoft Windows computers

Some Windows operating systems require that you perform some configuration activities before you run the installation program.
Configuring DEP to recognize the installation program

Before installing or uninstalling the Master Transmitter or CMS console components on a Windows Server 2003 computer, you must configure the Data Execution Program (DEP) feature to recognize the installation or uninstallation program. Otherwise, DEP blocks the successful completion of the program. If the block occurs, the installation program might complete, but the product will fail to start. You must configure DEP on the machines where you will install the Master Transmitter and CMS console components.
To configure DEP to recognize the installation program 1 In the installation directory or on the installation media, locate
BBCA8201_win_x64.exe/BBCA8201_win_x86.exe.
2 From the Windows Desktop, right-click the My Computer icon. 3 Select Properties. 4 Select the Advanced tab. 5 Under the Performance heading, select Settings. 6 Select the Data Execution Prevention tab. 7 Select Turn on DEP for programs and services except those I select and click Add. 8 In the installation directory or media, browse to
BBCA8201_win_x64.exe/BBCA8201_win_x86.exe and click Open.
9 Click Apply, click OK, and then click OK again to close the System Properties
window.
10 Restart the computer.
62
Installing the root certificate on Windows computers
Installing the root certificate on Windows computers

The binary files in the installation program are signed with the Thawte Code Signing Certificate. Before running the installation program, access the Thawte website at http://www.thawte.com/, and download the Thawte Root certificate and Code Signing Certificate Authority (CA) certificates to the target computer. Ensure that you select import the code-signing CA certificate on the Intermediate
Certification Authorities tab.
Microsoft Software Update Services considerations

If you are integrating with Microsoft Software Update Services (SUS), BMC Software recommends that you install the BMC BladeLogic Client Automation applications and the SUS server on two separate machines.
Requirements for UNIX X11 libraries

This section contains information about the UNIX X11 library requirements for the following UNIX platforms:
s s s s
AIX requirements on page 63 HP-UX requirements on page 64 Linux requirements on page 65 Solaris requirements on page 66
AIX requirements
If you will be using Channel Manager, Application Packager, or any other channel that has a user interface, the X11 libraries are required. The X11.motiflib contains the following AIX X11 library: libXm.a
Chapter 5
Before you install
63
HP-UX requirements
The X11.base.lib contains the following required UNIX X11 libraries:

s s s
libX11.a libXt.a libXext.a
The total package size for X11.motiflib and X11.base.lib is approximately 40 MB. The Scanner Service requires that you have the libgcc-4.2.4-1, libstdc++-4.2.4-1, libstdc++-devel-4.2 library installed. Download and install the minimum required maintenance level for 5L as listed in the JDK 1.4.2. Release Notes at http://www.ibm.com/developerworks/java/jdk/aix/service.html . By default, the JIT compiler is turned on in the tuner (regardless of JRE version). You should not change the default setting.
HP-UX requirements
If the required UNIX X11 libraries are missing, the tuner does not start. For HP-UX 11.11, the UNIX X11 libraries you need are included in the HP-UX 11.11 patches mentioned in this section.
HP-UX patches and kernel configuration

Before you install BMC BladeLogic Client Automation products on your system, you must first install all the necessary patches. You can obtain information about which patches to install from the following website: http://docs.hp.com/en/HPUXJAVAPATCHES/index.html Install the patches PHSS_25881 and PHSS_34736, and the pthreads patch PHCO_29960. Also, install all the AWT-related patches, which have crucial fixes for the AWT/X-Motif libraries.
Configure kernel parameters

Some HP servers are shipped with default kernel parameters that are insufficient for running server software such as the BMC BladeLogic Client Automation transmitter. If you encounter out-of-resource errors while running the transmitter, you might need to reconfigure the operating systems kernel.
64
Linux requirements
To help you determine the kernel parameters best suited for the hardware and software configurations of your machines, use the following resource to locate a parameter configuration guide and an HP-UX 11 configuration tool, named HPjconfig: http://docs.hp.com/en/HPUXJAVAPATCHES/index.html Also, HP recommends reconfiguring the following kernel parameters when running large, server-side Java applications: maxdsiz max_thread_proc nkthread maxfiles ncallout For recommended values for these parameters, see: http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNu mber=HPUXJAVAHOME By default, the JIT compiler is turned on in the tuner (regardless of JRE version). You should not change the default setting.
Linux requirements
If you will be using Channel Manager, Application Packager, or any other channel that has a user interface, the X11 libraries are required. If the required UNIX X11 libraries are missing, the tuner does not run. You must have the binutils package, including the strings utility, installed. (This is already installed in most normal Linux installations.) You also must have glibc 2.1 or above installed. The XFree86-libs package contains the following required UNIX X11 libraries:
s s s s s s
libXp.so.6 libXext.so.6 libXt.so.6 libX11.so.6 libSM.so.6 libICE.so.6
The total package size is approximately 21 MB.
Chapter 5
Before you install
65
Solaris requirements
You also must have the libstdc++-libc6.2-2.so.2 library from the compat-libstdc++ package. The following list describes additional requirements for Red Hat Enterprise AS 3.0 and 4.0:
s
You must have the following versions of the compat-libstdc++ package: compatlibstdc++-7.3-2.96.128.i386.rpm and llibstdc++-libc6.2-2.so.3 library from the compatlibstdc+. These packages might not be part of the standard configuration. You must use update 4 or update 5.
Creating a native package

You must manually install the rpmbuild package 4.2 or later on Linux machines, if the rpmbuild package is not installed on the machines by default.
Solaris requirements
If the required UNIX X11 libraries are missing, the tuner does not start. The SUNWxwrtl package contains the following required UNIX X11 libraries:
s s s s
libXm.so.3 libXt.so.4 libX11.so.4 libXext.so.0
The package size for SUNWxwrtl is minimal because all this installation does is set the proper sym-links to core OS files. The cumulative size of all the files referenced by the sym-links in this package is 7.21 MB.
NOTE
Make sure that you install all necessary patches for the JRE before installing BMC BladeLogic Client Automation products. For information about patches for 1.6, check http://java.sun.com/javase/6/.
66
Chapter
6
67 71 72 72 74 76 76 77 79 79 80 83 83 84
How to install the basic components

This section describes how to perform a fresh installation of a tuner, the master transmitter, the CMS console, and the BMC BladeLogic Client Automation modules that compose the product. This chapter presents the following topics: Installation worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Downloading the installation files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the basic components on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the master transmitter and tuner on Windows . . . . . . . . . . . . . . . . . . . . Installing the CMS console on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the basic components on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the master transmitter and tuner on Linux . . . . . . . . . . . . . . . . . . . . . . . Installing the CMS console on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the BMC BladeLogic Client Automation modules . . . . . . . . . . . . . . . . . . . . Logging in to the CMS console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Install Products workflow to install modules . . . . . . . . . . . . . . . . . . . . . Using Channel Manager versus Infrastructure Administration to manage channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Channel Manager to manage channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Infrastructure Administration runchannel program . . . . . . . . . . . . . . .
Installation worksheets
Table 1 on page 68 contains the prompts and any default values that you encounter when you run the installation program on Windows, Solaris, or Linux machines.
s
If you choose to install the master transmitter and console on the same machine, the prompts in this table reflect the order in which the prompts appear in the installation program.
Chapter 6
67
If you choose to install the components on separate machines, which is recommended for a production environment, not all prompts are displayed for both installation paths. Table 1 on page 68 shows each prompt and the components to which it corresponds.
Table 1
Master transmitter BBCA Console
Installation prompts for master transmitter and console on Windows (part 1 of 3)
Panel and prompt Description Destination directory Default value:

s
Value
(Windows) C:\Progam Files\BMC Software\BBCA (UNIX) /opt/bmc/BBCA
Workspace directory
Default value:
s
(Windows) C:\Progam Files\BMC Software\BBCA\Tuner (UNIX) /opt/bmc/BBCA/Tuner
Tuner Administration Port Number
Default value: 7717
Proxy Configuration HTTP Host Name Select to activate text boxes for credentials. Port Number User name Password Confirm password HTTPS Host Name Select to activate text boxes for credentials. Port Number User name Password Confirm password SOCKS Host Name Select to activate text boxes. Allow proxy to resolve hosts Port Number
Select either the Yes and No option button.
68
Table 1
Panel and prompt Description Proxy Exceptions This panel is displayed if you select the HTTP, HTTPS, or SOCKS check box on the Proxy Configuration panel. Use this panel to enter a comma-delimited list of host suffixes for which the proxy settings do not apply.
Value
BBCA Console HTTP Port Number Database Selection
This panel is displayed if you are installing the console. Default value: 8888 Select a database now or choose to specify a database when you use the CMS console to configure the product. Default value: Microsoft SQL Server. Unless you select Do not configure Database at this time, you must complete the Database Configuration panel.
Database Configuration Oracle Host Name Port Number: 1521 (default) Database Instance Use Net Service Name For Oracle RAC, type the net service name in Database Instance and select this check box. Database Admin User Name and Password (and confirmation) SQL Server Host Name Port Number: 1433 (default) Database Name Database Admin User Name and Password (and confirmation) invdb
Database User Database users that require authentication. You will Configuration also need these passwords during product upgrades. inventory password: Password for the user that creates and maintains structures used by the product. user_view password: Password for the user that queries the Inventory database structures in Report Center.
Chapter 6
69
Table 1
Panel and prompt Description Schema Install In addition to the Core schema, which you must Selection install, you can also choose to have the installation program install any combination of the other product schemas. ISM Schema If you selected to install the Infrastructure Status User Monitor schema, provide the following credentials: Configuration s ISM administrator password s ISM user password Channel Install Use this panel to select a location from which to copy Source Selection and install the BMC BladeLogic Client Automation modules:
s
Value
Install from media at the following location You can type a location or click Browse.
Install channels from BMC Software via Internet The location of the current version is displayed by default.
Do not install any channels at this time
When running the Windows installation program and you choose to install channels, the installation program also creates a profile and installer for a managed node. + Copy Channels If you select a location from which to copy and install the products, you use this panel to select the products. + Add/Remove When you select Yes, you enable your users to Program uninstall the tuner from their desktop computers. By Uninstall default, this option is set to No. Selection
70
Downloading the installation files
Downloading the installation files

This procedure describes how to download the installation files from the BMC Electronic Product Distribution (EPD) website. You access the EPD site from the BMC Support Central website.
Before you begin

s
Refer to the Release Notes for any known issues for a fresh installation of the product or individual components. To access the EPD website, you must provide user credentials. If you do not have a user name and password, you can set up login credentials on the Login page.
To download the BMC BladeLogic Client Automation installation files 1 Access BMC Support Central, the Customer Support website, at
http://www.bmc.com/support_home.
2 In the navigation pane, select Downloads & Patches. 3 Under Product Downloads, Patches, and Fixes, click Product Downloads (EPD). 4 On the Login page, type your user name and password, and click Submit. 5 On the Export Validation & License Terms page, complete the required options,
and click Continue.
6 On the Select Product page, select BMC BladeLogic Client Automation or BMC
Configuration Management Control Center, and click Continue.
7 On the Select Product Version page, select the version and platform to install, and
click Continue.
8 On the Download Files page, download the following files to your computer:
s
BMC BladeLogic Client Automation Configuration Discovery Integration for CMDB BMC BladeLogic Client Automation installation program Documentation for BMC BladeLogic Client Automation
Chapter 6
71
Installing the basic components on Windows
Where to go from here

Proceed to one of the following tasks:
s s s
Installing the basic components on Windows Installing the basic components on Linux on page 76 Installing the basic components on HP-UX and AIX on page 79
Installing the basic components on Windows

The tasks in this section describe how to install the master transmitter and CMS console on separate computers. To install these components on Windows, complete the following tasks, in the order presented: 1. Verify that you have completed the prerequisite tasks described in Chapter 5, Before you install, starting on page 53 and Installation worksheets on page 67. 2. Install the master transmitter and tuner, as described on page 72. 3. Install the CMS console, as described on page 74. 4. Install the BMC BladeLogic Client Automation products, as described on page 79. After you have finished installing the basic components, you can use the prepackaged tuner to create and customize you configuration automation environment.
Installing the master transmitter and tuner on Windows

This task describes how to install the master transmitter and a tuner on a Windows computer.
Before you begin

s
Verify that you have completed the prerequisite tasks described in Chapter 5, Before you install, starting on page 53. Locate the installation media or folder on your computer that contains the following installation program:
s
BBCA8202_win_x64.exe: Enables you to install Master Transmitter. Use this program if you want to install tuner in 64-bit mode.
72
Installing the master transmitter and tuner on Windows
BBCA8202_win_x86.exe: Enables you to install Master Transmitter and Console server. Use this program if you want to install tuner in 36-bit mode.
Note: Only the 32-Bit Tuner supports the CMS. The 64-Bit Tuner does not support the CMS.
s
Complete the installation worksheet in Table 1 on page 68. Exit all other programs. Using the instructions described in Downloading the installation files on page 71, download the installation program to your computer.
To install the master transmitter and tuner on Windows 1 If necessary, copy the installation program from the download location to the
machine that will host the master transmitter.
2 Start the installation program.

If the installation program detects a problem with your computer setup, the Initialization Problem panel is displayed. Depending on the problem, the program, the installation program might enable you to continue, but to fix the problem described on this panel, click Cancel.
3 On the Welcome panel, click Next. 4 To accept the license agreement, select I agree to the terms of the License Agreement,
and click Next.
5 On the Feature Selection panel, select Install Master Transmitter 8.2.02, and click
Next.
6 Using Table 1 on page 68, review and update the remaining installation panels. 7 Review the settings on the Installation Preview panel, and click Install.
After a few minutes, a Tuner Installation Completed dialog box is displayed, indicating the tuner and a master transmitter are installed. The master transmitter is not enabled until you install the CMS console and configure the master transmitter.
8 Click Done. 9 If you chose to copy the channels to the master transmitter, you can view the status
of the copy operation by viewing the following file:
temporaryDirectory\BBCAPostInstallChannelCopy.txt
Chapter 6
73
Installing the CMS console on Windows

Perform one of the following actions:
s
If you chose to install the master transmitter and CMS console on separate machines, install the CMS console as described in Installing the CMS console on Windows. If you installed the master transmitter and CMS console on the same machine, you are ready to log in to the CMS console and copy your purchased BMC BladeLogic Client Automation products to your master transmitter as described in Installing the BMC BladeLogic Client Automation modules on page 79.

This task describes how to install the CMS console and a tuner on a machine where you have not installed the master transmitter.
Before you begin

s
Verify that you have completed the prerequisite tasks described in Chapter 5, Before you install, starting on page 53. Locate the installation media or folder on your computer that contains the following installation program.
s
BBCA8202_win_x86.exe: Enables you to install Master Transmitter and Console server. Use this program if you want to install tuner in 32-bit mode.
Note: Only the 32-Bit Tuner supports the CMS. The 64-Bit Tuner does not support the CMS.
s
Exit all other programs. Complete the installation worksheets in Table 1 on page 68. Install the master transmitter on a different machine as described in Installing the master transmitter and tuner on Windows on page 72.
74
To install the CMS console on a machine separate from the master transmitter 1 Copy the installation program from the download location to the designated host
machine for the CMS console and double-click to start.
s
If the installation wizard detects a tuner on your machine, you are prompted to remove or keep the tuner. BMC recommends that you remove the existing tuner when installing from the website. If the installation program detects a problem with your computer setup, the Initialization Problem panel is displayed. The installation program enables you to continue, but to fix the problem described on this panel, click Cancel.
2 On the Welcome panel, click Next. 3 To accept the license agreement, select I agree to the terms of the License Agreement,
and click Next.
4 On the Feature Selection panel, select Install BBCA Console 8.2.02, and click Next. 5 Using Table 1 on page 68, review and update the remaining installation panels. 6 Review the installation settings and click Install.
After a few minutes, a Tuner Installation Completed dialog box displays indicating the tuner and the CMS console are installed.
7 Click Done.
The BMC Configuration Management Login web page is displayed. You use this page to log on to the CMS console.

Log on to the CMS console and install the individual products, as described in Installing the BMC BladeLogic Client Automation modules on page 79.
Chapter 6
75
Installing the basic components on Linux
Installing the basic components on Linux

The tasks in this section describe how to install the master transmitter and CMS console on separate machines. The installation program also installs a tuner with each component. To install these components on Solaris or Linux, complete the following tasks, in the order presented: 1. Verify that you have completed the prerequisite tasks described in Chapter 5, Before you install, starting on page 53 and Installation worksheets on page 67. 2. Install the master transmitter and tuner, as described on page 76. 3. Install the CMS console, as described on page 77. 4. Install the BMC BladeLogic Client Automation products, as described on page 79. After you have finished installing the basic components, you can use the tuner to create and customize you configuration automation environment.
Installing the master transmitter and tuner on Linux

After you download the installation files, use the installation script to install the master transmitter. By default, a standard prepackaged tuner is also downloaded. Use this tuner as the starting point for creating and customizing your BMC BladeLogic Client Automation environment.
Before you begin

s
Verify that you have completed the prerequisite tasks described in Chapter 5, Before you install, starting on page 53. Complete the installation worksheet in Table 1 on page 68. Using the instructions described in Downloading the installation files on page 71, download the installation program to your computer. Locate the installation media or folder on your computer that contains the installation program for your operating system:
BBCA8202_lnux.bin
Exit all other programs.
76
Installing the master transmitter and tuner on Linux
To install the master transmitter and tuner on Linux 1 If necessary, copy the installation program from the download location to the
machine that will host the master transmitter.
2 Start the installation program. 3 On the Welcome panel, click Next. 4 To accept the license agreement, select I agree to the terms of the License Agreement,
and click Next.
5 On the Feature Selection panel, select Install Master Transmitter 8.2.02, and click
Next.
6 Using Table 1 on page 68, fill in the installation prompts. 7 Review the settings on the Installation Preview panel, and click Install.
After a few minutes, a Tuner Installation Completed dialog box is displayed, indicating the tuner and a master transmitter are installed. The master transmitter is not enabled until you install the CMS console and configure the master transmitter.
8 Click Done. 9 If you chose to copy the channels to the master transmitter, you can view the status
of the copy operation by viewing the following file:
/tmp/BBCAPostInstallChannelCopy.txt

The next step in the installation process:
s
If you elected to install the master transmitter and CMS console on separate machines, install the CMS console as described in Installing the CMS console on Linux. Otherwise, you are ready to log in to the CMS console, from the browser, and copy your purchased products (channels) to your master transmitter as described in Installing the BMC BladeLogic Client Automation modules on page 79.
Chapter 6
77
Installing the CMS console on Linux
Installing the CMS console on Linux

This task describes how to install the CMS console and a tuner on a machine where you have not installed the master transmitter.
Before you begin

s
Verify that you have completed the prerequisite tasks described in Chapter 5, Before you install, starting on page 53. Complete the installation worksheets in Table 1 on page 68. Using the instructions described in Downloading the installation files on page 71, download the installation files to your computer. Locate the installation media or folder on your computer that contains the installation program for your operating system:
BBCA8202_lnux.bin
Exit all other programs. Install the master transmitter and CMS console as described in one of the following procedures: Installing the master transmitter and tuner on Windows on page 72 Installing the master transmitter and tuner on Linux on page 76
To install the CMS console on Linux 1 If necessary, copy the installation program from the download location to the
machine that will host the CMS console.
2 Start the installation program. 3 On the Welcome panel, click Next. 4 To accept the license agreement, select I agree to the terms of the License Agreement,
and click Next.
5 On the Feature Selection panel, select Install CMS console 8.2.02, and click Next. 6 Using Table 1 on page 68, fill in the installation prompts.
When the installation script completes, a browser page is displayed.
78
Installing the BMC BladeLogic Client Automation modules

Log on to the CMS console and install the individual products, as described in Installing the BMC BladeLogic Client Automation modules on page 79.
Installing the BMC BladeLogic Client Automation modules

This procedures in this section describe how to log in to the CMS console and use the Install Products workflow in the CMS console to copy your modules to the master transmitter.
NOTE
If you used the installation program to perform a fresh installation of the product and you chose to copy the channels to the master transmitter, you do not need to perform the procedures in this section.
Logging in to the CMS console

When the installation program is finished, the BMC Welcome page is displayed. The procedure in this section describes how to access and log in to the CMS console on a local or remote machine. Unless you change them, you access the CMS console by entering the following credentials:
s s
user name: admin. password: leave blank.
Unless you changed the default port number when you installed the CMS console, you can use the following URL to access the CMS console: http://localhost:8888/mim/unifiedinstaller/unifiedinstaller.jsp.
Chapter 6
79
Using the Install Products workflow to install modules
To log in to the CMS console 1 Open a browser, and type the following URL in Address or Location:
http://machineName:portNumber/mim/unifiedinstaller/unifiedinstaller.jsp
where:
s s
machineName: name of the machine on which you installed the CMS console portNumber: HTTP port number for the CMS console, which is 8888 by default.
2 Type the CMS console authentication credentials, and click Log In: 3 If the Welcome page is displayed, perform any required tasks, and click Continue.

The Install Products workflow is located on the right side of the Setup & Deployment page and guides you through the process of installing the product modules. The Install Products workflow shows the status of your progress in the wizard, as shown in Figure 1. Figure 1 Install Products workflow
If you need to stop in the middle of a workflow, you can log out. When you log back in, you are returned to the place in the workflow where you left off. The Install Products workflow provides help in the following ways:
s s
Field help: To display, place your cursor on a field name. General help: To display, click Help in the top right corner of the window.
80
Before you begin

s
You must know the location of the Master Transmitter. Verify that the target computer has the required space for the modules. If you just logged in for the first time, the Setup and Deployment page is displayed and the Infrastructure Setup tab is selected. If you are not already logged in, use the procedure in Logging in to the CMS console on page 79 to access the CMS console. If the tuner is running as an NT service, you cannot copy products to a mapped network drive. You can only copy products to a mapped network drive when the tuner is running as an application.
To run the Install Products workflow 1 On the first page of the Install Products workflow, click Next to display the Install
Products:Install Source page.
2 Select an installation source, and click Next:

s s
If installing from CD-ROM or a location on the file system, provide the path. If installing from the Customer Support website, type a user name and password.
NOTE
Occasionally, when you install using the Internet, your channels are delivered from a password-protected area on the products.marimba.com transmitter. Password protection is typically used for hot fixes or beta versions of products, and not for standard releases. If a user name and password are required, contact BMC Support to get this information.
3 On the Install Products:Location of the Master Transmitter page, provide the

following location information for your master transmitter, and click Next:
Item Host name Administration port Listener port Description The name or IP address of the machine on which you installed your master transmitter. The default host name is localhost. The port of the tuner on which the master transmitter is running. The default administration (tuner) port is 7717, unless you changed the port when doing a custom installation. The port the master transmitter uses to listen for requests from clients (endpoints). The default master transmitter listener port is 5282, unless you changed the port when doing a custom installation.
Chapter 6
81
Item
Description
Use SSL for tuner Select this if you are using Secure Socket Layer encrypted communication between Tuner Administration and your tuner. Use SSL for transmitter Select this if you are using Secure Socket Layer encrypted communication between Transmitter Administration and your transmitter.
4 On the Install Products: Copy Channels page, review the channel selections, and
click Next. By default all purchased channels (modules) are selected to be copied. BMC Software recommends that you accept this default and copy all the channels. The selected channels are copied to your master transmitter. This process can take several minutes. When the process is finished, the Install Products: Download Complete page is displayed.
NOTE
If the wizard could not copy some of the channels, it lists those channels. To save this information, print the browser page.
5 On the Install Products: Download Complete page, click Done. 6 To view a list of your installed modules (channels), perform one of the following
actions:
s
Right-click the tuner icon in your system tray. Choose Start => All Programs => BMC Software => BMC BladeLogic Client Automation => Tuner. Your tuner displays and starts all available channels. From the CMS console, choose Applications => Infrastructure => Transmitter Administration. The Connect to a Transmitter page is displayed and shows your installed channels.
Using a browser, browse to the URL for your master transmitter. For example, http://hostName:5282 where hostName is the name of the machine hosting your master transmitter and 5282 is the default port.
On UNIX, you can check your UNIX system processes to view the tuner and installed channels.
82
Using Channel Manager versus Infrastructure Administration to manage channels
On Windows, the tuner is installed as a Windows service with automatic startup, so that the tuner starts when the machine is rebooted. The name of the service is BCA-Clients Tuner Service.
Using Channel Manager versus Infrastructure Administration to manage channels

Channel Manager is the interface to the tuner is and is deployed automatically. This interface is local to the machine and is not browser-based. You can use Channel Manager to administer channels on the machine that is local to the CMS console. To administer channels on any machine that is not local to the CMS console, you must use Infrastructure Administration.
Using Channel Manager to manage channels

Although BMC Software recommends that you use the Infrastructure Administrator to perform configuration management tasks, the Channel Manager is convenient for performing tasks on the local CMS console. You might use Channel Manager to:
s s
Perform emergency operations if the CMS console is not working. Perform some configuration tasks on the CMS console, for example, changing the folder from which the CMS console is subscribed. (This cannot be done by Infrastructure Administration.)
For additional information about the tasks you can perform with Channel Manager, click Help in Channel Manager.
To launch Channel Manager from the Start menu on Windows 1 From the Start menu, choose Start => All Programs => BMC Software => BMC
BladeLogic Client Automation => Tuner.
NOTE
In Windows OS, when you right click any channel in the Channel Manager, you cannot view the shortcut of the menus for this channel installed on tuners of version 7.5.00 or later.
Chapter 6
83
Using the Infrastructure Administration runchannel program

The runchannel program is a command-line interface to Deployment Manager. You can also use the following runchannel arguments for the Infrastructure Administration. For more information about the runchannel program, see the BMC BladeLogic Client Automation Package Deployment CLI Guide.
s
-channels Use to specify selected channels when installing products from the source transmitter. You can specify multiple channels by separating the values with a comma.
runchannel "http://dasher.marimba.com:5282/Marimba/Current/ InfrastructureAdministration" -user admin -password "" moduleinstallProducts -keyProduct CGESNZZUNCPGUABMNUSTFW keyUserM24931LTEST5 -keyPw AAV88DYR -license internet -txAdminPort 7717 -txHost localhost -src internet -txListenPort 5282-channels InfrastructureAdministration,ConsoleWindow,HelpManager
-channelFilename Use to provide selected channel names from a text file.

runchannel "http://dasher.marimba.com:5282/Marimba/Current/ InfrastructureAdministration" -user admin -password "" moduleinstallProducts -keyProduct CGESNZZUNCPGUABMNUSTFW keyUserM24931LTEST5 -keyPw AAV88DYR -license internet -txAdminPort 7717-txHost localhost -src internet -txListenPort 5282 channelFileName c:\channels.txt
In the sample command, c:\channels.txt contains channel names separated by a comma, a tab, or a newline character.
s
-txRepUserName tx_Replication_username Use to specify an authenticated user name.
-txRepPassword tx_Replication_password Use to specify an authenticated password.
84
Examples of -txRepUserName and -txRepPassword

runchannel http://dasher.marimba.com:5282/Marimba/Current/ InfrastructureAdministration" -user admin -password "" moduleinstallProducts -keyProduct $productKey -keyUser $productUser-keyPw $productPwd -license internet -txAdminPort $txAdminPort-txHost $txHost -txListenPort $txListenerPort -src internet-txRepUserName tx_Replication_username-txRepPassword tx_Replication_password
When you use remote deployment to send an installer to a remote machine, the remote machine should already be running in the specific locale (from machine bootup) in which the Latin-1 path was created. This eliminates any corrupted or garbled characters in the installation path. For example, you create a tuner installer with Spanish characters in the installation path. Before deploying it to a remote machine, you must perform the following actions on the remote machine:
s s s
Set the locale to Spanish. Set the locale as default. Restart the machine so that the machine boots up with the Spanish locale.

You have now installed a master transmitter, a tuner, the CMS console, and your purchased BMC BladeLogic Client Automation products have been copied to the master transmitter. Now you can set up the inventory management database and its associated core schema as described in Chapter 7, Setting up Inventory Management on page 97.
Chapter 6
85
86
Part
Part 3
Postinstallation activities
This part presents the following chapters. The appendices on this page also contain information related to postinstallation activities. Chapter 7 Setting up Inventory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Chapter 8 Setting up the Infrastructure Status Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Chapter 9 Setting up Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Chapter 10 Setting up Patch Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Chapter 11 Setting up Security Compliance modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Chapter 12 Setting up Deployment Manager and Content Replicator . . . . . . . . . . . . . . . . . . . 157 Chapter 13 Creating profiles, installers, and running deployments . . . . . . . . . . . . . . . . . . . . . 163 Chapter 14 Integrating tuner installation with OS provisioning . . . . . . . . . . . . . . . . . . . . . . . . 197 Chapter 15 Verifying that BMC BladeLogic Client Automation is set up correctly . . . . . . . . 211 Appendix A Database tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Part 3 Postinstallation activities
87
Appendix B Using a ghost image to deploy product modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Appendix C Manual database schema installation and updates . . . . . . . . . . . . . . . . . . . . . . . . . 333
88
Chapter
Setting up Inventory Management

This chapter describes how to use Schema Manager to install the Inventory Management module, which includes Report Center, the Query Library, and the Inventory database. This module also includes the Core schema used for storing inventory, logging, LDAP synchronization, and Deployment Manager data. Instructions for updating the database schema after a product upgrade are provided in Appendix C, Manual database schema installation and updates. This chapter presents the following topics: Inventory Management components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Overview of Inventory Management setup process. . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Installing the Inventory database schema modules and query libraries . . . . . . . . . . . 92 Installation options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Available schema modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Installation order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Database roles and users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Using the Easy install option to install the Inventory database schema modules and query libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Using the Custom install option to install the database schema modules and query libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Verifying the availability of the Query Library queries . . . . . . . . . . . . . . . . . . . . . . . . 100 Configuring the inventory and logging plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Configuring user and group access to the console . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
89
Inventory Management components

Inventory Management includes the components listed in Table 1. Table 1
Component Inventory database schemas

Description The Inventory database is composed of the following database schema modules:
s s s s s
Core schema, which is a prerequisite for all other schema modules. Individual schema modules that support the product modules. Centralized logging schema. LDAP synchronization schema Deployment Manager schema.
Report Center
Accessed from the CMS console, this module provides the interface for creating database queries and for configuring the inventory plug-in and the logging plugin. If you followed the instructions in Installing the CMS console on Windows on page 75 or Installing the CMS console on Linux on page 78, you installed Report Center when you installed the CMS console.
Inventory plug-in and logging plug-in
These plug-ins extend the functionality of the master transmitter.

s
The inventory plug-in is the server-side component of the Scanner Service channel. This plug-in collects inventory data from the endpoint and forwards it to the database. The logging plug-in is the server-side component of the Logging Service channel. This plug-in collects and forwards filtered log to the database.
For more information about these plug-ins, see Configuring the inventory and logging plug-ins on page 101. Integration with a directory service
If you plan to use the Policy Management module or use a directory service for user authentication, you use the CMS console System Settings to configure user and group access. For more information, see Configuring user and group access to the console on page 102. The Scanner Service (Inventory Service) scans the endpoint machine for inventory information and retrieves software usage, compliance, and patch information (if you purchased the corresponding products). The Logging Service collects log messages from the BMC BladeLogic Client Automation components that you specify, and at the specified severity level. The Logging Service also sends the log files back to the database according to the schedule and triggers that you specify. For more information, see Creating installers on page 176.
Scanner and Logging Services
90
Overview of Inventory Management setup process
Overview of Inventory Management setup process

This section provides an overview of the steps required to set up Inventory Management. Subsequent sections in this chapter provide detailed instructions for each high-level step. Table 2
Step 1 Review the following sections to ensure that your database type meets system requirements and guidelines before installing Inventory Management:
s s
Steps to install and set up Inventory Management
Determining the infrastructure platforms and hardware on page 33 Database requirements on page 54
Review the installation options (Easy, Custom, or Manual) to determine which method to use.
For more information about these options, see Installing the Inventory database schema modules and query libraries on page 92.
3
Use Schema Manager to install the Inventory database schema modules, or download installation files and install the schema from a command line. For detailed procedures, see the following options:
s
Using the Easy install option to install the Inventory database schema modules and query libraries on page 94 Using the Custom install option to install the database schema modules and query libraries on page 97 Manually installing or reinstalling the database schema on page 333
If you used the BMC BladeLogic Client Automation installation program to install the Inventory database modules in a test or development environment, you can skip this step.
4
Verify that the Query Library of Report Center is available. The Query Library contains predefined reports that you can run to display inventory information about the machines in your enterprise. For information about performing this step, see Verifying the availability of the Query Library queries on page 100.
Configure the Inventory and Logging plug-ins.
For detailed information, see Configuring the inventory and logging plug-ins on page 101.
6 Configure user and group access to the CMS console.
For more information, see Configuring user and group access to the console on page 102.
91
Installing the Inventory database schema modules and query libraries
Installing the Inventory database schema modules and query libraries

When you install an Inventory schema module, you also install a query library that contains predefined queries that you can use to generate reports in Report Center.
NOTE
If you used the installation program to install the Inventory database schema, you can skip this section and proceed to the section about configuring after a schema installation. If you did not use the installation program to install the Inventory schema, you must use Schema Manager to install it.
Installation options
When you install the database schemas and query libraries, you have several options from which to choose.
s
Easy install, which is the quickest way to install the database schema. However, in production environments, BMC recommends that you use one of the other installation options. Custom install, which enables you to change some of the default database settings. Manual install, which enables you to download the database scripts and install the schema from a command line. You might want manually install the schema if you Do not have access to the CMS console. Want to verify the database installation information. Want to override default values. For detailed information about downloading and running the installation files from a command line, see Appendix C, Manual database schema installation and updates.
Available schema modules

The Schema Modules tab on the Database Schemas page lists the available schema modules and shows whether the schema is installed, and if it is installed, the version number of the schema. You always need the Core schema, but the modules that you intend to use determine which of the other schema modules to install.
92
Installation order
Installation order
You must install the Core schema before you try to install any of the other schema modules, including the Infrastructure Status Monitor schema. The Core schema also includes the Inventory schema and the LDAP Synchronization schema. When you install the Inventory schema, the installation program creates the data files and user accounts in the database. After you install the Core schema, the order in which you install the other schema modules does not matter. The installation process of the other schema modules inserts tables for those modules into the Core schema. To view instructions that describe how to install the schema on a Microsoft SQL Server 2005 cluster, see the Schema Manager Help.
Database roles and users

When you install the core schema for the Inventory database, the installation process creates the database roles and users listed in Table 3. Table 3 Database roles and users (part 1 of 2)
Description
s
Role or user user_view user inv_view role
inv_view role. Users with this read-only role can perform queries on the Inventory database and view the results. user_view. The user_view user (and password of the same name) is granted the inv_view role. The user_view user can access the database views, but not the inventory tables.
93
Using the Easy install option to install the Inventory database schema modules and query libraries
Table 3
Database roles and users (part 2 of 2)

Description The inventory user (and password of the same name) can alter the inventory and logging tables, sequences, procedures, and more. It is the default account used by the Inventory and Logging plug-ins to send data to the database. When you log on to the schema as the inventory user, you can perform limited actions on the Inventory database: s On the Schema Manager tab, you can access only the Manual install option s On the System Maintenance tab, you cannot see the following maintenance scripts: Oracle: clean-inventory-tables, clean-duplicates-from-inventory-tables, removedeleted-nodes, recompile-all-the-objects-with-invalid-status, remove-deletednode-logs-by-date, remove-software-usage-records-completely SQL Server: clean-inventory-tables, clean-duplicates-from-inventory-tables, remove-deleted-nodes, recompile-all-the-objects-with-invalid-status, removedeleted-node-logs-by-date, remove-software-usage-records, and fixoverflowingidentities s On the Database Tools tab, Oracle users cannot see Database Info.
Role or user inventory user
dbtree user dbtree_role
This user and role are used internally by the BMC BladeLogic Client Automation modules. It is through this user account and role that data manipulation is handled against schema objects related to the Query Library. On Oracle, the inventory user is the owner of this object. On SQL Server, the sa user is the owner.
The Easy install option installs both the database schema and the related query library at the same time. You can select this option only if you do not need to change any of the default database settings. You use this procedure to install any schema module, but you must install the Core schema first. For Oracle 10g, the easy installation process creates the database files at oracle_home\database. The oracle_home variable points to oracle\product\10.2.0\db_1. BMC Software recommends that you use this installation option for non-production environments only.
94
Before you begin

s
Ensure that the target database meets the requirements specified in Table 1 on page 33 and Database requirements on page 54. You must have installed the master transmitter, the CMS console, Schema Manager, and the tuner. Terminate all user connections to the database instance. If you started using Report Center and configured the Inventory plug-in to insert data into your database, disable the Inventory plug-in. For details about how to disable this plug-in, see the BMC BladeLogic Client Automation Report Center Guide or Report Center Help. If necessary, log in to the CMS console as a primary administrator, as described in Logging in to the CMS console on page 87.
To connect to the Inventory database

You must connect to the Inventory database before you can perform any actions on the schema modules that comprise the Inventory database.
1 Choose Applications => Console => Schema Manager. 2 Select the Inventory Database tab. 3 On the Database page, provide the database attributes:
Table 4 Inventory database connection attributes (part 1 of 2)
Description Oracle or SQL Server Host name of the computer on which the database is installed. Commonly used port numbers :
s s
Database attribute Database type Host Name Port
Oracle: 1521 SQL Server: 1433
SID
For SQL Server, the database system ID is invdb, unless you edited all the necessary database setup scripts to change this value, which is not recommended. For Oracle RAC, type the net service name, and select Use Net Service Name.
Use Net Service Name
Indicates that the entry in SID is a net service name.
95
Table 4
Inventory database connection attributes (part 2 of 2)

Description
s s s
Database attribute
System administrator user

name System administrator password inventory password
Default system administrator user name for Oracle: system Default system administrator user name for SQL Server: sa Default inventory user name: inventory
Password required to authenticate the user. Default: inventory Note: If a custom password is set, you must provide the appropriate password.
user_view password
Default: user_view Note: If a custom password is set, you must provide the appropriate password.
TIP
Often, the Oracle system administrator user name is system and the default password is manager; on SQL Server, the user name is often sa, and the default password is no password. However, verify these credentials with your DBA.
4 Click Connect. To use the Easy install option to install the Inventory database schema modules 1 On the Database Schema page, select the Schema Modules tab. 2 On the Schema Modules sub tab under Action, click Install for Core. 3 On the Install Options page, select Easy install, and click Install.
Processing messages are displayed. Several error messages might be generated when the script drops tables that may not exist. You can ignore these messages.
4 To install the database schema and query libraries for other modules, such as
Software Usage, Software License Compliance, and Patch Management, repeat step 2 on page 96 and step 3 on page 96 for each schema module.

Verify that the installation program successfully installed the query libraries for each installed module in Report Center. For information about this procedure, see Verifying the availability of the Query Library queries on page 100.
96
Using the Custom install option to install the database schema modules and query libraries
NOTE
During the installation of the Core schema on Oracle, the inventory user requires DBA permission to execute the getdbmetadata procedure. The installation process temporarily grants this permission and then revokes it when the installation is finished. If you log on to Oracle Enterprise to view the status of the getdbmetadata procedure, the procedure is invalid.
The Custom install option enables you to use the GUI to modify the default settings when you install the schema modules and their corresponding query libraries. Although Schema Manager gives you several options for installing the database schema (Easy, Custom, and Manual), BMC Software recommends that you use the Custom installation option for the following conditions: The Custom installation option enables you to
s
Change passwords. When you install the Core schema, BMC Software recommends that you change the passwords for the database users (inventory, dbtree, and user_view) that are created during the schema installation.
Install the schema or the Query Library but not both at the same time. Review and modify file paths and size parameters for the various data files and index files in the Inventory database. The default data file path for SQL Server is C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\inv_sys01.mdf (the file name and extension can vary). To create the database files (for SQL Server or Oracle) in another location, edit the boxes that display the database path. These files are described Table 5 on page 98
To use a location other than the default (on the C drive) for your Microsoft SQL Server database.
97
Change the size of the database. Most of the text boxes on the Custom installation page pertain to size settings for the database. Because most databases are installed on servers that have significant disk space, the default setting of 300 MB is adequate for most environments. For some production environments, you might need to increase the default size. Only consider decreasing the database size in test or development environments where you might use small data sets.
Because these settings apply to the database and not the individual tables that are created by the modules, the custom settings do not apply to other schema modules. After you install the Core schema, the database is created, and the Custom installation page for the other schema modules does not display text boxes to change database settings. Table 5
File Inventory data file
Inventory database data and index files (part 1 of 2)

Function (Oracle) The inv_data tablespace is the primary inventory tablespace. The inv_data_2 tablespace (inventory data file 2) contains tables that change infrequently. This table requires at least 01.15 KB of disk space for each scan report if WMI-enabled; otherwise 0.031 KB. (SQL Server) Relates to the invdatagroup filegroup. Most of the tables and sequences are created in this tablespace. It is the largest tablespace and requires at least 24 KB of disk space for each scan report if the machine is WMI-enabled; otherwise 12 KB. (Patch Management) The default initial size of the data file is 100 MB.
Inventory index file (Oracle) The inv_index tablespace contains the indexes and constraints for the inv_data tables. This file requires at least 18 KB of disk space for each scan report if WMI-enabled; otherwise 12 KB. The inv_index_2 tablespace contains the indexes and constraints for the inv_data_2 tables. This file requires at least 01.70 KB of disk space for each scan report if WMI-enabled; otherwise 0.075 KB. (SQL Server) Relates to the invindexgroup filegroup. This file requires at least 18 KB of disk space for each scan report if WMI-enabled; otherwise 12 KB. (Patch Management) The default initial size of the index file is 100 MB. Inventory log file Logging data file This file applies to Microsoft SQL Server only. (Oracle) The log_data tablespace contains the schema objects, except for the indexes, for the logging application. (SQL Server) Relates to the loggingdatagroup filegroup. Logging index file (Oracle) The log_index tablespace contains all the indexes related to the logging application. (SQL Server) Relates to the loggingindexgroup filegroup.
98
Table 5
File
Inventory database data and index files (part 2 of 2)

Function (Oracle) The dbtree_data tablespace contains all the schema objects, except for indexes, for Report Center. (SQL Server) Relates to the dbtreedatagroup filegroup.
DBTree data file
DBTree index file
(Oracle) The dbtree_index tablespace contains all the indexes related to Report
Center.
(SQL Server) Relates to the dbtreeindexgroup filegroup. Power Management (Oracle) The pm_data tablespace contains the schema objects, except for the indexes, data file for the Power Management application. (SQL Server) Relates to the pmdatagroupfile filegroup. Power Management (Oracle) The pm_index tablespace contains all the indexes related to the Power index file Management application. (SQL Server) Relates to the pmindexgroupfile filegroup. Indexed view for SQL Server and materialized view for Oracle databases has been introduced for Power Management application.
Before you begin

s
Ensure that the target database meets the requirements specified in Table 1 on page 33 and Database requirements on page 54. You must have installed the master transmitter, the CMS console, Schema Manager, and the tuner. Terminate all user connections to the database instance. If you started using Report Center and configured the Inventory plug-in to insert data into your database, disable the Inventory plug-in. For details about how to disable this plug-in, see the BMC BladeLogic Client Automation Report Center Guide or Report Center Help. You must be logged on to the CMS console as a primary administrator, as described in Logging in to the CMS console on page 87.
To use the custom option to install the Inventory database schema modules 1 In the Schema Manager module, select the Inventory Database tab and connect to
the Inventory database as the system administrator. For instructions about connecting to the Inventory database, see To connect to the
Inventory database on page 95.
99
Verifying the availability of the Query Library queries
The Database Schemas page is displayed.
2 On the Schema Modules sub tab under Action, click Install for Core. 3 On the Install Options page, select Custom Install, review the current settings and
modify the setting as necessary, and click Install. Processing messages are displayed. Several error messages might be generated when the script drops tables that may not exist. You can ignore these messages. When the operation is finished, an Installation Complete page is displayed. For a description of the user accounts and roles that were created as part of this installation process, see Database roles and users on page 93.
4 To install the database schema and Query Library queries for other modules, such
as Software Usage, Software License Compliance, and Patch Management, repeat step 2 on page 100 and step 3 on page 100 for each schema module.

Verify that the installation program successfully installed the query libraries for each installed module in Report Center. For information about this procedure, see Verifying the availability of the Query Library queries on page 100.
NOTE
During the installation of the Core schema on Oracle, the inventory user requires DBA permission to execute the getdbmetadata procedure. The installation process temporarily grants this permission and then revokes it when the installation is finished. If you log on to Oracle Enterprise to view the status of the getdbmetadata procedure, the procedure is invalid.
Verifying the availability of the Query Library queries

The Inventory database schema installation process also installs the predefined queries that comprise the Query Library. You can use these queries as is, or you can use them as templates for creating custom queries. When you finish installing a schema module, verify that the predefined queries are available in the Report Center module.
100
Configuring the inventory and logging plug-ins
Before you begin

Verify that the Report Center module is available as an application in the CMS console. If it is not available, subscribe to Report Center in the CMS tuner.
To verify the Query Library availability 1 From the CMS console, choose Applications => Report Center. 2 From the Query View page, select the Query Library folder to view the query
folders that correspond to your schema modules.
3 Expand the top-level Queries folder to view the following (empty) folders that
were added to the Queries folder:
s s s s s s s
BMC CM Administrative Groups Collections Deployment Manager Custom Query Deployment Manager Groups OS Management Patch Management (if you purchased the Patch Management module) Policy Compliance
You can create queries in these folders and then use the queries in other BMC BladeLogic Client Automation applications. For more information about queries, see the BMC BladeLogic Client Automation Report Center Guide.
TIP
If you do not see these folders or the Query Library folder, use Schema Manager to reinstall the Query Library. In this case, repeat the procedure in Using the Custom install option to install the database schema modules and query libraries on page 97, but clear the check box for Schema on the Custom Reinstall page. Select only Applications => Report Center => Query Library.
Configuring the inventory and logging plugins

To configure the inventory and logging plug-ins, you must publish the configuration settings to the Scanner Service channel and the Logging Service channel on your master transmitter. You must complete this task before you can deploy the Scanner Service and Logging Service channels to the endpoints to ensure that they have the correct schedule settings.
Chapter 7
101
Configuring user and group access to the console
The following steps list the required basic inventory and logging configuration tasks. The instructions for performing these tasks are provided in both the Report Center help and the BMC BladeLogic Client Automation Report Center Guide. 1. Select a database. For the inventory plug-in and the logging plug-in, specify the database that receives data from the plug-in (most likely, the database that you configured in Installing the Inventory database schema modules and query libraries on page 92). Configure this setting for the inventory plug-in and then again for the logging plug-in. Each plug-in has its own configuration settings. 2. Enable inventory scans and log collection. Before you can collect data, you must configure inventory scanning and log collection on the endpoints. For instructions, see the chapter about configuring endpoints, in the BMC BladeLogic Client Automation Report Center Guide. Configure these settings for the inventory plug-in and the logging plug-in. Report Center provides many options for configuring scanning and logging. Although defaults are provided, review the options and change them as needed.

Initially, you log in to the CMS console as the admin user. BMC recommends that you change the default password for this user and add additional users and groups, either by using the CMS console local user database or by setting the console to use a directory service for authentication. When you add users and groups, you specify their roles. Some roles have more administrative privileges than other roles. For more information about roles, see the following documentation:
s
For an overview of roles and their privileges, see the BMC BladeLogic Client Automation CMS and Tuner Guide. For details about the tasks that each role can perform in Report Center, see the introduction in the BMC BladeLogic Client Automation Report Center Guide. For instructions about configuring the console to use a directory service for user authentication, see the section about adding a directory service in the BMC BladeLogic Client Automation CMS and Tuner Guide.
102
For instructions about adding users and groups so that they can access the console, see the chapter about user authentication in the BMC BladeLogic Client Automation CMS and Tuner Guide.
Chapter 7
103
104
Chapter
Setting up the Infrastructure Status Monitor

8
This chapter describes how to use Schema Manager to install the Infrastructure Status Monitor module, and presents the following topics: Installation guidelines for the Infrastructure Status Monitor schema . . . . . . . . . . . . 106 Installing the Infrastructure Status Monitor database schema . . . . . . . . . . . . . . . . . . 106
Overview of the Infrastructure Status Monitor

The Infrastructure Status Monitor provides health-related metrics about your BMC BladeLogic Client Automation infrastructure. It provides an overall, health-at-aglance view of your infrastructure components and provides detailed monitoring views of Master transmitters, Repeaters, Mirrors, and Proxies. Using the Infrastructure Status Monitor, you can monitor your environment to ensure that your BMC BladeLogic Client Automation infrastructure is running properly and to diagnose any issues that arise. For complete details about this feature, see the Infrastructure Status Monitor and the BMC BladeLogic Client Automation CMS and Tuner Guide.
Chapter 8
105
Installation guidelines for the Infrastructure Status Monitor schema

The Schema Manager module enables you to install the database schema for the Infrastructure Status Monitor and other modules. Although Schema Manager gives you several options for installing a database schema (Easy, Custom, and Manual), BMC Software recommends that you use the Custom installation option for the following conditions:
s
to change the passwords for the Infrastructure Status Monitor admin and user (recommended) to install the schema or the Query Library but not both at the same time to modify the default database size parameters to use a location other than the default (on the C drive) for your Microsoft SQL Server database
Installing the Infrastructure Status Monitor database schema

If you used the BMC BladeLogic Client Automation installation program to install the Infrastructure Status Monitor database schema, you can skip this section and refer to the BMC BladeLogic Client Automation CMS and Tuner Guide for more information about configuring this module. If you did not use the installation program to install the Inventory database, you must use Schema Manager to install it on the. The Infrastructure Status Monitor and Inventory schemas must reside on the same computer.
NOTE
If you prefer to install the schema by running scripts at the command line, see Appendix C, Manual database schema installation and updates. You may want manually install the schema if you
s s s
do not have access to the CMS console want to verify the database installation information want to override default values
106
Before you begin

s
Ensure that the Inventory database schema has been installed, as described in Installing the Inventory database schema modules and query libraries on page 100. If necessary, log in to the CMS console, as described in Logging in to the CMS console on page 87.
To use the Custom option to install the Infrastructure Status Monitor database schema 1 To access Schema Manager, choose Applications => Console => Schema Manager. 2 Connect to the Infrastructure Status Monitor database: A On the Welcome to Schema Manager page, click Infrastructure Status Monitor
Database.
B On the Database page, select an option from Database type. C Provide the host name, port number, and the database system ID (Oracle) or the
database name (SQL Server). For Oracle RAC, provide the net service name and select Use Net Service Name. The database administrator (DBA) can provide you with these values.
s
The default port numbers are 1521 (Oracle) and 1433 (SQL Server). For SQL Server, the database name is invdb, unless you edited all the necessary database setup scripts to change this value (not recommended).
D Type the system administrator user name and password. TIP

Often, the Oracle system administrator user name is system and the default password is manager; on SQL Server, the user name is often sa, and the default password is no password. However, you should verify these authentication credentials with your DBA.
E Type the password for the Infrastructure Status Monitor admin, which is
hmadmin by default.
F Type the password for the Infrastructure Status Monitor user, which is hmuser
by default.
G Click Connect.
Chapter 8
107
3 From the Infrastructure Status Monitor Database Schema page, select the
Infrastructure Status Monitor Schema Modules tab.
4 Under Action, click Install. 5 On the Installation Options page, select Custom Install, review the current settings,
and modify the setting as necessary, and click Install: Processing messages are displayed. Several error messages might be generated when the script drops tables that may not exist. You can ignore these messages. When the operation is finished, an Installation Complete page is displayed.

You must configure the Infrastructure Status Monitor. For detailed information about how to configure the Infrastructure Status Monitor, see the BMC BladeLogic Client Automation CMS and Tuner Guide.
108
Chapter

9
This chapter describes how to use Schema Manager to install the Infrastructure Status Monitor module, and presents the following topics: Installation guidelines for the Infrastructure Status Monitor schema . . . . . . . . . . . . 110 Installing the Infrastructure Status Monitor database schema . . . . . . . . . . . . . . . . . . 110
Overview of the Infrastructure Status Monitor

The Infrastructure Status Monitor provides health-related metrics about your BMC BladeLogic Client Automation infrastructure. It provides an overall, health-at-aglance view of your infrastructure components and provides detailed monitoring views of Master transmitters, Repeaters, Mirrors, and Proxies. Using the Infrastructure Status Monitor, you can monitor your environment to ensure that your BMC BladeLogic Client Automation infrastructure is running properly and to diagnose any issues that arise. For complete details about this feature, see the Infrastructure Status Monitor and the BMC BladeLogic Client Automation CMS and Tuner Guide.
Chapter 9
109

The Schema Manager module enables you to install the database schema for the Infrastructure Status Monitor and other modules. Although Schema Manager gives you several options for installing a database schema (Easy, Custom, and Manual), BMC Software recommends that you use the Custom installation option for the following conditions:
s
to change the passwords for the Infrastructure Status Monitor admin and user (recommended) to install the schema or the Query Library but not both at the same time to modify the default database size parameters to use a location other than the default (on the C drive) for your Microsoft SQL Server database

If you used the BMC BladeLogic Client Automation installation program to install the Infrastructure Status Monitor database schema, you can skip this section and refer to the BMC BladeLogic Client Automation CMS and Tuner Guide for more information about configuring this module. If you did not use the installation program to install the Inventory database, you must use Schema Manager to install it on the. The Infrastructure Status Monitor and Inventory schemas must reside on the same computer.
NOTE
If you prefer to install the schema by running scripts at the command line, see Appendix C, Manual database schema installation and updates. You may want manually install the schema if you
s s s
do not have access to the CMS console want to verify the database installation information want to override default values
110
Before you begin

s
Ensure that the Inventory database schema has been installed, as described in Installing the Inventory database schema modules and query libraries on page 100. If necessary, log in to the CMS console, as described in Logging in to the CMS console on page 87.
To use the Custom option to install the Infrastructure Status Monitor database schema 1 To access Schema Manager, choose Applications => Console => Schema Manager. 2 Connect to the Infrastructure Status Monitor database: A On the Welcome to Schema Manager page, click Infrastructure Status Monitor
Database.
B On the Database page, select an option from Database type. C Provide the host name, port number, and the database system ID (Oracle) or the
database name (SQL Server). For Oracle RAC, provide the net service name and select Use Net Service Name. The database administrator (DBA) can provide you with these values.
s
The default port numbers are 1521 (Oracle) and 1433 (SQL Server). For SQL Server, the database name is invdb, unless you edited all the necessary database setup scripts to change this value (not recommended).
D Type the system administrator user name and password. TIP

Often, the Oracle system administrator user name is system and the default password is manager; on SQL Server, the user name is often sa, and the default password is no password. However, you should verify these authentication credentials with your DBA.
E Type the password for the Infrastructure Status Monitor admin, which is
hmadmin by default.
F Type the password for the Infrastructure Status Monitor user, which is hmuser
by default.
G Click Connect.
Chapter 9
111
3 From the Infrastructure Status Monitor Database Schema page, select the
Infrastructure Status Monitor Schema Modules tab.
4 Under Action, click Install. 5 On the Installation Options page, select Custom Install, review the current settings,
and modify the setting as necessary, and click Install: Processing messages are displayed. Several error messages might be generated when the script drops tables that may not exist. You can ignore these messages. When the operation is finished, an Installation Complete page is displayed.

You must configure the Infrastructure Status Monitor. For detailed information about how to configure the Infrastructure Status Monitor, see the BMC BladeLogic Client Automation CMS and Tuner Guide.
112
Chapter
10
114 114 114 114 114 115 115 115 116 116 118 118 122 126 128 130 132 133 133
10
Setting up Policy Management

This chapter describes how to install BMC BladeLogic Client Automation Policy Management for the first time. If you are upgrading from an earlier version of Policy Management, see Part 4, Upgrade, which begins on page 195. Overview of Policy Management components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directory service schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy Service plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integration with a database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of the Policy Management installation process. . . . . . . . . . . . . . . . . . . . . . Prerequisites for installing Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing the directory service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites for Active Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites for Sun Java System Directory Server. . . . . . . . . . . . . . . . . . . . . . . . Prerequisites for ADAM / AD LDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connecting to the directory service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the directory service schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directory service schema options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up Sun Java System Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Policy Manager and the Policy Service plug-in . . . . . . . . . . . . . . . . . . . Whats next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 10
113
Overview of Policy Management components
Overview of Policy Management components

This section describes the components that comprise BMC Policy Management. For more information about Policy Management, see the BMC BladeLogic Client Automation Policy Management Guide.
Policy Manager
Policy Manager provides a browser interface for creating policies that control which applications get installed and updated on endpoints. You access Policy Manager through the CMS console. If you followed the instructions in Chapter 6, How to install the basic components, you installed Policy Manager when you installed and set up the CMS console.
Directory service schema

The directory service schema enables Policy Manager to use the directory service for browsing target endpoints, storing configuration information, and storing policies. You use Schema Manager to install the directory service schema and run an LDIF script to extend the schema of your directory service, so that it can be used with Policy Manager.
Policy Service
Policy Service is the client-side component (endpoint) of Policy Management and is responsible for applying the policy for each endpoint. Policy Service is implemented as a channel and receives updates from the Policy plug-in that resides on the transmitter.
Policy Service plug-in

The Policy Service plug-in is the server-side component (transmitter) of the Policy Service channel and determines the target groups to which an endpoint belongs. This configuration is described in Configuring Policy Manager and the Policy Service plug-in on page 133.
114
Integration with a database
Integration with a database

If you plan to use Report Center or policy compliance and immediate policy update features, you must use the CMS console System Settings option to configure access to the database, as described in Connecting to the directory service on page 122.
Overview of the Policy Management installation process

Installing Policy Management consists of the following tasks:
s s s s s
Prerequisites (page 115) Preparing the directory service (page 77) Prerequisites for Active Directory (page 116) Prerequisites for Sun Java System Directory Server (page 118) Prerequisites for ADAM /AD LDS (page 118)
If you are using Active Directory as your directory service and there are multiple domains in the environment in which you are installing Policy Management, you need to decide which domain to use to store policies. You can choose any domain to store policies. Consider the following criteria:
s
You should give all Policy Management administrators who store policies write access to this domain. This domain will have additional Policy Manager data stored in it.
Prerequisites for installing Policy Management

Before you can perform the tasks described in this chapter, perform the following actions:
s
Download your BMC BladeLogic Client Automation products and set up your master transmitter and CMS console. Read the Policy Management section of the release notes before beginning the installation process.
You can access the product download page and the release notes from the BMC Customer Support web site.
Chapter 10
115
Preparing the directory service
Preparing the directory service

The BMC Policy Management system uses a directory service for browsing target endpoints, storing configuration information, and storing policies. If you have not done so, install one of the following directory services:
s s
Microsoft Active Directory Microsoft Active Directory Application Mode (ADAM) / Active Directory Lightweight Directory Services (AD LDS) Sun Java System Directory Server
For information about which versions of these directory services are supported, see the BMC BladeLogic Client Automation Release Notes document, available on the BMC Customer Support web site. Vendor-specific instructions for installing the directory services are provided with the product and are not presented in this document. After installing and connecting to the directory service, you use Schema Manager to generate and run LDIF scripts that configure the directory service so that it can be used with Policy Management components. This chapter provides instructions for installing the schema in the directory service for the first time. Instructions for updating the schema from previous versions are provided in Part 4, Upgrade.
Prerequisites for Active Directory

Before using Schema Manager to install the schema, ensure that Active Directory adheres to the following guidelines:
s
A supported directory service is installed and configured correctly. To use Active Directory with the BMC BladeLogic Client Automation product, you must have one of the supported versions of Active Directory installed, configured, and running. For a list of the supported versions, see the BMC BladeLogic Client Automation Release Notes document. If using automatic discovery, verify that the machine hosting the CMS console can access the machine hosting Active Directory. To work with Active Directory, Policy Manager and the Policy Service plug-in automatically discover Active Directory components, such as the Global Catalog and the domain controller. BMC BladeLogic Client Automation applications use the service records (SRV) in the DNS server to discover the domain.
116
Prerequisites for Active Directory
NOTE
When using Active Directory with multiple domains, you must use automatic discovery.
If managing machines not in the Active Directory domain, verify that the required tuner properties are set. For machines that are not in the Active Directory domain, ensure that BMC BladeLogic Client Automation products can discover the domain and automatically discover the Global Catalog and domain controller. For the domain auto-discovery feature of BMC BladeLogic Client Automation applications to work for machines outside the Active Directory domain, you must set the marimba.ldap.admanagementdomain tuner property to the domain name you want that machine to use. Set this tuner property on the machines that host Policy Manager, Common Management Services (CMS), and Report Center before using the CMS console System Settings option to configure the data source, as described in Connecting to the directory service on page 122. If you set the property after you have configured the directory service settings, you must save the directory service settings again by going to the Directory Services page and clicking OK, even if you did not changed anything on that page. If you cannot change the resolve.conf file, you can use another tuner property, marimba.ldap.srvdnsserver, to specify a comma-separated list of DNS servers that can be used to look up the SRV records. However, machines running the plug-in and the Policy Manager must be able to resolve the host name of the returned domain controllers and Global Catalogs.
Troubleshooting notes. If none of the DNS servers returns an SRV record that meets the query conditions, the error.ldapconn.norecords error is displayed. This error also prints out the query and the DNS servers queried. If the Global Catalog was found, but the host name could not be resolved, then an unknown host error is displayed. Also, set the marimba.ldap.admanagementdomain tuner property for machines that are not part of an Active Directory domain. This step enables BMC BladeLogic Client Automation products to discover the domain and automatically discover the Global Catalog and domain controller. Set this property for the following machines: The machines that host the transmitter (including repeaters) and the Policy Service plug-in The endpoint machines that run Policy Service If you do not set the property on these endpoints, the Policy Service plug-in can have problems sending machine-based policies to these endpoints.
Chapter 10
117
Prerequisites for Sun Java System Directory Server
NOTE
Do not set a value for the tuner property marimba.ldap.admanagementdomain on Windows endpoints within an Active Directory domain. If you do, the tuner does not send user or machine distinguished names to the Policy Service plug-in.
When running Policy Management on UNIX machines, ensure they are in the DNS server list. In addition to setting the property mentioned above, ensure the UNIX machines have the Active Directory DNS server in the DNS server list (which can be found in /etc/resolv.conf).
TIP
Use a space instead of a tab when you enter the DNS server into the /etc/resolv.conf file, such as nameServer<space>ipAddress.
For more information about using Active Directory with Policy Management, see the Active Directory and ADAM / AD LDS integration section in the BMC BladeLogic Client Automation Policy Management Guide.
Prerequisites for Sun Java System Directory Server

Before using Schema Manager to install the schema, ensure that the Sun Java System Directory Server adheres to the following guidelines: Verify the supported directory service is installed and configured correctly. To use Sun Java System Directory Server with BMC BladeLogic Client Automation modules, you must have one of the supported versions of Sun Java System Directory Server installed, configured, and running. For a list of the supported versions, see the BMC BladeLogic Client Automation Release Notes document.
Prerequisites for ADAM / AD LDS

Active Directory Application Mode (ADAM) / AD LDS is a directory service that runs as a user service, rather than as a system service. Because ADAM / AD LDS runs as a non-operating system service, it does not require deployment on a domain controller. Running as a non-operating system service means that multiple instances of ADAM / AD LDS can run concurrently on a single server, with each instance being independently configurable.
118
You can use ADAM / AD LDS with Policy Manager if you need a flexible, standalone directory service but do not want the network infrastructure requirements of Active Directory. If you use ADAM/ AD LDS because you do not want to incorporate Policy Management into the enterprise Active Directory schema, then you must copy and synchronize all machine and user information for targeting policies from the enterprise Active Directory to ADAM / AD LDS regularly. You can copy and synchronize information by using tools made available by Microsoft. Before using Schema Manager to install the schema, ensure that ADAM / AD LDS adheres to the following guidelines: Verify a supported directory service is installed and configured correctly. To use ADAM / AD LDS with BMC BladeLogic Client Automation products, you must have one of the supported versions of ADAM / AD LDS installed, configured, and running:
s
For a list of the supported versions, see the BMC BladeLogic Client Automation Release Notes document. Follow the instructions provided by Microsoft to install ADAM. The ADAM download from Microsoft includes step-by-step instructions for installing ADAM. If you download ADAM from the Microsoft web site, ensure that you obtain the retail version. If you are installing and configuring AD LDS (ADAM) in Windows 2008 with Identity Manager, then perform the following steps before you start the Set Up Wizard. Step 1: To add the AD LDS server role
1 Install AD LDS Server Role. 2 Click Start, and click Server Manager. 3 In the console tree, right-click Roles, and click Add Roles. 4 Review the information on the Before You Begin page of the Add Roles Wizard,
and click Next.
5 On the Select Server Roles page, in the Roles list, select the Active Directory
Lightweight Directory Services check box.
6 Click Next. 7 Follow the instructions in the wizard to add the AD LDS server role.
Step 2: To create a new AD LDS instance in windows 2008
Chapter 10
119
1 Click Start, and choose Administrative Tools => Active Directory Lightweight
Directory Services Setup Wizard.
2 On the Welcome to the Active Directory Lightweight Directory Services Setup

Wizard page, click Next.
s
Select the following options when you run the ADAM / AD LDS Setup Wizard either using ADAM downloaded from the Microsoft web site for windows 2003 or using AD LDS for windows 2008: Setup Options page: Select A unique instance. This option automatically creates a new instance of ADAM that uses the default configuration and schema partitions. Instance Name page: Specify a name for the new instance that reflects the fact that you are using it for BMC Policy Management.
Application Directory Partition page: Select Yes, create an application directory partition and specify a distinguished name for the partition that you want to use for Policy Management, such as dc=company,dc=com. Service Account Selection page: Unless you are installing ADAM on a domain controller, select Network service account. ADAM Administrators page: Select Currently logged on user so that the user installing ADAM has administrative permissions for this ADAM instance. Importing LDIF Files page: Choose Import the selected LDIF files for this instance of ADAM and add the following LDIF files:
MS-AZMan.LDF MS-InetOrgPerson.LDF MS-User.LDF MS-UserProxy.LDF
NOTE
The LDIF script, that you use later as part of installation, extends the MS-User object, which is included in the MS-User.LDF file. Failure to import this object will cause errors when running the LDIF script.
120
If you are installing ADAM /AD LDS on Windows XP Professional Edition and you are planning to use SSL, ensure you download all the required hotfixes. When you download, you need to take one of the following two approaches: Connect using SSL. Disable the SSL requirement that you connect using SSL. To do this you must modify the dSHeuristics property (using ADSI Edit, for example) of the object cn=Directory Service, cn=Windows NT, cn=Services, cn=Configuration, dc=X. The attributes should not have a value set. Set its value to 0000000001001 (with nine leading 0s before the first 1). Ensure the user name that you use for the bind DN has the Administrators role. When you use the ADAM ADSI Edit application to add users and groups to ADAM /AD LDS, you need to add at least one user with the Administrators role that you can use as the bind distinguished name (bind DN) when connecting to ADAM / AD LDS from CMS and Policy Management.
NOTE
The Administrators role in ADAM /AD LDS is different from the Administrators role you need to specify in the System Settings option of the CMS console for Policy Management. See Connecting to the directory service on page 122, for details on how to set the Administrators role for Policy Manager.
Ensure the that passwords you set for users meet the restrictions required by the domain. The domain where ADAM /AD LDS is running might have certain password restrictions that the current password does not meet. For example, on Windows 2003 Server, the complex password restrictionpasswords must include six or more characters and at least one punctuation symbolis enabled by default. If the password being used is not valid (that is, it does not meet the restriction), then the user account you create is disabled. Use one of the following options to solve this problem:
s s
Take the machine off the domain and set msDS-UserAccountDisabled to false. Reset the password to a valid password and reset the msDS-UserAccountDisabled to false.
NOTE
You must reset the msDS-UserAccountDisabled attribute to false. Removing the machine from the domain does not solve the problem.
Ensure that users have the appropriate read and write permissions. Users need read and write permissions for the directory service to log in to the CMS console and use Policy Manager. You can verify that users have appropriate read and write permissions for the directory service by using the dsacls program, such as:
C:\WINDOWS\ADAM>dsacls \\localhost:389\cn=BMCUser,DC=company,DC=com Chapter 10 Setting up Policy Management 121
Connecting to the directory service
If the user does not have read and write permissions for the directory service, use the dsacls command, an ADAM /AD LDS specific command, to grant them. For more information, see the command-line help (dsacls -help) or the Microsoft support website.

After you have installed a directory service, you can use the CMS console System Settings option to connect to the directory service. Then, you can use the directory service for user authentication and for Policy Manager.
NOTE
If the directory service does not contain the corporate user and group database, you can configure Policy Manager to obtain user and user group targets from a source other than the directory service. See the chapter on obtaining user and group information from a transmitter in the BMC BladeLogic Client Automation Policy Management Guide.
To create a data source and add a directory service 1 Open a browser window and log in to the CMS console: A Use the following URL: http://machineName:8888
s s
machineName is the name of the machine on which the console is installed. Use the port number 8888, unless you did a custom installation and changed the console HTTP port.
B Enter the user name admin and leave Password blank, and click Log In. 2 In the upper-right corner of the console, choose Applications => Console => System
Settings.
3 From the General Settings page, click the Data Source tab and then click the
Directory Service link.
4 From the Directory Services page, click Add a Directory Service and complete the
Add Directory Service page that is displayed:
122
A Enter an appropriate directory service name and description. NOTE

For backward-compatibility reasons, you cannot use local or ldap for the name of the directory service.
B Select the type of directory service to use. C If you choose Active Directory, BMC Software recommends that you select the
Auto-discover check box. For more information, see the section on when to use automatic discovery for Active Directory in the BMC BladeLogic Client Automation Policy Management Guide.
CMS automatically discovers the Active Directory domain, site, Global Catalog, and domain controller (DC). CMS uses the SRV records in the DNS server to discover the domain. It connects to a domain controller in the domain with the lowest load. For Active Directory, only the bind DN and the bind DN password are required. Ensure the bind DN is that of a user with read-write permissions in the directory service.
D Supply the host name and port number, such as Directory_Service:389 or

176.16.2.162:389. Only Sun Java System Directory Server and ADAM /AD LDS require this information.
The directory service administrator can provide you with these values.
E Supply the base distinguished name (DN) for the directory service connection,
which is usually equivalent to the directory suffix, such as:
s
Active Directory or Active Directory Application Mode (ADAM) dc=company,dc=com Sun Java System Directory Server dc=company,dc=com
F Supply the bind distinguished name and password for a user with read and
write permissions in the directory service.
s
For Active Directory or ADAM /AD LDS, use the following formats: The full distinguished name, such as: cn=Administrator,cn=Users,dc=company,dc=com
Chapter 10
123
The common name (if it is unique), such as: Administrator (Active Directory only) The user principal name (UPN), such as: Administrator@company.com
NOTE
To use the built-in administrator account created by Active Directory using the user principal name (UPN) format, such as administrator@company.com, you must set up the UPN attribute for the administrator account using the Microsoft Management Console (MMC). By default, no UPN attribute is assigned to the administrator account. If the UPN attribute cannot be found for an account, the user cannot log in. This scenario is true even when an account with the same user name has been set up with a UPN attribute in one domain but not another, such as when administrator@root1.com has been given a UPN attribute, while administrator@east.root1.com has not.
For Sun Java System Directory Server, use the following formats: The full distinguished name, such as:
uid=Administrator,ou=People,dc=company,dc=com
The common name for the directory administrator, such as: cn=Directory
Manager
s
Select Use this directory service to authenticate users.
5 After completing the Directory Services page, click OK to save your configuration. 6 When Policy Manager warns you that the configuration used for authenticating
users has been changed and that you need to log out before proceeding, click Change the user roles before logging out.
7 On the User Roles page, enter the names of the groups to whom you want to assign
the different roles. At a minimum, you must set up two user groups. One user group is assigned the primary administrator role and the other is assigned the administrator role. Any user listed in the directory service who belongs to the primary administrator group or administrator group can browse to Policy Manager and use it. By carefully setting permissions for these users, you can control the area of access and responsibility for each administrator.
NOTE
Users with the operator role do not have access to Policy Manager.
124
User roles control the access of administrators to certain pages in the browser interface. For Policy Manager, you must belong to the group that has the administrator role to log in. Members of a group given the primary administrator role can also configure Policy Manager. (For more information, see the chapter on permissions and security issues in the BMC BladeLogic Client Automation Policy Management Guide.) The views of targets and policies that you and other administrators see when logging in to Policy Manager and the ability to assign targets to a policy are controlled by the permissions granted in the directory service. For Active Directory, a user may be in any type of group. If the user to whom you want to assign primary administrator permissions is not in a group, you can create a Global Security group and assign the user as a member. For Sun Java System Directory Server, you might want to add the common name cn=Directory Manager to the group that contains primary administrators. The best time to set these permissions is during installation, before you give access to more than one administrator. (For more information, see the chapter on permissions and security issues in the BMC BladeLogic Client Automation Policy Management Guide.) Use this information as a guide for setting up your groups and permissions in the directory service.
8 After you have assigned roles, click OK to save your changes. 9 When Policy Manager warns you that the configuration used for authenticating
users has been changed and that you need to log out before proceeding, click Log
out without changing directory service settings.
You have added the directory service and selected it for user authentication. The next time you log in, you can use the name and password of a user in the directory service, as long as the user is a member of one of the groups you specified in the User Roles page.
NOTE
If you have problems logging in as a user from the directory service, ensure that Common Management Services (CMS console) is using the directory service for user authentication:
10 Log in as admin: A Enter the user name admin and leaving Password blank. B Click Log In. 11 From the General Settings page, click the User Authentication tab and then click the
User Authentication Type link.
Chapter 10
125
Installing the directory service schema
12 Choose Directory service and select the directory service to use, and click OK. 13 Log out and log in again.

The directory service schema enables Policy Manager to use the directory service for browsing target endpoints, storing configuration information, and storing policies. To install the directory service schema for BMC Policy Management, you use the Schema Manager.
NOTE
For detailed information about how Policy Manager integrates with the various directory services, see the BMC BladeLogic Client Automation Policy Management Guide.
Before you begin

s s
You must have completed the activities described in Part 2, Installation. You must be logged in to the CMS console.
To install the directory service schema 1 Choose Applications => Console => Schema Manager. 2 On the Welcome to Schema Manager page, click Directory Service. 3 On the Choose a Directory Service page, select a directory service from the list, and
click Connect.
4 If the directory service that you want to connect to is not listed, add the directory
service to the console; otherwise, skip to step 5:
A On the Choose a Directory Service page, click Add a Directory Service. B Add a directory service.
For instructions on adding a directory service, see Adding or editing a directory service in the BMC BladeLogic Client Automation CMS and Tuner Guide or the online Help.
5 On the Schema Modules tab, for the item called Policy Manager, click Install.
126
6 On the Installation Options page, specify the options to use when generating the
LDIF scripts, and click Install. If you need assistance filling in this information, see Directory service schema on page 114. You can also place your mouse pointer over the hyperlinked field names to display the rollover text that shows recommended default values.
7 On the Download LDIF Scripts page, click the link to download the .zip file that
contains the LDIF scripts you need to run. Save the .zip file before opening it. The .zip file contains two types of files:
s
an LDIF script that contains the schema changes and commands for creating containers for Policy Management a batch file (.bat) for running the LDIF script When you run the batch file on Active Directory, provide the password for the user that has schema administrator rights and who generated the LDIF Script. For example, at the command prompt, type:
install_ad.bat password
Ensure you can log in to the directory service with the user name and password that you use.
8 On the machine that hosts the directory service, use the batch file to run the LDIF
script and install the directory service schema. The LDIF script changes your directory service schema so that it can be used with Policy Management. If you are using distributed Active Directory, updates to the schema result in directory service replication traffic across your network. Because the traffic can be significant, run the scripts during an off-peak time. You might want to print or view the script for reference. The script contains comments that describe how to run the script.
NOTE
When you run LDIF scripts on ADAM, you must download the contents of the .zip file into the ADAM install directory (the default is C:\Windows\ADAM). Otherwise, the following error is displayed when you run the LDIF scripts: Add error on line 35:Invalid DN Syntax. This error appears if the script is not in the default ADAM directory or is not using the default ADAM ldifde.
Chapter 10
127
Directory service schema options

Using Schema Manager, you can review the default values and make changes to the following options when generating the LDIF schema scripts:
s
Schema base DN. For Active Directory only, this value specifies the location for creating schema attributes and classes. By default, Schema Manager generates a single script that defines both the schema and the additional containers and default information that are required by Policy Manager. For Sun Java System Directory Server and ADAM /AD LDS, this default is the required configuration, so you only need to specify the schema base DN. This DN is used for both installing the schema and creating the containers. For Active Directory multidomain environments in which the schema master is in a domain different from the one where Policy Management runs, two scripts are needed: one for the schema definitions, and one to create the default containers specific to Policy Management. You can generate separate scripts for installing the schema and creating the containers by specifying both the schema base DN and the base DN on the Installation Options page.
You also need to change the fields described in Table 1 on page 128 so that the DNs match the base DN that you specified.
Table 1
Option
Other directory service schema options (part 1 of 3)

Description an additional LDIF script and batch file is generated for creating a Subscriptions container for the top-level domain It is used for storing policies assigned to the top-level domain. For example, if the top-level domain is company.com, then the LDIF script cn=company.com.ldif and the corresponding batch file install_ad_container_cn_company.com.bat are generated.
Note for Active Directory
Base DN
for Active Directory only, to specify a different location for installing the schema (see schema base DN) and Policy Management entries, this is the base distinguished name (DN) or suffix (for example, dc=company,dc=com) for creating the Policy Management directory service entries The base DN is the location in the directory service where entries needed for Policy Management configuration are stored and retrieved. These entries include the Subscription configuration object (cn=Subscription Config, ou=ConfigObjects, ou=BMC CM, ou=BMC Software, <base_dn>), attributes (ou=Subscriptions, ou=ConfigObjects, ou=BMC CM, ou=BMC Software, <base_dn>), and searches for targets (ou=People, <base_dn>)
128
Table 1
Option

Description option to obtain users from the source that the transmitter is using for user access and authentication The default value is false. To source users from a transmitter, see the section on obtaining user and group information from a transmitter in the BMC BladeLogic Client Automation Policy Management Guide.
Source users from a transmitter
Subscription config base DN
location of the Subscription configuration object This object stores configuration information for Policy Manager. The default value is ou=Subscription Config,ou=ConfigObjects,ou=BMC CM,ou=BMC Software,dc=company,dc=com.
Subscription base DN
location where Policy Manager stores policies The default value is ou=Subscriptions,ou=ConfigObjects,ou=BMC CM,ou=BMC Software,dc=company,dc=com.
Collections base DN
location where Report Center stores any collections that you want to use with Policy Manager The default value is ou=Collections,ou=BMC CM,ou=BMC Software,dc=company,dc=com.
LDAP query collections base DN
location for storing any LDAP query collections that you want to use with Policy Manager The default value is ou=LDAPCollections,ou=BMC CM,ou=BMC Software,dc=company,dc=com.
Machine import base DN
location where machines and machine groups are stored if you import them from a machines.txt file using Policy Manager The default value is cn=Computers,dc=company,dc=com in Active Directory or ADAM /AD LDS, and ou=Machines,dc=company,dc=com in Sun ONE.
Require entries in the directory service
option to apply policies to endpoints that have entries in the directory service only (even if the policy is assigned to all endpoints) The default value is false.
Hidden entries
list of containers that you do not want to display in Policy Manager You can specify a comma-separated list of DNs, with each DN enclosed by double quotation marks, such as ou=Subscriptions, ou=ConfigObjects,ou=BMC CM,ou=BMC Software,dc=company,dc=com, ou=Acl,ou=ConfigObjects,ou=BMC CM,ou=BMC Software,dc=company, dc=com, dc=company,dc=com. You can only hide OUs, CNs, and DCs. By default, Policy Manager hides the Subscriptions, Acl, and BMC BladeLogic Client Automation containers in the previous example.
Chapter 10
129
Setting up Active Directory
Table 1
Option

Description location where access control lists (ACLs) are stored The default value is ou=Acl,ou=ConfigObjects,ou=BMC CM,ou=BMC Software,dc=company,dc=com.
ACL base DN
Centralized collections mode
option to use centralized mode for collections For ADAM /AD LDS, iPlanet, and Sun Java System Directory Server, centralized mode is the only mode available, so this check box is automatically selected. For Active Directory, distributed mode is available and you can choose it by clearing the check box. By default, this check box is selected.
NOTE
Oracle installs an incompatible version of ldapmodify and adds it to your PATH environment variable. If you use Sun Java System Directory Server, do not use the Oracle version of ldapmodify.
Generally, if the script fails the user who is running it does not have permission to make changes in the directory service. If this problem occurs, log in with a user account that has the necessary permissions, and run the script again. Next, follow these instructions depending on the directory service you are using:
s s
Setting up Active Directory on page 130 Setting up Sun Java System Directory Server on page 132

This section contains procedures that you must complete to set up Active Directory for Policy Management.
NOTE
If you are using ADAM /AD LDS, you do not need to perform these procedures.
Verifying your DNS configuration

Before running the LDIF script, ensure that the Domain Name System (DNS) is configured to point to the Active Directory that you are using with Policy Manager. Otherwise, Policy Manager cannot start.
130 BMC BladeLogic Client Automation Installation Guide
To verify DNS configuration 1 Go to Network and Dial-up Connections. 2 Right-click the network connection you are using and choose Properties. 3 Select Internet Protocol (TCP/IP) and click Properties. 4 For the preferred DNS server, verify the first DNS server points to the IP address
for Active Directory.
Generating and running an LDIF script to create collections containers

If you use Active Directory and use collections in a multidomain forest environment, and you want to run distributed mode, you must generate and then run an LDIF script to create Collections containers in each domain where Report Center runs. For more information, see the collections chapter of the BMC BladeLogic Client Automation Report Center Guide.
s
In distributed mode, you have one Report Center installed per Active Directory domain and you want to restrict administrators within a given domain so that they manage only collections within their local domain. You use the Install collections option in Schema Manager to generate a script that creates a Collections container in the directory service for each domain where you want to use collections. The LDIF script that you generate, as described in this section, creates Collections containers for each domain where you need collections. For more information about collections, see the chapter on Collections: Querybased groups of users and machines in the BMC BladeLogic Client Automation Policy Management Guide.
Before you begin

Ensure that the Domain Name System (DNS) is configured to point to the Active Directory that you are using with Policy Manager, as described in To verify DNS configuration on page 131.
To create collections containers for each of your domains 1 On the Welcome to Schema Manager page, click Directory Service. 2 On the Choose a Directory Service page, select a directory service from the list and
click Connect.
Chapter 10
131
Setting up Sun Java System Directory Server
3 On the Directory Service Schemas page, click the System Maintenance tab. 4 From the Action list, choose Install collections and enter the base DN and collections
base DN.
5 Click Perform Action. 6 On the Download LDIF Scripts page that appears, click the link to download the
.zip file containing the LDIF scripts.
The file contains two types of files:

s
An LDIF script that contains the commands for creating containers for Policy Management. A batch file (.bat) for running the LDIF script.
7 On the machine where the directory service is installed, use the batch file to run the
LDIF script and perform the action on the directory service. You might want to print out or view the script for reference. There are comments in the script file providing instructions for running the script.
NOTE
Ensure the Subscription configuration object and the BMC CM Config object are replicated to the Global Catalog before you start using Policy Manager.
Setting up Sun Java System Directory Server

This section contains procedures that you must complete to set up Sun Java System Directory Server for Policy Management.
Setting virtual list view

For Sun Java System Directory Server, you must enable Virtual List View (VLV) to allow directory service browsing from within Policy Manager.
NOTE
Enabling VLV increases memory usage and degrades server performance if insufficient memory is allocated for the directory service. Adjust your system configuration according to your performance needs.
132
Configuring Policy Manager and the Policy Service plug-in
To set the look-through limit for Sun Java System Directory Server 5.2 1 Log in to Sun Java System Directory Server. 2 On the Directory Server Console, select the Directory tab. 3 In the navigation tree, expand the cn=config icon, and then choose Plug-ins =>
LDBM Database.
4 Select config and right-click the generic editor. 5 Change the NSSLAPD look-through limit as needed (the default is 5000).
If you do not want to set a limit, type -1 in this text box. If you bind to the directory as Directory Manager, by default the look-through limit is unlimited, and overrides any settings you specify here.
Configuring Policy Manager and the Policy Service plug-in

When you have extended your directory service and connected to it from the CMS console, use Policy Manager to perform the following tasks:
s s s
Configure and publish the Policy Service plug-in. Choose a container for saving policies. Assign permissions for targets and policies.
For complete instructions, see the chapter about configuring Policy Manager, in the BMC BladeLogic Client Automation Policy Management Guide.
Whats next?
To use the policy compliance feature of Policy Manager, you need to install and configure Report Center. See Chapter 7, Setting up Inventory Management. To use the immediate policy update feature, you need to install and configure Deployment Manager. See Chapter 12, Setting up Deployment Manager and Content Replicator.
Chapter 10
133
Whats next?
134
Chapter
11
135 135 136 136 136 137 141
11
Setting up Patch Management

When you install the CMS console, the Patch Manager channel is automatically installed on the console. This section describes how to install other BMC BladeLogic Client Automation channels and how to use Patch Manager to configure the Patch Repository and the Patch Service plug-in. Overview of Patch Management components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patch Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patch Source channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patch Service plug-in. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patch Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the Patch Repository and installing the Patch Sources . . . . . . . . . . . . . Configuring Patch Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
If you do not plan to use the Patch Management product, you can skip this section.
Overview of Patch Management components

This section describes the components that comprise the Patch Management module.
Patch Manager
You access Patch Manager through the CMS console. It provides the graphical user interface for configuring the other patch-related components and for selecting the patches to deploy to endpoints. If you followed the instructions in Part 2, Installation, you installed Patch Manager when you installed and set up the CMS console.
Chapter 11
135
Patch Source channels
Patch Source channels

Depending on the types of machines in your enterprise, install at least one of the following Patch Source channels: Red Hat Enterprise Linux, or Windows. These channels contact the appropriate Red Hat Linux, and Microsoft websites to obtain patch information. For instructions for installing these channels, see Configuring the Patch Repository and installing the Patch Sources on page 137.
Patch Service plug-in

The Patch Service plug-in runs on the transmitter machine. The Scanner Service sends inventory and compliance information to the database using the Patch Service plugin on the transmitter, and then starts Patch Service and Policy Service to calculate compliance.
Patch Service
Patch Service is the client-side component of the Patch Management module. You install this channel on endpoints, as described in Creating installers on page 176. Patch Service performs the following tasks:
s
downloads the Patch Information channel that is created after you publish a patch group uses the Patch Information channel to determine which patches are appropriate for the machine performs actions such as installing and uninstalling patches provides compliance information after it finishes performing actions
Because you have already installed Patch Manager (as described in Installing the CMS console on Windows on page 75 or Installing the CMS console on Linux on page 78), you can now configure the Patch Repository, as described in the next section.
136
Configuring the Patch Repository and installing the Patch Sources

After you install the Core database schema and the Patch Management database schema (as described in Installing the Inventory database schema modules and query libraries on page 100), you can configure the Patch Repository. As part of this configuration, you specify the machines on which you want to install the Patch Source channels. The channels are then automatically installed when you save the Patch Repository settings. The following conditions apply to all Patch Source channels:
s
You must update the Patch Source channel if you change the following properties on the Repository Configuration page. The property changes take effect after the update. Windows platform s Destination/Storage directory s Locales Red Hat Enterprise Linux s Source/Red Hat Network URL s Source/User name and Password s Download policy/Red Hat patch download policy
You cannot make configuration changes if a patch group is being published. Either stop the publish or wait until the publish is finished. You cannot make configuration changes if the patch repository is updating. During this time, the only option on the Repository Configuration page is Cancel. If you change a published storage directory and want the information automatically transferred, rebuild the patch repository. To manually copy the information, update the repository.
Before you begin

s
Ensure that the machine hosting your transmitter has enough disk space to accommodate all the patches that you need to publish. For more information about disk space requirements for the transmitter, see the BMC BladeLogic Client Automation Release Notes document, available on the BMC Customer Support web site. Ensure that you have completed the prerequisite work. For information, see the BMC BladeLogic Client Automation Patch Management Guide and the release notes.
Chapter 11
137
For Windows Patch Source, ensure that the following JVM arguments are set: -Xms128m -Xmx640m -XX:PermSize=32m -XX:MaxPermSize=160m JAVA_OPTS=-Xms128m -Xmx640m -XX ermSize=32m -XX:MaxPermSize=160m
Note: When you configure more than two locales in the Patch Repository configuration, it is recommended to increase the Maximum Heap size (Xmx) to 1024. For example, -Xms128m -Xmx1024m -XX:PermSize=32m -XX:MaxPermSize=160m
To configure the Patch Repository

For a more detailed procedure, see the BMC BladeLogic Client Automation Patch Management Guide, available on the BMC Customer Support web site, in online help, or in the Documentation channel.
1 Log in to the CMS console as the admin user, and choose Applications => Patch
Manager.
To log in as a different user, ensure that the user name has primary administrator privileges. The first time you use Patch Manager, the Repository Configuration page is displayed.
2 In Master transmitter, enter the URL for the master transmitter where you want to
publish patch metadata and patch binaries Example: http://trans.mycompany.com:5282). Do not include a forward slash (/) at the end of the URL. All patches must be published to one master transmitter.
3 If publish permission is required to publish patches to the transmitter, fill in User

name for publishing and Password for publishing.
4 In Custom Patch Storage directory, enter the path to a local directory where the
Custom Patch binary files are stored.
5 To install the Windows Patch Source channel, in the Platforms section, select
Windows, and complete the following steps:
A In the Source section, in the Get Patch Source channel from box, enter the URL
(on a transmitter) of the Windows Patch Source channel you want to deploy. This becomes the channel that receives Windows Patch Source configuration changes from Patch Manager.
138
B If the transmitter requires authentication for subscribing and publishing, enter

user names and passwords in the Subscribe Credentials and Publish Credentials sections.
C In the Destination section, in Install Patch Source channel on, enter the host name
(or IP address) and tuner port for the host on which you want to install the Windows Patch Source channel. You must include the RPC port number, such as http://mytuner:7717.
D In Storage directory, enter the path to a local directory where the Windows Patch
Source channel stores downloaded patches. This directory path is relative to the host that is running the Windows Patch Source channel and retrieving the patches, such as C:\PatchStorageDir.
E If administrative permissions are set on the tuner, clear the Connect anonymously
check box and enter the required user credentials.
F In the Download policy section, select a policy that optimizes the Patch
Management implementation.
G In the Delete Patches section, select Allow Delete Patches to delete patches from
the repository and also from the transmitter if published, which are removed by the vendor.
H In the Repository update schedule section, Current update schedule shows the
schedule. To change it, click Modify to specify when to update the patch repository.
I In the Locales section, you can specify the locales for which you want to publish
patches. English is the default.
6 To install the Red Hat Enterprise Linux Patch Source channel, in the Platforms
section, select Red Hat Enterprise Linux, and complete the following steps.
NOTE
When you are finished with the Repository configuration page, go to the Patch Service configuration page and set the Satellite Server Configuration section. These settings enable the endpoints to connect to the Satellite server and install patches.
A In the Source section, in Get Patch Source channel from, enter the URL (on a
transmitter) of the Red Hat Enterprise Linux Patch Source channel to deploy. This becomes the channel that receives Red Hat Enterprise Linux Patch Source configuration changes from Patch Manager.
Chapter 11
139
B If the transmitter requires authentication for subscribing and publishing, enter

the user credentials in the Subscribe Credentials and Publish Credentials sections.
C In Red Hat Network URL, enter the URL to the Red Hat Network. If permission is
required to access the Red Hat Network, fill in User name and Password.
D In the Destination section, in Install Patch Source channel on, enter the host name
(or IP address) and tuner port for the host on which you want to install the Red Hat Enterprise Linux Patch Source channel. You must include the RPC port number, such as http://mytuner:7717.
E If administrative permissions are set on the tuner, clear Connect anonymously

and enter the required user name and password.
F In the Download policy section, select a policy. G In the Repository update schedule section, Current update schedule shows the
schedule. To change it, click Modify to specify when to update the patch repository.
7 When you have finished completing the fields on the page, click Preview, review
your settings, and then click Save to publish the new configuration settings. You are returned to the Patch Manager Configuration page. The Patch Source channels are installed on the machines you specified.
NOTE
The Patch Source channels are started at this point, and begin collecting information about patches. This step updates the Patch Repository and can take several minutes to complete.
8 When the Patch Repository update is complete, verify that the Patch Information
channel was created on the transmitter:
A Choose Applications => Infrastructure => Transmitter Administration, and

complete the Connect to a Transmitter page.
B Click Manage Channels and then click the Content tab. C Use the expander button to display the folders on the transmitter and look for a
folder called PatchManagement. This folder should be at the same level as the BMC CM or Marimba folder.
D Expand this folder and verify that it contains the Patch Information channel.
140
Configuring Patch Service
TIP
(troubleshooting) If you cannot find the PatchManagement/PatchInfo channel on the transmitter, use Patch Managers Get New Patches command or try publishing a patch group (which also creates the PatchInfo channel.) For instructions about creating a patch group, see the Patch Manager online help or the BMC BladeLogic Client Automation Patch Management Guide.

Now that you have installed the Patch Source channels, configured the Patch Repository, and published the PatchManagement/PatchInfo channel to the transmitter, you can configure the Patch Service plug-in, as described in Configuring Patch Service.

The following procedure describes how to publish the Patch Service plug-in.
To configure Patch Service 1 Access the Patch Service Configuration page: A Choose Applications => Patch Manager. B Click the Configuration tab and then click Patch Service to access the Select a
Service page.
C Either enter or browse to the URL of the Patch Service channel that was copied
to your master transmitter when you performed the procedure in Installing the CMS console on Windows on page 75 or Installing the CMS console on Linux on page 78.
D Click OK. 2 In the Patch Service update schedule section, specify how frequently you want the
Patch Service channel updated. The default is Daily at 12:01am.
3 To set requirements for publishing and subscribing to the Patch Service plug-in, in
the Patch Service Options section, enter user names and passwords as needed.
Chapter 11
141
4 In the Endpoint Options section, in Patch Information channel URL, perform one of
the following actions:
s
Accept the URL. When you entered the master transmitter URL and saved the Repository Configuration page, Patch Information channel URL was automatically filled in with that URL. Change the URL. Enter a new URL or browse a transmitter and navigate through folders to select a Patch Information channel. This channel contains patch dependency information.
5 Fill in the rest of the Endpoint Options section as appropriate. 6 To set the Snooze and Reboot window options, in the Custom Reboot Options
section, select or clear the options in this section. The two sections are described together at Snooze|Reboot.
A If you want a custom title, enter one in Snooze|Reboot window title. If you want
the default title Reboot Required, leave the field blank.
B Current snooze|reboot icon shows you the current icon. To change it, in the Select
snooze|reboot icon list, select an icon or select new icon. If you have no customized icons, the default icon is used.
C If you selected select new icon, in New snooze|reboot icon path, enter the URL or
click Browse and select the URL. Click Add to list.
D To create a custom message for users about rebooting their machines, enter it in
Snooze|reboot message. If you want the default message, leave the field blank.
E To have the Snooze|Reboot window move underneath other windows, select

Let Snooze|Reboot window go under other windows. The default is cleared, that is, the Snooze|Reboot window is always the top window.
F If you want the Snooze|Reboot window to minimize, select Let Snooze|Reboot

window be minimized. The default is cleared, that is, the Snooze|Reboot window is always open.
G For the Reboot window, to set the number of hours and minutes to notify users
for the last reboot time, enter the hours and minutes in Time before reboot. The default timeout is one minute.
7 To set the Red Hat Enterprise Linux Satellite, in Satellite Server Configuration, select
Satellite Server Configuration, and complete the following steps:
142
A Enter the Distinguished name of certificate.

This is the certificate you created when you configured the Satellite server.
B In Select certificate, do one of the following:

s s
Select a certificate. If you choose select certificate, in Certificate path, enter the URL or click Browse and select the URL. Click Add to list.
C Enter the Red Hat Network URL. D To restrict access to the Satellite, enter a user name and password. 8 When you have finished completing the fields on the page, click Preview, review
your settings, and then click Publish, to publish the new configuration settings.

After you have configured the Patch Repository and the Patch Service plug-in, you can deploy the Patch Service channel to endpoints.
s
If you plan to use Deployment Manager, proceed to Chapter 12, Setting up Deployment Manager and Content Replicator. If you do not plan to use Deployment Manager, proceed to Chapter 13, Creating profiles, installers, and running deployments, which describes how to install BMC BladeLogic Client Automation components on the rest of the machines in your enterprise.
Chapter 11
143
144
Chapter
12
145 146 146 146 147 147 148 148 149 150 150
Setting up Security Compliance modules

12
This chapter describes how to configure the FDCC Reporting and Security Policy Manager modules: Overview of the Security Compliance modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FDCC Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Policy Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the FDCC Reporting module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying the transmitter for the FDCC Reporting channel . . . . . . . . . . . . . . . . Specifying a folder for saving benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling benchmark scanning on the endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . Scheduling vulnerability scanning on the endpoints. . . . . . . . . . . . . . . . . . . . . . . Configuring the Security Policy Manager module . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the master transmitter and email notification properties . . . . . . . . Configuring the remediation repository for McAfee remediation content . . . .
Overview of the Security Compliance modules

This section describes the components that you can access from the Security Compliance menu option. If you do not plan to use the Security Compliance modules, you can skip this section.
Chapter 12 Setting up Security Compliance modules
145
FDCC Reporting
FDCC Reporting
You access the FDCC Reporting module from the CMS console. The FDCC Reporting module is an FDCC scanning program that enables you to monitor the FDCC compliance of your Windows computers against the benchmarks in the Security Content Automation Protocol (SCAP) packages. By scheduling compliance scans against your endpoints, you can monitor the compliance of your Windows computers. For detailed information about the FDCC Reporting module, see the FDCC Reporting online Help.
Security Policy Manager

You access the Security Policy Manager module from the CMS console. The Security Policy Manager module enables you to ensure that your desktop and laptop computers avoid security threats and comply with government-mandated regulations by applying groups of remediations to specific endpoints in your environment. You can use predefined remediations that address industry-specific regulations, or you can leverage predefined remediations to create custom groups that address the specific requirements of your company. For detailed information about the Security Policy Manager module, see the Security Policy Manager online Help.
Configuring the FDCC Reporting module

To enable security benchmark scanning, you must verify that your product infrastructure is properly configured to scan for vulnerabilities and publish test results. After you review and adjust the default settings for the module, you are ready to start identifying the benchmark tests to run against the computers in your environment. To locate the benchmark files to test against the Windows computers in your environment, you must access the NIST website and download SCAP bundles to a local computer. For information about locating and downloading SCAP bundles from the NIST website, see the FDCC Reporting online Help.
146
Specifying the transmitter for the FDCC Reporting channel
Specifying the transmitter for the FDCC Reporting channel

When you import SCAP bundles to the FDCC Reporting module, the benchmark test properties are published to the transmitter. By default, the FDCC Reporting module publishes the benchmark channels to your master transmitter, but you can specify a different transmitter.
To specify the transmitter for the FDCC Reporting channel 1 Choose Applications => Security Compliance => FDCC Reporting to access the FDCC
Reporting module.
2 Select the Configuration tab. 3 In Transmitter URL, type the URL and port number of the transmitter. 4 If required for the specified transmitter, type the authentication values in User and
Password.
5 To specify a channel name other than the current name, type a value in Transmitter
Folder.
6 Click Save.
Specifying a folder for saving benchmarks

The benchmarks folder acts as the repository for the benchmarks that you import from the NVD on the NIST website. Unless you change the default value, the FDCC Reporting module creates the SecurityBenchmarks folder and saves the benchmarks in the following location in the channel: http://transmitterName:portNumber/SecurityBenchmark/benchmarkNameversionNumber. Each benchmark channel requires approximately 3 MB of disk space.
To specify a folder for saving benchmarks 1 In the FDCC Reporting module, select the Configuration tab. 2 In Transmitter Folder, type a new name for the folder that contains the benchmarks.
147
Enabling benchmark scanning on the endpoints
3 You can specify nested folders by separating folder names with a forward slash
(/). Example: FDCC/SecurityTests.
4 Click Save.
Enabling benchmark scanning on the endpoints

Before you can test for the security vulnerabilities that might exist on your Windows computers, you must enable benchmark scanning on the endpoints.
To enable benchmark scanning on the endpoints 1 Select Applications => Reporting => Report Center to access the Report Center
module.
2 In Report Center, select the Configuration tab. 3 On the Report Center Configuration page, select Inventory Configuration. 4 On the Inventory Plug-in to Configure page, specify the location of the Inventory
plug-in, and click OK.
5 On the Inventory Configuration (Plug-in) page, select the Endpoint tab. 6 In the Scanning section, scroll to Security-Benchmark Scanner, and select Enable
Security-Benchmark Scan.
7 Click Preview, and click Save & Publish.
Scheduling vulnerability scanning on the endpoints

By default, vulnerability scans are not scheduled. When you set up the scanning schedule, BMC recommends that you not perform vulnerability scans more often than once each week, but not less often than every month. Although daily scans would absolutely ensure that your computers stay compliant, for all practical purposes, a weekly scan should suffice.
To schedule vulnerability scanning on the endpoints 1 Select Applications => Reporting => Report Center to access the Report Center
module.
2 In Report Center, select the Configuration tab.

Configuring the Security Policy Manager module
3 On the Report Center Configuration page, select Inventory Configuration. 4 On the Inventory Plug-in to Configure page, specify the location of the Inventory
plug-in, and click OK.
5 On the Inventory Configuration (Plug-in) page, select the Endpoint tab. 6 In the Scanning section, scroll to Security-Benchmark Scanner section. 7 Use the Update frequency options to change the frequency in which the endpoints
are scanned for FDCC vulnerabilities. Verify that Update Frequency is set to a value other than Never.
8 To change the time in which endpoints are scanned, select different options from
the list boxes and type values for the new time.
9 Click Preview, and click Save & Publish.
Configuring the Security Policy Manager module

To configure the Security Policy Manager module, you must configure the Remediation Repository and the Patch Service. The Security Policy Manager module uses the update schedule in Patch Service to apply remediation groups to the endpoints. Because Security Policy Manager uses VBscript to apply remediations, do not disable VBscript on the endpoints. To ensure that you have enough memory to apply remediation content on the endpoints, modify your JVM arguments on the tuner so that they contain the following settings: Xms128m Xmx256m
149
Configuring the master transmitter and email notification properties
Configuring the master transmitter and email notification properties

As part of the repository configuration, you must specify the transmitter where the remediation groups are published.
To configure master transmitter and email notification properties 1 Choose Applications => Security Compliance => Security Policy Manager to access the
Security Policy Manager module.
2 Select the Configuration tab, and click Repository. 3 In the Master Transmitter box, specify the URL for the master transmitter where you
want to publish remediation groups. All remediation groups must be published to the same master transmitter.
4 If permission is required to publish remediation groups to the transmitter, type the

authentication credentials in the user name and password boxes.
5 To receive an email notification when a repository update fails, select the Email
Notification check box, and type the email contact addresses:
s s s
In From, type a single email address for the notification sender. In To, type a comma-separated list of email addresses to receive the notification. If necessary, in Locale, select a language in which to display the notification text.
Configuring the remediation repository for McAfee remediation content

The remediation source channel retrieves remediations from McAfee and makes them available for viewing and distribution. At the completion of this procedure, remediation data is downloaded from McAfees site to build your local remediation repository in the Inventory database. You must install a McAfee remediation source channel on a host computer that is running a tuner. To assist you in deploying this channel, the system can get it from your transmitter and install it on a specified host for you.
150
The initial operation requires at least two hours, but subsequent updates can require significantly less time. Because McAfee adds content on a regular basis, you should also update your repository on a regular basis. The frequency with which you update the repository has a direct affect on the time required to complete the update.
To configure the remediation repository for McAfee remediation content 1 In Security Policy Manager, select the Configuration tab, and click Repository. 2 In the Source section, specify the required source locations and credentials for the
channel that will receive remediation content from McAfee:
A In the Get Remediation Source channel from box, enter the URL (on a transmitter)
of the McAfee remediation channel to deploy.
B If the transmitter requires authentication to subscribe and publish to the

remediation source channel, type the user names and passwords in the Subscribe Credentials and Publish Credentials sections.
s
Subscribe credentials are required by the transmitter to allow the host to subscribe to the McAfee remediation channel. Typically, transmitters are not configured to require subscription credentials. Publish credentials are required by the transmitter to allow Security Policy Manager to publish (save) configuration changes for the McAfee remediation source channel.
3 In the Destination section, identify the destination for the McAfee source channel: A In Remediation Source Channel, type the host name (or IP address) and tuner
port for the host on which you want to install the McAfee remediation source channel.
B If administrative permissions are set on the tuner, clear the Connect

Anonymously check box, and type the required authentication credentials.
C (optional) In Storage Directory, type the path to the target directory.

Unless specified otherwise, the storage directory is the data directory for the McAfee remediation source channel in the tuner workspace.
4 In the Download Policy section, select a policy that optimizes your Security Policy
Manager implementation.
s
Download and Package all Remediation Binaries when the Repository is Updated
151
Select this option to download and package binaries when the remediation repository is updated. You might receive a large volume of patch data when you select this option.
s
Download and Package a Remediation when a Remediation Group is Published
This default option downloads the binaries when a remediation group is published, but only the metadata downloads when the remediation repository is updated.
5 In the Repository Update Schedule section, review the current update schedule.
When you select an option other than Never, options and boxes are displayed that you can use to set the update frequency and times.
NOTE
Generally, less time is required to update the repository when you schedule more frequent updates. BMC recommends that you schedule weekly updates.
6 Click Save. 7 On the Repository Configuration page, click Preview, and then click Save.
152
Chapter
13
Setting up Deployment Manager and Content Replicator

13
This section provides initial instructions on setting up a Deployment Manager environment. After initial setup, see the BMC BladeLogic Client Automation Deployment Manager Guide for information about configuring and customizing Deployment Manager. Overview of Deployment Manager components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment Service and Content Replicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment Manager extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command-line options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logging in to Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting the root directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . If you do not plan to use Deployment Manager, you can skip this section. 153 154 154 155 155 156 157 157
Overview of Deployment Manager components

Deployment Manager controls the distribution of content to endpoints. This section describes the components that comprise this module. If you followed the instructions in one the following sections, you installed Deployment Manager when you installed the CMS console:
s s
Installing the basic components on Windows on page 73 Installing the basic components on Linux on page 76
Chapter 13
153
Deployment Manager
If you followed the instructions in Installing the basic components on HP-UX and AIX on page 79 Deployment Manager is installed on an HP-UX or AIX host machine.
Deployment Manager
Deployment Manager (DM) is the server-side component of the product and is the browser interface that provides centralized deployment and monitoring of content distribution to endpoints. From Deployment Manager you can create, start, and monitor deployment jobs. The set of commands that comprise a deployment job distribute and manage content and applications on sets of endpoints. Additional tasks you can perform using Deployment Manager:
s s s s s
run system commands install, update, and remove applications install, update, and remove large amounts of data perform all of these tasks according to a schedule or by manually starting the job monitor the progress in near-real time. Deployment Manager receives log files from endpoints while the job runs.
Deployment Manager versus Policy Manager

Whereas the policies you set with Policy Manager often do not take effect immediately, but must wait until the endpoints Policy Service checks for updates, the deployment jobs that you create with Deployment Manager can be run and sent to endpoints immediately. This functionality is often important if the endpoints you are managing are servers, and you want deployment actions to be carried out at the same time on all the servers. When used with Deployment Manager, Policy Manager can update policies immediately.
Deployment Service and Content Replicator

Deployment Service is the client-side component of the product. The Deployment Service receives commands from Deployment Manager and either carries them out or communicates with other channels on the endpoint to carry out the commands. The Deployment Service also sends log messages back to Deployment Manager so that progress on the endpoint can be centrally monitored.
154
Deployment Manager extensions
The Deployment Service communicates with Content Replicator on the endpoint, and Content Replicator installs, stages, updates, or removes data files. Deployment Manager can install the Deployment Service as long as the URL for the Deployment Service channel uses the same relative URL as Deployment Manager. The default path that the BMC BladeLogic Client Automation installer uses is http://machineName:5282/Marimba/Current/. The Content Replicator and Deployment Services channels are automatically installed on an endpoint when a Deployment Manager job runs on the endpoint (as long as Content Replicator uses the same relative URL as Deployment Manager).
Deployment Manager extensions

Deployment Manager extensions make it possible to use the BMC BladeLogic Client Automation Application Packager and Content Replicator products directly from within Deployment Manager. You can create Application Packager commands to package shrink-wrapped or custom applications and then use Deployment Manager to distribute the applications to endpoints. Content Replicator publishes data files from a source system, sends the content to a data server (transmitter) and then previews, stages, installs, and rolls back, if necessary, the content distribution to the individual endpoints.
Command-line options
The runchannel program provides the capability of using command-line options to perform Deployment Manager or Content Replicator tasks. For more information, see the BMC BladeLogic Client Automation Package Deployment CLI Guide.
Chapter 13
155
Logging in to Deployment Manager
Logging in to Deployment Manager

Although Deployment Manager is installed on the same machine as the CMS console, you access Deployment Manager through a different browser interface.
To log in to Deployment Manager from the browser 1 Open a browser and enter the Deployment Manager URL, which has this form:
http://machineName:port
where:
s
machineName is the name of the machine on which Deployment Manager is installed. port is the port number for accessing Deployment Manager. The default is 8000.
Example: http://machine_abc:8000
2 On the login page, in User name, enter admin, and leave Password blank. 3 Click Login.
If you are logging in to Deployment Manager for the very first time, you must configure the database settings for accessing the Report Center (inventory db) database.
4 Configure the database settings: A Choose the Database type (Oracle or Microsoft SQL Server). B Type the host name. C Enter the port number. The default port numbers are 1521 (for Oracle) and 1433
(for SQL Server).
D Enter the SID:

s s s
For Oracle, type the database system ID. For Oracle RAC, type the net service name, and select Use Net Service Name. For SQL Server, type the database name invdb.
E Provide the password for the inventory user. The default password is inventory. F Click OK.
Configuring Deployment Manager
The Deployment Manager Restarting page displays. After a 30 second display, the login page is displayed.
5 Log in again.
The Welcome page appears. This page provides an Introduction to Deployment Manager and outlines the required steps for deploying content to target endpoints.
NOTE
For security purposes, if you do not use Deployment Manager for 15 minutes, you are automatically logged out. You can change this setting using the Deployment Manager Settings tab. To use the command-line interface to log in to Deployment Manager, see the -login option in the BMC BladeLogic Client Automation Package Deployment CLI Guide.
Configuring Deployment Manager

BMC Software highly recommends that you change the root directory from its default location. If you leave the root directory in the default location, deleting the Deployment Manager channel also deletes all your configuration information. BMC also recommends that you restrict access to the root directory because it contains files essential for Deployment Manager to run properly, and it contains sensitive information (such as user names and passwords). Ensure that only administrators and trusted users have access to it. Deployment Manager starts automatically when the host machine starts.
Setting the root directory

Deployment Manager stores all its configuration settings and history logs in its root directory. By default, the root directory is the directory where the Deployment Manager channel is stored. All Deployment Manager objects and execution logs are stored in the Report Center (inventory) database.
s
On Windows, the default is installationDirectory\.marimba\Marimba\ch.X\data\, where X is the appropriate channel number. On UNIX, the default root directory is
/usr/local/Marimba/Tuner/.marimba/ws3/ch.X/data/.)
When changing the root directory, keep the following points in mind:
Chapter 13 Setting up Deployment Manager and Content Replicator 157
The root directory must be on the same machine as Deployment Manager. If you change the root directory, restart Deployment Manager. The information previously stored in the old root directory is not copied to the new root directory. Deployment Manager uses only the information stored in the new directory. You can change the root directory setting only if you are a Deployment Manager administrator (that is, a member of the dmadmins group).
NOTE
To set the root directory using the command-line interface, see the -setRoot, -getRoot, and -restart options in the BMC BladeLogic Client Automation Package Deployment CLI Guide.
To set the root directory from the browser 1 On the Deployment Manager interface, select the Settings tab. 2 From the Deployment Manager Settings page, under Settings click Set Root
Directory link.
3 Enter the full path you want Deployment Manager to use for its root directory. 4 Click OK. 5 Restart Deployment Manager: A Click the Settings tab => Advanced Settings => Restart. B From the Restart Deployment Manager page, click Restart. Where to go from here
You are now ready to configure Deployment Manager for your environment. Refer to the following documentation:
s
The BMC BladeLogic Client Automation Deployment Manager Guide for a description on how Deployment Manager works and for information on configuring and customizing Deployment Manager for your environment. The BMC BladeLogic Client Automation Package Deployment CLI Guideprovides information on using the command-line interface to Deployment Manager, Content Replicator, and Application Packager.
Both documents are available on the BMC BladeLogic Client Automation Customer Support website.
Chapter 13
159
160
Chapter
14
Creating profiles, installers, and running deployments

14
When you have finished configuring your CMS console, your BMC BladeLogic Client Automation applications, and the plug-ins so that your endpoints can send and receive data according to the schedules you specify, you can create installers that you run on your target machines. These installers create several types of infrastructure components: repeater and mirror transmitters, proxies, and managed nodes (endpoints). Overview of the setup and deployment components . . . . . . . . . . . . . . . . . . . . . . . . . Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installer Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating profiles for various components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a profile for desktop endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a profile from the Profiles tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading a profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a profile for a mirror or repeater transmitter . . . . . . . . . . . . . . . . . . . . . Creating a profile for a proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a profile for a Deployment Manager endpoint . . . . . . . . . . . . . . . . . . . . Creating installers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installer location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Platform-specific installer templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CAR files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Platform dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating installer deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installer installation path on targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installer deployment timeout period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running and monitoring installer deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Credentials for starting a deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring a running deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stopping a deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining if you have a successful deployment . . . . . . . . . . . . . . . . . . . . . . . . 162 162 162 163 163 165 167 168 168 171 173 174 174 174 175 175 180 180 180 183 183 184 184 185
Chapter 14
161
Overview of the setup and deployment components
Troubleshooting failed deployments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Failed deployment details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Ports used by remote deployer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Limitation of remote deployment on Microsoft Windows Server 2008. . . . . . . . 188 Remote deployment on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Stub installer failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Understanding mrbapsexec errors for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Uninstalling tuners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 For online help about any items that appear on the tabs, click the Help button in the upper-right corner of the browser page. For text boxes that have underlined labels, placing your mouse pointer over the label name causes a description to display.
Overview of the setup and deployment components

When you package a tuner to run on your endpoints, and to be used throughout your BMC BladeLogic Client Automation infrastructure, you combine the following items:
s s s
Tuner binaries Profiles (configuration settings) Installers (installation-specific settings)
Profiles
You create a profile for each type of component, including proxies, transmitters, managed nodes (endpoints), mirrors, and repeaters. Profiles contain configuration settings, not product binaries. Each profile is saved as a segment of the channel. If you change a profile setting, then the next time an endpoint updates its Infrastructure Service channel, the endpoint gets the new profile settings.
Installers
You create an installer for each profile. When you create an installer, you select a profile and specify various installation specific settings, such as whether you want the installation to be invisible to end users, and the location where you want the software to be installed on the machine. When you finish creating the installer, you
162
Installer Deployments
have an executable file that you can deploy to the machines in your enterprise. The installers are saved in the Infrastructure Administration channels data directory, for example:
installationDirectory\.marimba\<profile name>\ch.3\data\ persist\installermanager\ installers\winnt\myInstaller.exe
Installer Deployments
After creating an installer, you create a list of machines on which you want to deploy the installer. You create an installer deployment when you identify the machines for the installers. To create a deployment, you use the Deployments tab, on the CMS console to start the process.
WARNING
When you perform the tasks described in this chapter, use the Setup & Deployment workflow on the CMS console. When using workflows ensure that no one logs in to the console using the same user name as the current user. If this happens, an internal error occurs. To recover from this error, use Channel Manager to stop and then restart the CMS console. (The console is also called the Common Management Services channel.)
Creating profiles for various components

You need to create a different profile for each of the components in Table 1. Each component has a corresponding profile types. Table 1
Profile type Managed Node Master Transmitter
Profile types (part 1 of 2)

Description runs on endpoints and enables content and applications to be automatically updated hosts the channels and packaged applications and content to be distributed to your endpoints The recommended way to install a master transmitter is to run the installation program or script on the machine that is to host the master transmitter.
To install your master transmitter on HP-UX and AIX machines, use the Master Transmitter profile type and then create an HP-UX or AIX-specific installer. For details, see Installing the basic components on HP-UX and AIX on page 79.
Chapter 14
163
Creating profiles for various components
Table 1
Profile type
Profile types (part 2 of 2)

Description mirrors channels from the master transmitter, to provide fault tolerance For details, see Creating a profile for a mirror or repeater transmitter on page 168.
Mirror Transmitter
Repeater Transmitter repeats selected channels from the master transmitter to distribute the load across multiple servers For details, see Creating a profile for a mirror or repeater transmitter on page 168. Proxy caches channels from the master transmitter, providing a lowoverhead way of serving channels to remote endpoints After you create the profile and installer for this component, and deploy it to the appropriate machine, you might need to use Proxy Administrator (on the CMS console) to configure additional proxyspecific settings. For details, see Creating a profile for a proxy on page 171. Evaluation used solely by Professional Services and channel partners This profile type requires an Evaluation Key and has pre-set tuner, transmitter, and installer configurations for improving the test drive experience.
You must also create a profile for endpoints.

s s
For desktop endpoints, use the Managed Node profile type. For Deployment Manager endpoints, more specific instructions are provided later, in Creating a profile for a Deployment Manager endpoint on page 173.Creating a profile involves selecting one of the profile templates, editing the settings if needed, and saving the profile. When the profile is created, you can use it to create an installer.
A single Infrastructure Service cannot accommodate more than 44 user-created profiles. If you have difficulty deleting a profile, you might need to use the Infrastructure Transmitter Administrator to delete the profile (segment).
NOTE
The tuner property that records which profile is being used is marimba.tuner.update.profile. You can change this property to change which profile a tuner uses. The value for this property uses the form .profile_profileName.
164
Creating a profile for desktop endpoints

You can quickly create a profile for desktop endpoints by using the Setup & Deployment wizard. This wizard abbreviates the profile creation process by offering only basic configuration options.
Before you begin

You must be logged in to the CMS console, as described in Logging in to the CMS console on page 87
To create a profile for desktop endpoints 1 On the tab menu in the upper-right portion of the browser page, choose
Applications => Infrastructure => Setup & Deployment.
2 From Deploy BBCA Infrastructure, click Begin Wizard.

This wizard is also referred to as a workflow. You can alternatively access it from the Show Workflows list.
3 On the Create Profiles page, select the Managed Node profile, and click Next. NOTE
To display a list of profiles from a different transmitter, or if access permission has been set on the current transmitter (for publishing to the Infrastructure Service or replicating it), click Load Profiles. For more information, see Loading a profile on page 168. For Windows endpoints: If the machines for which you are creating a profile do not have more than 64 MB of RAM, use the Profiles tab to edit the profile, so that you can access the Advanced => Runtime Arguments tab. On the Runtime Arguments tab, verify that JVM arguments contains the following setting: -Xms64m -Xmx128m
This setting prevents the tuner from using too much memory.
NOTE
(Windows XP) If you plan to install BMC BladeLogic Client Automation products on a Windows XP (Service Pack 2) machine that has the Windows Firewall turned on, then add a firewall exception for the java.exe application that the tuner uses. However, remote deployment does not work when Windows Firewall is turned on. For more information, see Windows XP Firewall exceptions on page 58.
Chapter 14
165
For Solaris endpoints: Use the Profiles tab to edit the profile, so that you can access the Advanced => Runtime Arguments tab. On the Runtime Arguments tab, enter -Xint in Launch arguments.
4 Name the profile.

Assign a name that indicates the type of component, such as repeater or endpoint. If you use a different profile for endpoints in one department than for endpoints in another department, you might include the department name in the profile, for example: HR_Endpoint.
5 Complete the remainder of the pages that appear.

Enabling MESH in a profile: You can enable the MESH (multi-endpoint sychronized host) functionality in a endpoint profile by setting the following custom property: marimba.tuner.p2p.enabled=true
For more information on how setting this property can reduce the number of mirror and repeaters needed in your environment, see the BMC BladeLogic Client Automation CMS and Tuner Guide.
Enabling tuner uninstall from Add or Remove Programs: By default, the tuner cannot be uninstalled from Add or Remove Programs in the Windows Control panel. But you can change this option in an endpoint profile. From the Edit Profile page in Setup & Deployment, click the Advanced and Miscellaneous tabs. Select Allow Tuner Uninstall from Add or Remove Programs.
Selecting this option sets the marimba.tuner.uninstall.allowed property to true.

Enabling vPro features: By specifying Intel AMT vPro settings, you can allow BMC
BladeLogic Client Automation to use vPro features to wake vPro PCs for policy updates and to launch the vPro management console from Tuner Administration, the Infrastructure Status Monitor Dashboard, or from the Machine Details page in Report Center. To enable vPro features, access the Edit Profile page in Setup & Deployment, and click the Advanced and vPro tabs, as described in the Setup & Deployment Help.
Enabling ISM monitoring: The Infrastructure Status Monitor provides healthrelated metrics about your BMC BladeLogic Client Automation infrastructure, including Master transmitters, Repeaters, Mirrors, Proxies, and Tuners. You can enable this feature on the endpoint from the CMS console as described in the BMC BladeLogic Client Automation CMS and Tuner User Guide.
166
Creating a profile from the Profiles tab
Patch Management: If you intend to use Patch Management, then in the Trusted Transmitters list, add the transmitter that hosts your Patch Management channels
(that is, the transmitter that you publish patches and patch groups to). The patch groups and Patch Information channel that you create cannot be signed with codesigning certificates. Therefore, use the trusted transmitter instead of security certificates. When you specify a trusted transmitter, endpoints are able to download the patches created and deployed by using Patch Management.
NOTE
You can enable remote administration on the Security => Remote Administration tab. If you do not allow remote administration, you cannot use Tuner Administrator or Deployment Manager to connect to the managed node. About users and groups in a directory service: You can set a profile to allow remote
administration for either one user or one or more groups from a directory service, but not both users and groups by using the option called Allow remote access for the following users and groups. Further, to specify groups, use group= before specifying the groups, for example: group=group1;group2.
NOTE
On the Create Installer page, the profile that you just created appears in Select a Profile. To change the profile, select the Profiles tab. When you edit a profile, you see more configuration settings than were initially displayed when you ran the wizard.
Finish creating the installer that uses this profile before you go back and create additional profiles for other components.
Creating a profile from the Profiles tab

Instead of using the workflow, you can access the Profiles tab, select a profile template, and then click Edit a Copy. Using the Profiles tab allows you to see additional configuration options. If you use the Profiles tab, also read the following sections, as appropriate:
s s s
Creating a profile for a mirror or repeater transmitter on page 168 Creating a profile for a proxy on page 171 Creating a profile for a Deployment Manager endpoint on page 173
Chapter 14
167
Loading a profile
Loading a profile
Each profile is saved as a segment of the Infrastructure Service channel. Therefore, the profiles displayed in Available Profiles depend on which Infrastructure Service the console is connected to. If you have different transmitters and they all host an Infrastructure Service channel, then the profiles you want might be on only one of those transmitters. This procedure describes how to select the Infrastructure Service channel from the appropriate transmitter and how to supply user credentials if permission has been set on the transmitter for replicating or publishing the Infrastructure Service.
To load profiles 1 On the Profiles tab, click Load Profiles. 2 Enter the transmitters URL (for example, http://acme:5282) and, if access
permission is set for the transmitter, enter the user credentials for replicating or publishing channels. If the transmitter has access permission, consider these guidelines:
s
If replication permission has been set, enter the user credentials for replicating the channel to edit or create profiles. If publish permission has been set, you cannot save new profiles or apply edits to existing ones unless you enter user credentials for publishing the channel. If both replication permission and publish permission are set to use the same user credentials, then you enter those credentials only once, in User name and Password. If, however, the user credentials for publishing (applying) the profile are different from those for replicating the channel, select the check box for that purpose and enter the publish user name and password separately.
3 Click Load, and after the list of profiles is displayed, click Close.
Creating a profile for a mirror or repeater transmitter

When you create a profile for a mirror or repeater transmitter, you cannot use the Create Profile wizard. Profiles for a mirror or repeater require that you set additional properties. This procedure describes how you can create a profile by editing a copy of the Mirror Transmitter profile or the Repeater Transmitter profile.
168
TIP
You can also use the following procedure to create a profile for a master transmitter. You might need to use this procedure to install a master transmitter on an HP-UX or AIX machine.
To create a mirror or repeater profile 1 In the Setup & Deployment window, click the Profiles tab.
You can ignore error messages about canceling out of a workflow.
2 In the list of available profiles that appears, select the appropriate profile template
(Mirror Transmitter or Repeater Transmitter), and click Create a Copy.
3 On the Edit Profile page, you can set most of the core settings, but you must
complete the following steps:
A Name the profile. B If you intend to use Patch Management, then on the Security => Trusted
Transmitters tab, add the transmitter to which you will publish patches and
patch groups. For more information, see the Patch Management note in step 5 on page 166.
C On the Security => Remote Administration tab, allow remote administration. If

you do not, you cannot use Tuner Administrator or Transmitter Administrator to connect to this transmitter.
D On the Advanced => Runtime Arguments tab, ensure that JVM arguments contains
the following setting:
-Xms128m -Xmx640m -XX:PermSize=32m -XX:MaxPermSize=160m
This setting increases the memory allocation, which avoids out-of-memory errors.
4 On the Custom Properties tab, if you plan to run the Logging Service channel on this
transmitter to collect specific log messages in the central database, set the following properties:
s
Set marimba.tuner.logs.centralizedlogging to true if you want the Logging Service channel to run when the tuner starts. Set marimba.tuner.logs.applyFilters to true if you want the Logging Service channel to apply filters to the log messages produced on the endpoint. Apply filters so that only the needed log messages are collected. If you set this property to false, your database can get overloaded.
Chapter 14
169
5 To enable Infrastructure Status Monitor on the profile, complete the following

steps:
A Select the Advanced tab, and then select the ISM tab. B Type the host name or IP address of the of the master transmitter to receive the
SNMP Alerts.
C Type the SNMP manager port number.

You can specify any valid port, but the default port is 162.
D Type the URL where Logging Service is running.

Example: http://mpl-esx:5282/ISM/LoggingService
E For Component Reporting Schedule - Send Status, set the schedule used by the
related components to send their status to the plug-in.
6 Click the Mirror or Repeater icon (as appropriate), near the top of the page, to
display the transmitter-specific settings.
TIP
If you are creating a master transmitter profile, click the Master icon.
7 For a Mirror Transmitter, perform the following steps: A On the General => Redirection Settings tab, if you plan to use redirection or
geographic redirection, configure those settings.
NOTE
If you plan to use a subnet repeater policy, then do not configure redirection settings now. Use the Transmitter Administrator to specify that setting.
B On the General => Replication Settings tab, specify the master that this mirror
replicates, and specify whether you want the subscribe and replication permissions to also be mirrored.
170
Creating a profile for a proxy
8 For a Repeater Transmitter, perform the following step:

On the General => Replication Settings tab, click New Source to Repeat, and specify which master or masters this repeater replicates. You can replicate all the channels, only particular folders, or only particular channels from one or more masters.
9 If needed, review the other tabs for the core and transmitter-specific settings. 10 Preview and then apply your settings. NOTE
Other mirror-specific or repeater-specific settings you can specify might not be possible to specify in a profile. You might need to use Transmitter Administrator for those settings, after you run the installer and install the mirror or repeater.

Proceed to Creating installers on page 174, to create an installer for this transmitter profile.

When you create a profile for a proxy, you cannot use the Create Profile wizard. Profiles for a proxy require that you set additional properties. This procedure describes how you can create a profile by editing a copy of the Proxy profile.
To create a proxy profile 1 In the Setup & Deployment window, click the Profiles tab.
2 In the list of available profiles that appears, select Proxy and click Create a Copy. 3 If you intend to use Patch Management, on the Security => Trusted Transmitters tab,
add the transmitter that you will publish patches and patch groups to. For more information, see the Patch Management note in step 5 on page 166.
4 On the Security => Remote Administration tab, allow remote administration.

If you do not configure for remote administration, you cannot use Proxy Administrator to connect to this proxy.
Chapter 14 Creating profiles, installers, and running deployments 171
5 On the Advanced => Runtime Arguments tab, ensure that JVM arguments contains
the following setting:
-Xms128m -Xmx640m -XX:PermSize=32m -XX:MaxPermSize=160m
This setting increases the memory allocation, which avoids out-of-memory errors.
6 If you intend to use the Infrastructure Status Monitor, select Advanced => ISM tab,
and complete the following steps:
A Type the URL for the Logging Service.

Example: http://mpl-esx:5282/ISM/LoggingService
B For Component Reporting Schedule - Send Status, set the schedule used by the
related components to send their status to the plug-in.
7 On the Custom Properties tab, set the following custom properties if you plan to run
the Logging Service channel on this proxy to collect specific log messages in the central database:
A Set marimba.tuner.logs.centralizedlogging to true if you want the Logging Service

channel to run when the tuner starts.
B Set marimba.tuner.logs.applyFilters to true if you want the Logging Service

channel to apply filters to the log messages produced on the endpoint. Apply filters so that only the required log messages are collected. If you set this property to false, your database can get overloaded.
8 Click the Proxy icon, near the top of the page, to display the proxy-specific settings
and change the setting, if necessary. Defaults are provided for all necessary proxy settings, so that you are not required to configure any setting specifically. These settings include such things as type of proxy (normal or reverse), listener port, cache size, performance-related settings, and log roll policies.
9 Preview and then apply your settings. NOTE

Other proxy-specific settings you can specify might not be possible to specify in a profile (especially settings related to SSL). You might need to use Proxy Administrator for those settings, after you run the installer and install the proxy.
172
Creating a profile for a Deployment Manager endpoint

Proceed to Creating installers on page 174, to create an installer for this proxy profile.
Creating a profile for a Deployment Manager endpoint

When you create a profile for a Deployment Manager endpoint, you cannot use the Create Profile wizard. Profiles for a proxy require that you set additional properties. This procedure describes how you can create a profile by editing a copy of the Managed Node profile.
NOTE
You can also use the following procedure to create a profile for a Deployment Manager machine. You might need to do this to install Deployment Manager on a machine. (Ordinarily, Deployment Manager is automatically installed when you run the BMC BladeLogic Client Automation installer to install the CMS console. The CMS console is supported only on Windows, and Linux, however.)
To create a Deployment Manager endpoint profile 1 In the Setup & Deployment window, click the Profiles tab.
2 In the list of available profiles that appears, select Managed Node, and then click
Create a Copy.
3 For most of the settings on the Edit Profile page, you can use the settings you
prefer, but you must configure the following settings:
A If you intend to use Patch Management, then on the Security => Trusted
Transmitters tab, add the transmitter that you will publish patches and patch groups to. For more information, see the Patch Management note in step 5 on page 166.
B On the Security => Remote Administration tab, allow remote administration. If

you do not, you cannot use Deployment Manager to connect to your endpoints and run deployment jobs on them.
C To eliminate out-of-memory errors, on the Advanced => Runtime Arguments tab,

ensure that JVM arguments contains the following setting:
-Xms64m -Xmx128m
Chapter 14
173
Creating installers
D (Solaris only) On the Runtime Arguments tab, in Launch arguments, type -Xint. E On the Custom Properties tab, set the following custom properties:
s s
Set marimba.logs.enabled to true. Set marimba.logs.max.queue to 0 (zero). This settings means that there is no limit to the queue size for logs. Use this setting so that log messages do not start to be discarded after the queue reaches a certain size.
4 Preview and then apply your settings. Where to go from here

Proceed to Creating installers, to create an installer for this Deployment Manager endpoint profile.
Creating installers
When you create an installer, you select a profile and you specify various installationspecific settings, such as whether you want the installation to be invisible to end users, and the location where you want the software to be installed on the endpoint. After you create the installer, you have an executable that you can deploy to the machines in your enterprise. You must create a different installer for each profile.
Installer location
The installers are saved in the Infrastructure Administration channels data directory, for example:
installationDirectory\Tuner\.marimba\<profilename>\ch.3\data\persist\installermana ger\installers\winnt\myInstaller.exe
Platform-specific installer templates

When you create an installer, in addition to using a profile, Setup & Deployment uses a platform-specific template to build the installer. These templates are included in the Infrastructure Service channel as the following segments:
.template_Linux .template_Windows x86 .template_Windows x64 174 BMC BladeLogic Client Automation Installation Guide
CAR files
.template_MacOSx
For a list of the supported versions of each platform, see the BMC BladeLogic Client Automation Release Notes document, available on the BMC Customer Support website.
CAR files
When you create an installer, you specify whether to include any BMC BladeLogic Client Automation channels in the installer, so that when you install the tuner, the tuner is automatically subscribed to the channel. You use one of the following methods to include channels in an installer:
s s
Specifying a channel URL Specifying a CAR file (channel archive file) a more complicated process than using a channel URL
You must create the CAR files before creating the installer. To create the CAR files, you can use Channel Copier or the Transmitter Administrator, which is part of the console server. You can create CAR files for the following channels:
s s
Scanner Service Subscription Policy Service
For instructions about creating CAR files, see either the Channel Copier Help or the Transmitter Administrator Help. Save these CAR files on the machine that you use to create the installers.
Platform dependencies
If the console server is hosted on a Windows machine, you can create an installer for either Windows or UNIX. However, if the CMS console is installed on a UNIX machine, you cannot create an installer for Windows machines because the UNIX machine cannot create the MSI package used for Windows installers. If your CMS console is hosted on a UNIX machine, you can create installers for Windows endpoints if you run the BMC BladeLogic Client Automation installer on a Windows computer to create another console and then create Windows installers from that computer.
Chapter 14
175
Before you begin

s s
You must have a profile that you can use to create the installer. To specify channels, you must know the channel URL or channel archive file (CAR) file.
To create an installer 1 On the Create Installer page that appeared after you finished creating a profile,
ensure the profile you created is selected, and click Next.
NOTE
An alternative method to create an installer is to first click the Installer tab, and then click New Installer. Select a profile and complete the wizard pages.
2 On the Create Installer: Select Platform page, select the platform and click Next.
The Create Installer: Edit Settings page appears, and the General tab is displayed.
3 Name the installer.

By default, the profile name is used to construct the name of the installer. Because installers are platform-specific, you can indicate the platform in the installer name, for example, endpoint-Solaris.bin. The profile name is also used as the service name, if you are creating an installer that installs the tuner as a Windows service.
4 To create a stub installer, in addition to the regular installer, specify the stub
installer and complete the related fields in the Stub Installer section. You can create a stub installer to save download time and reduce the load on your network. Because of its smaller size, the stub is deployed to endpoints faster than the regular installer. (It then downloads the regular installer.) When you create a stub installer, both the stub and the regular installer are created, and both are saved in the same directory with the regular installer. The name of the stub installer includes _stub by default to help you distinguish the stub installer from the regular installer.
5 In the Channels to Include section, click either Add CAR File or Add URL:
s
If you click Add CAR File, specify a source directory to the .car files (which you previously created by using Channel Copier or Transmitter Administrator). Also specify the URL that the channel should use when checking for updates after it is installed. By default, the URL for the Infrastructure Service channel is included. If you need to instead include this channel by using a CAR file, include only the any/any segment in the CAR file (for Infrastructure Service).
176
If you click Add URL, specify the source URL and update URL. The source URL is the URL to use for packaging the channel into the tuner installer. The update URL is the URL that the channel should use when checking for updates after it is installed on the endpoint. (The source and update URLs can be the same.)
NOTE
If the subscribe permission was set on the transmitter, supply the user name and password for subscribing to the channel.
6 Specify whether you want the channel to check for an update before running for
the first time, and specify whether you want to start the channel when the tuner is launched for the first time (recommended for Scanner Service only); then click Save.
7 To include other channels, repeat step 5 on page 176 and step 6.

The channels that you include are displayed in the Channel list. By default, the Infrastructure Service channel is always displayed in the list. It is by means of this channel that configuration updates (profile changes) and tuner binary updates are sent to endpoints. For master transmitter, mirror, and repeater profiles, both the Infrastructure Service channel and the Transmitter channel are included by default. For proxy, both the Infrastructure Service channel and the Proxy Server channel are included by default. The following list of components contains recommendations for the additional channels to include:
s
For managed nodes (desktop endpoints), add the Scanner Service and Policy Service if you plan to use the Policy Management module. When this service is installed, you can use the Policy Management module to install the other product service channels that you want to run on the endpoint. Alternatively, if you plan to use Deployment Manager, you use Deployment Manager (on the CMS console) to install service channels. The service channels that you likely want to install are, in addition to Scanner Service, Patch Service (if you purchased the Patch Management module), and Logging Service. The Deployment Service channel and Content Replicator are automatically installed by Deployment Manager, so that you do not need to create a policy or deployment job to install it.
NOTE
You should archive only the Infrastructure Service, Policy Service, and Scanner Service channels. Archiving only a few channels keeps the size of the installer to a minimum.
Chapter 14
177
For application-packaging machines, include the Scanner Service and Policy Service, if you use Policy Management. When you install the tuner, use either Policy Manager or Deployment Manager to subscribe the tuner to the following channels: Application Packager, Channel Manager, Help Manager, and Channel Copier. These channels are required for an application-packaging machine. Depending on the BMC BladeLogic Client Automation modules that you purchased, you can also subscribe the tuner to Patch Service and Logging Service.
For mirrors or repeaters, include the Scanner Service and Policy Service, if you use Policy Management. Transmitter and Infrastructure Service are included by default. When you install the tuner, you can use either Policy Manager or Deployment Manager to subscribe the tuner to the following channels: Patch Service and Logging Service.
For proxies, include the Scanner Service and Policy Service, if you use Policy Management. Proxy Server and Infrastructure Service are included by default. When you install the tuner, you can use either Policy Manager or Deployment Manager to subscribe the tuner to the following channels: Patch Service and Logging Service.
For a Deployment Manager installer, include the Deployment Manager (SDM), Deployment Manager Command Line (SDMCmd), Content Replicator (Rep), and if applicable, Application Packager. The Infrastructure Service is included by default.
NOTE
On Windows, and Linux, Deployment Manager is installed automatically when you run the installer to create the CMS console.
For Deployment Manager endpoints, you do not need to include any additional channels. You do not need to include the Deployment Service channel or Content Replicator channel. These channels are automatically downloaded the first time you run a deployment job on the endpoint. The only requirement is that these channels be in the same location on the transmitter as the Deployment Manager channel, which is the default location. When you install the tuner, if needed, you can use Deployment Manager to subscribe the tuner to the following channels: Patch Service and Scanner Service. Review the settings on both the General tab and the Advanced tab.
178
8 To remotely deploy the installers, use the Deployments tab to set the user
interaction to be silent or semi-silent on Windows, or non-interactive on UNIX. If you set the user interaction to be fully interactive, prompts appear on the endpoints when you run the remote deployment, and because no users respond to the prompts, the remote deployment fails.
9 (For packaging machines only) If you are creating an installer for a Windows
machine that you intend to use for packaging software, set the tuner so that it is not installed as an NT service (the default).
NOTE
If you plan to install and use Application Packager on the machine, use the following steps to clear the NT service option: Select the Advanced => NT Service tab and clear the Configure the Tuner as a Service check box.
10 When you have finished completing the Edit Settings page, including the General
tab and the Advanced tab, click Preview.
NOTE
(UNIX) On the Advanced => Packaging & Startup tab:
s
You can specify the user to run as on the tuner. The default is root, and BMC Software recommends that you keep this default setting. Super-user, root privileges are required in order for inventory collection to work properly. Some Scanner Service system calls and other commands need root privileges to be executed. Therefore, if the tuner runs as a different user than root, some data is not collected by the inventory scanner. You can specify the Umask value in tuner startup script. Enter an octal value to set the file permissions for tuner logs on UNIX endpoints. The default (027) allows "rwx" permissions for the owner and read permission for the group. If non-root users need access to tuner logs, set the umask to 022 while creating the installer.
11 When you have finished reviewing your settings, click Create Installer. Where to go from here
When you get to the Remote Deploy page, the installer that you just created appears in the Select an Installer list. At this point, continue on to the next section, Creating installer deployments on page 180. You finish creating the deployment that uses this installer before you go back and create additional profiles and installers for other components.
Chapter 14
179
Creating installer deployments
Creating installer deployments

When you have created an installer (as described in Creating installers on page 174), you can create a list of machines on which to deploy the installer. The task of identifying which installer to use on which machines constitutes creating an installer deployment. When the deployment is created, you can use the Deployments tab to start the deployment operation.
NOTE
The process of creating an installer deployment requires you to create a new deployment. You cannot create a deployment by editing an existing deployment. Also, because you cannot edit a deployment, if you need to make a change to a deployment, delete the deployment and create a new one.
Disabling UAC
When you perform remote deployment of Tuner on Windows Vista, Windows 7 and Windows 2008 operating systems, you must disable User Access Control (UAC) in the endpoints.
Installer installation path on targets

By default, the installer.exe file is copied to the C:\temp folder on the remote machines. To copy installer.exe to a different location, set the path in channel.txt by adding the optional channel property psexec.installdir:
psexec.installdir=d:\new
You must add this property before you deploy an installer. When the remote tuner installation is complete, the installer.exe file is deleted from remote machines. To deploy the Tuner successfully, ensure the admin$ share for C$ is enabled on the target machines.
Installer deployment timeout period

To customize the installer deployment timeout (optional), add the following channel property in the infrastructure administration channel.txt: deployment.timeout=360000, where 360000 is time in milliseconds
To create an installer deployment 1 On the Remote Deploy page that appears after you finished creating an installer,
ensure the installer you created is selected, and click Next.
NOTE
An alternative way to create a deployment is to not use the wizard/workflow but instead to click the Installer tab directly, select the installer, and then click Deploy.
2 Complete the Remote Deploy: Select Targets page that appears, and then click
Preview.
WARNING
If, to target Windows machines, you use auto-discovery, ensure that when you enter the domain name, you type the name correctly. To avoid this issue, you might browse My Network Places and copy the domain name, and then paste the name into the domain field.
NOTE
(about selecting targets) The targets that you specify must be machines that you can communicate with from the machine where the console is installed. For deployments to Windows machines, you can choose from the following mechanisms to specify the target machines to include in this installer deployment:
s s s
Run a command that auto-discovers the machines in a specified group or domain. Manually enter machine names or IP addresses. Enter the path to a file that lists the machines.
Regardless of which mechanism, or combination of mechanisms, you use, the machines need to be from the same domain (a domain look-up is done, not a DNS look-up). When you attempt to run the installer deployment, you are prompted for the domain administrator user name and password.
For UNIX endpoints, you cannot auto-discover targets. Either enter machine names manually or use a file that lists the machines. For either UNIX or Windows deployments, the machines in a deployment need to be from the same domain. When you later attempt to run the installer deployment, you are prompted for the domain administrator user name and password. Regardless of the method that you use to specify the machines, to identify them, you must provide either an IP address or machine name. If your endpoints use static IP addresses, you can use the fully qualified machine name (for example, machine1.acme.com). If they do not use static IP addresses, you might need to enter just the machine name (for example, machine1 rather than machine1.acme.com). It depends on the way your network is set up. If you enter multiple machine names or IP addresses, separate the names or IP addresses with commas or new lines.
Chapter 14 Creating profiles, installers, and running deployments 181
3 After you preview the list of machines in your deployment, save and name the
deployment.
TIP
When naming the deployment, use a name that indicates the type of component deployed (for example: Repeaters) and the group targeted (for example: Finance). You can also indicate the platform. For example, the deployment name can be: Win_Repeaters_Finance.
At this point, the wizard/workflow aspect of creating profiles, installers, and deployments is complete for this one infrastructure component.
NOTE
(auto-discovered machines) If you used the Auto-Discovery tab to display a list of machines, the returned list of machines includes all the machines in the domain, including Windows machines and UNIX (if the UNIX machine is running a program like Samba). The list might also include machines that use unsupported Windows platforms, such as Windows NT 3.5 machines. You cannot determine the platform the machine uses by looking at the machine list. You cannot determine from the list whether a machine already has a tuner on it. If you accidentally select a machine whose operating system is not supported for this installer, when you run the deployment, that machine fails to install the tuner.
Auto-discovery can return only machines that are currently connected to the network. If a machine is off-line, it does not appear in the machine list.
4 Create profiles for the other infrastructure components you need, and also create
installers and deployments for them. For instructions about specific profiles, refer to the following sections:
s s s
Creating a profile for a mirror or repeater transmitter on page 168 Creating a profile for a proxy on page 171 Creating a profile for a Deployment Manager endpoint on page 173

When you finish creating profiles, installers, and deployments for all the infrastructure components you need, you can run the installer deployments, as described in Running and monitoring installer deployments on page 183.
182
Running and monitoring installer deployments
Running and monitoring installer deployments

When you finish creating the installer deployment, you are taken to the Installer Deployment page, and the deployments that you created appear in the list on this page. To start a deployment, select the check box next to the deployment name, and click Start. When the installer (or installer stub) is deployed to a machine, it is placed in one of the following locations:
s
On Windows machines where a user is logged in, the installer is placed in

C:\Documents and Settings\userName\Local Settings\Temp\
On Windows machines where no one is logged in, the installer is placed in

C:\Documents and Settings\Administrator\Local Settings\Temp\
On UNIX machines, the installer is placed in /tmp
NOTE
To deploy an installer to a UNIX machine, you can send files to the machine using ftp or scp (you must have read/write permissions to the folder where the tuner is to be installed). You can run programs on the machine using telnet, ssh1, or ssh2. For Solaris 10, ssh1 is not configured by default. You must configure ssh1 and generate a host key to enable ssh1.
Credentials for starting a deployment

When providing credentials to start a deployment, you must provide domain credentials before the installer deployment can begin. The domain administrator must be a member of the local user group with administrator rights. Provide the domain administrator user name and password as follows:
s
If the machines are part of a domain (the most common case), provide the user name and password for the domain administrator. For the user name, use the format domainName\userName, where domainName is the name of the domain and userName is the domain administrators user name. For some platforms, such as Windows 2003 Server, the password cannot be left blank.
Chapter 14
183
Monitoring a running deployment
If the machines are not part of a domain (for example, they might instead be part of an NT workgroup), provide a user name and password that is accepted as the local administrator of all the machines.
Although the endpoints must be connected to the network for the deployment to succeed, users do not need to be logged in the endpoint computers.
NOTE
If the installer that you are deploying is set to run as a Windows service, it is installed to run under the endpoints local system account. (The name of the service is the name of the profile used to create the installer.) Therefore, if network access to the local system account is disabled on the endpoint, the deployment fails. In this situation, you might need to use the Setup & Deployments Installers tab to download and save the installer to disk. Then copy the installer to the endpoint and start the installer manually.
Monitoring a running deployment

When the installer deployment starts, the Deployment Status page is displayed. If necessary, you can use this page to stop the deployment or retry the machines on which the deployment failed. The Deployment Status page is refreshed every 30 seconds, but you can click the browser Refresh button to check the status more often.
NOTE
On the Deployment Status page, you can use the Refresh button to refresh the page, but for other browser pages in the CMS console, never click the Refresh button. Doing so often causes a message prompting you to resubmit the form, and then you see a page expired message. If there is a failure, check the Infrastructure Administration channel logs for information about the failure, as described in the Troubleshooting failed deployments on page 186 section.
Stopping a deployment
If you click Stop, the deployment stops after the installers are deployed to the current group of machines. For example, if your deployment includes 30 machines and you click stop a few seconds after you click Start, the deployment continues on several of the machines before it stops. This is because the deployment is started concurrently on a group of machines.
184
Determining if you have a successful deployment
Determining if you have a successful deployment

A successful deployment depends on whether you deploy a tuner installer or only the installer stub.
Tuner installer monitoring

If you did not create an installer stub when you created your deployment, when you create a deployment, you are deploying the complete tuner installer to endpoints. In this case, monitoring the deployment means monitoring whether the installer is successfully downloaded to the machine and then whether the installer executable is successfully started. It does not necessarily mean that the tuner and channels were successfully installed.
Installer stub monitoring

If you created an installer stub, which is smaller than the tuner installer, then your deployment should complete more quickly. In this case, monitoring the deployment means monitoring whether the stub file is successfully downloaded and started on the machine. When the installer stub is started, it contacts the transmitter and downloads the tuner installer and starts it. This tuner installer download is not monitored by the deployment. Regardless of whether you deploy a stub or an actual installer, the monitoring does not tell you whether the tuner was installed successfully. To find this information, run a Report Center query that returns a list of machines and their channels, as described in the next chapter. For Windows and UNIX machines, after the installer runs, the tuner starts automatically only if you configured it to do so when you created the installer. (For more information, see the online help for UNIX-specific settings.) To manually start the tuner on a UNIX machine, navigate to the directory where the tuner is installed (the default is /opt/Marimba/Tuner/), and type the following command to start the tuner:
./tuner
Chapter 14
185
Troubleshooting failed deployments
NOTE
(Platform) Deployment does not succeed on machines running an unsupported Windows operating system, such as NT 3.5 or Windows 98. For Windows XP endpoints running the Windows Firewall, you must have Printer and File Sharing enabled in the firewall exceptions list. To deploy an installer to a UNIX machine, you can send files to the machine using ftp or scp (you must have read/write permissions to the folder where the tuner is to be installed). You can run programs on the machine by using telnet, ssh1, or ssh2. For Solaris 10, ssh1 is not configured by default. You must configure ssh1 and generate a host key to enable ssh1.
Troubleshooting failed deployments

If a failure occurs, place your mouse pointer over the corresponding Failed status for the machine to view details about the failure. Typical causes of failure include connection or authentication problems. You can also check the Infrastructure Administration channel logs for information about the failure. The default location for these logs is:
s
Windows: installationDirectory\Tuner\.marimba\<profile name>\ch.X\historyXX.log
UNIX: installationDirectory/Tuner/.marimba/ws3/ch.X/history-XX.log
In these paths, ch.X specifies the channel number for the Infrastructure Administration channel. To find the channel number, refer to the map.txt file in the tuner workspace, which lists the channels and their corresponding channel numbers. You can also review Credentials for starting a deployment on page 183.
Failed deployment details

To generate additional failure details on remote deployments, you can add a debug flag by adding a debug flag to the prefs.txt file on the CMS tuner, or you can edit the Tuner Administrator settings.
Adding a debug flag to the prefs.txt file

To troubleshoot a failed deployment on a remote tuner, you must add the debug flag to the prefs.txt file on the CMS tuner.
186
Failed deployment details
To add a debug flag to the prefs.txt file on the CMS tuner 1 On the CMS tuner machine, locate the prefs.txt file. 2 Using a text editor, add the following property, and restart the tuner.
marimba.launch.javaArgs=-DDEBUGFLAGS\=REMOTEDEPLOY\=5
NOTE
If the marimba.launch.javaArgs property is already present in the prefs.txt file, append -DDEBUGFLAGS\=REMOTEDEPLOY\=5 to the property.
Editing the Tuner Administration settings to add a debug flag

To add the debug flag using the Tuner Administration, perform the following steps.
To edit the Tuner Administration settings to add a debug flag 1 From the CMS console, navigate to Applications => Infrastructure => Tuner
Administration.
2 On the Tuner Administration page, select the CMS tuner and provide the tuner
user name and password.
3 Click Edit Settings. 4 In the Tuner Administration page, click JVM from the Advanced tab. 5 Add the following text in the JVM arguments text box:
DDEBUGFLAGS\=REMOTEDEPLOY\=5
6 Click Preview and click Apply to save the settings. 7 Restart the tuner. Where to go from here
Create the installer and remotely deploy the installer.exe to the end points. If the remote deployment fails, check the infrastructure administration channel logs for debug information. The logs are located in the following locations:
Chapter 14
187
Ports used by remote deployer
(Windows) C:\Program Files\Marimba\Tuner\.marimba\<profile name>\Ch.X\

history-XX.log
(UNIX) /usr/local/Marimba/Tuner/.marimba/ws3/ch.X/history-XX.log
Failed tuner installation on Windows 2008

If you install the tuner on a Windows 2008 machine in which the required patches are missing, the installation fails and the following error message is displayed: Error processing package file : Extract To resolve this problem, apply the required patches to the Windows 2008 machine and restart the machine. When the machine restarts, the temp folder with the logged in user name is created.
Ports used by remote deployer

If the installer fails to deploy, verify that the TCP ports used by the remote deployer (445 or 139) are available.
Limitation of remote deployment on Microsoft Windows Server 2008

When Common Management Services is running on Microsoft Windows 2008 Server, the binary files of the remote deployment installer are copied in the \\windows \Temp folder instead of the c:\Temp folder.
Remote deployment on UNIX

If the installer fails to deploy or execute on remote UNIX machines, check the infrastructure administration channel's history -xx.log file. In addition, ensure that the following protocols are enabled on the remote machines:
s
SCPfor installer transfers (For execute permission, SSH or REXEC need to be configured) FTPonly for installer transfers (For execute permission, SSH or REXEC need to be configured) SSHfor execute permission
188
Stub installer failures
REXECfor execute permission
NOTE
SFTP is not supported.
These protocols are required for the following actions:

s
The Remote deployer attempts to copy the installer.bin using SCP. If SCP is not enabled on the remote machine, then the installer attempts to use FTP to copy the file to the temp directory of the remote machine. After it copies the installer, the installer executes using SSH. If SSH is not enabled, the installer executes using REXEC (Remote Exec).
Stub installer failures

If the stub installation fails to download the tuner installer to remote end points, check for error details in mrbStubError.log located in one of the following locations:
s
(Windows) C:\Documents and Settings\RemoteDeployerUserName\Local

Settings\Temp\mrbstubx\mrbStubError.log
(UNIX) /tmp/mrbstubx/
Understanding mrbapsexec errors for Windows

If you have enabled the debug flag, you can view the error codes in the infrastructure administration history -xx.log located at C:\Program Files\Marimba\Tuner\.marimba\ Marimba\ch.xx. The error codes are defined in Table 2. Table 2
Error code 101 102 103 104
mrbapsexec error codes (part 1 of 2)

Description Argument is bigger than the maximum length defined. Accumulate length of all arguments is bigger than the maximum length specified. Insufficient no. of arguments. Argument for flag A is incorrect.
Chapter 14
189
Uninstalling tuners
Table 2
Error code 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 1000 10000
mrbapsexec error codes (part 2 of 2)

Description Argument for flag C is incorrect. Argument for flag F is incorrect. Argument for flag V is incorrect. Argument for flag D is incorrect. Argument for flag E is incorrect. Argument for flag I is incorrect. Argument for flag P is incorrect. Argument for flag S is incorrect. Argument for flag U is incorrect. Invalid flag specified. The command argument is incorrect (application/file is not specified). Cannot use flag S and E together. Cannot use flag F and V together. Invalid username/password. Must use flag C with flag F and V. Flag C could be used alone. Unable to install service on remote machine. (Unable to connect to remote machine). The network path was not found or network location cannot be reached. Communication with service failed on remote computer. Failed to copy the task on remote computer. Service failed to start. The token of the task is inaccessible. Username and password are incorrect. User privileges are insufficient to execute the task. Desktop application on remote computer is inaccessible. Remote window station is inaccessible. The task failed to execute on remote system. The mrbapsexec exe is not found. Application error Deployment timed out on this machine.
Uninstalling tuners
This section provides instructions for removing tuners, their workspace directories, and root directories for BMC BladeLogic Client Automation servers such as transmitters, proxies, and Deployment Manager.
190
Uninstalling tuners
Before you begin

s
s s
To enable the Remove option in Add or Remove Programs, connect to Tuner Administration, and on the Custom Properties tab, set marimba.tuner.uninstall.allowed=true. Ensure that you are logged on to the system with administrator rights. If the tuner is running in the service mode, stop the tuner service from services.msc.
To remove tuners from Windows machines 1 Open the Add/Remove Programs applet in the Control Panel. 2 Scroll to the tuner and select it.
In the Add/Remove Programs list, the tuners name is based on the keyword (by default, the profile name) that was given to the tuner as part of the installation process.
3 Click Remove. 4 When prompted, specify whether to delete the workspace too (that is, the
.marimba\keyword\ directory).
The Add/Remove Programs applet removes the tuner and its workspace (if you specified that it should).
5 If the tuner was hosting a BMC BladeLogic Client Automation server that had its
own separate workspace, such as txroot or proxyroot, manually delete that directory.
To remove tuners from UNIX machines 1 Locate where the tuner is installed, for example:
/opt/Marimba/Tuner/
To remove the tuner from a machine where you ran the installer (to install a master transmitter or CMS console), the path is instead:
/usr/local/Marimba/Tuner/
2 Remove the associated binary files by typing the following command:

rm -rf /opt/Marimba/Tuner/
For the master transmitter or CMS console, the command is:

rm -rf /usr/local/Marimba/Tuner/ Chapter 14 Creating profiles, installers, and running deployments 191
Uninstalling tuners
3 You can also remove the workspace directory found in:

/opt/Marimba/Tuner/.marimba/keyword
where keyword is, by default, the profile name, unless you specified a particular keyword when creating the installer for this tuner. For the master transmitter or CMS console, the command is:
/usr/local/Marimba/Tuner/.marimba/ws3
To remove tuners from Solaris or Linux machines by using system packaging utilities 1 Remove the associated binary files by entering one of the following commands,
depending on whether the machine is Linux or Solaris:
s
On Linux, use the rpm command, for example, if the package name is MRBAtrans:
rpm -e MRBAtrans
On Solaris, use the pkgrm command, for example, if the package name is MRBAtrans:
pkgrm MRBAtrans
2 Remove the associated workspace directory that you specified at installation time.
192
Part
Part 4
Upgrade
This part presents the following chapters. The appendices listed on this page also contain upgrade information. Chapter 16 Preparing for the upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Chapter 17 Upgrading transmitters and proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Chapter 18 Upgrading the CMS console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Chapter 19 Upgrading Report Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Chapter 20 Upgrading Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Chapter 21 Installing or upgrading Patch Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Chapter 22 Upgrading Deployment Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Chapter 23 Updating endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Appendix C Manual database schema installation and updates . . . . . . . . . . . . . . . . . . . . . . . . . 333
Part 4
Upgrade
193
194
Chapter
14
Verifying that BMC BladeLogic Client Automation is set up correctly

14
After running installer deployments on the machines in your BMC BladeLogic Client Automation environment, you can run a Report Center report to confirm the infrastructure components were successfully installed. Using Report Center to run a report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Using Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Whats next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 To create a Ghost image of a Windows machine to deploy your tuners and the Scanner Service channel to endpoints, see Appendix B, Using a ghost image to deploy product modules.
Using Report Center to run a report

This procedure describes how to perform a query to verify that all machines with the Scanner Service are inventoried correctly.
Before you begin

Ensure that you have installed the infrastructure components and that the Scanner Service on each machine has sent data at the scheduled time.
To query for all tuners 1 On the main Query View page of Report Center, click the Builder icon. 2 In the New Query page that appears, from the Select Category list, select Tuners. 3 From the Search for list, select Tuner.
Chapter 14 Verifying that BMC BladeLogic Client Automation is set up correctly 195
Using Help
4 From the for which list, select Tuner ID. 5 Select the equal sign (=) from the relationship list. 6 Type an asterisk (*) in the search value text box.
The asterisk wildcard character tells Report Center to search for all tuners.
7 Click Preview Results.

The generated report displays a list of all the tuners in your system.
Using Help
BMC BladeLogic Client Automation Help is context sensitive. The first time you click Help, the console displays a security warning that prompts you to install and run an applet that has been code-signed by Quadralay Corporation. If you dont install the applet, the help system works, but some functionality is not available.
Whats next?
This guide describes the minimum configuration tasks required to install BMC BladeLogic Client Automation. You must configure the system settings immediately after installation and before using the applications. Use the CMS console to review these additional configuration options:
s
Console configuration options. The console system settings enable you to set
configurations in the following areas: General settings. These settings include options for configuring the inactive user timeout, the browser access port number and host name, and log file rolling policies. User authentication settings. These settings determine how users are authenticated when they log in to the console. These include options for configuring the type of user authentication that you want to use, the local user database, user role mapping, and the emergency administrator password. Data source settings. These settings specify the sources where the applications get and store data. These include options for configuring the directory services and databases that you want the applications to use.
196
Whats next?
Configuration settings for collecting inventory scans and log files. As was mentioned
in Configuring the inventory and logging plug-ins on page 109, you can configure how inventory scans are done and the endpoint log data that you want to collect. For step-by-step instructions, see the BMC BladeLogic Client Automation Report Center Guide.
s
Creating policies. In addition to configuring Policy Manager and the Policy Service
plug-in, as mentioned in Chapter 9, Setting up Policy Management, you can create policies. The step-by-step instructions for all of these tasks are provided in the BMC BladeLogic Client Automation Policy Management Guide.
s
Using Deployment Manager. To use the Deployment Manager product family, you create deployment jobs that package and deploy content and applications to your endpoints. For instructions, see the BMC BladeLogic Client Automation Deployment Manager Guide.
Chapter 14 Verifying that BMC BladeLogic Client Automation is set up correctly
197
Whats next?
198
Chapter
15
Integrating tuner installation with OS provisioning

15
After creating the installers that you run to install the software agent (tuner) on the machines in your company, you can configure these installers as part of operating system (OS) provisioning. Integrating tuner installation with OS provisioning is useful when you have a number of new machines on which you need to install both the OS and the tuner. You can generate a script insert that enables you to automatically install and run the tuner after the OS provisioning. You can also quickly provision the new machines with applications by specifying a machine or group of machines that you want to use as a model. Overview of the tuner integration with OS provisioning . . . . . . . . . . . . . . . . . . . . . . Tuner installers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OS provisioning tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy group model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Custom keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Script inserts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifying the OS provisioning method to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Image-based method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scripted installation method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview steps for provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites for provisioning machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installed and configured the BMC BladeLogic Client Automation system . . . . Created profiles and installers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating the script insert for provisioning machines. . . . . . . . . . . . . . . . . . . . . . . . Using the script insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HP Ignite-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IBM Network Install Manager (NIM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Red Hat Linux Kickstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solaris Jumpstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unattended Windows 2000/XP/2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the script insert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HP Ignite-UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IBM Network Install Manager (NIM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrating with Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 15 Integrating tuner installation with OS provisioning
200 200 200 201 201 202 202 202 202 203 203 203 204 205 207 208 208 209 209 210 207 208 208 210
199
Overview of the tuner integration with OS provisioning
Reboot behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Overview of the tuner integration with OS provisioning

Integrating the software agent (tuner) installation with OS provisioning involves the following items:
s s s s s
Tuner installers OS provisioning tools Policy group model Custom keywords Script insert
Tuner installers
When you create an installer, you select a profile and specify various installationspecific settings, such as whether you want the installation to be invisible to end users, and the location to install the software on the machine. When you finish creating the installer, you have an executable that you can deploy to the machines in your enterprise. You must create a different installer for each profile. The installers are saved in the Infrastructure Administration channels data directory, for example:
c:\Program Files\Marimba\Tuner\.marimba\<profile name>\Ch.X\data\ persist\ installermanager\installers\winnt\myInstaller.exe
OS provisioning tools
OS provisioning tools enable administrators to install an operating system on a new machine and configure required settings and applications. Some examples of OS provisioning tools are:
s s s s s
HP-UX Ignite IBM Network Install Manager Red Hat Linux Kickstart Solaris Jumpstart Unattended Windows 2000/XP/2003
200
Policy group model
Ensure you are familiar with the OS provisioning tool that you are using before installing the operating system and the tuner.
Policy group model

With the Policy Management product, you can choose groups (of users or machines) from the directory service and assign them policies that determine the applications that get installed for them. You can take advantage of these existing policies when provisioning new machines. On the Policy Groups tab of the Install Tuner with the OS page, you can identify the groups in the directory service with a policy that you want to use as a model for the new machines. After you install the tuner along with the operating system, applications (and other information) assigned to the groups that you identified are installed on the new machines also. Using policy groups as a model enables you to quickly provision new machines with the required applications and content. This reduces the latency that is usually associated with waiting for Inventory and Policy Management to run, collect information, and apply policies to the new machines. The item that you use as a model might be any object in the directory service that has a policy assigned. It might be a single machine or user, a group of machines or users, a container, an organizational unit, and so on. For more information about Policy Management, see the BMC BladeLogic Client Automation Policy Management Guide, available on the BMC Customer Support website.
Custom keywords
Custom keywords are properties and values that you can assign to target machines. These keywords are stored as tuner properties on the target machines. After the machines are provisioned, you can use Inventory and Report Center to create collections of machines that have a particular custom keyword. For example, during provisioning, you can assign the custom keyword webserver a machine. In Report Center, a collection has been created to find all the machines that have the corporate keyword webserver. This collection is used to define a group named Webservers. This group is assigned a policy that defines a set of required applications. The next time collections run, the machine that you just provisioned is picked up as a new member of the Webservers group and is managed as part of the group in the future.
Chapter 15
201
Script inserts
Script inserts
The script insert you generate can be added to the OS provisioning script or configuration file that you use with your OS provisioning tool. The script insert contains commands for the following actions:
s
After the OS is installed, install the tuner. If a policy group was specified, get the policy for the target machine and install the applications (and other information) associated with the policy. If custom keywords were specified, apply the keywords to the target machine so they are available for Inventory to gather.
It also contains instructions for using the script insert.
Identifying the OS provisioning method to use

To provision machines with tuners, use one of the following methods.
Image-based method
With the image-based method, you use a tool like Ghost to create system snapshots (or images) that contain a complete OS and applications environment. You apply the image to the machines that you want to provision. In this method, you can include the tuner with the image so that it is installed when you apply the image containing the OS. For more information, see Appendix B, Using a ghost image to deploy product modules.
Scripted installation method

With the scripted installation method, you use a tool to install an operating system on the machines that you want to provision. You provide the tool with a script that specifies the configuration and options for the provisioned machines. In this method, you can include instructions in the script for installing and running the tuner immediately after OS installation.
202
Overview steps for provisioning
Overview steps for provisioning

The following steps provide a high-level view of OS provisioning:
1 Provision the tuner along with the operating system. 2 The tuner is installed and starts running. 3 Policy Service updates and applies the policies as determined by the policy groups
that you specified. Policy Service triggers Scanner Service.
4 Scanner Service runs and sends the custom keywords that you have specified to
the database.
5 The machine is provisioned with the specified applications and managed by BMC
BladeLogic Client Automation.
Prerequisites for provisioning machines

Before you provision machines using the scripted installation method, ensure that you meet the following prerequisites.
Installed and configured the BMC BladeLogic Client Automation system

You must have the 7.0.x or later versions of the following channels:
s
Common Management Services (CMS) Infrastructure Administration Policy Manager Ensure you select the check box for modeling on the Policy Service Plug-in page before you publish the Policy Service plug-in. To validate policy groups against a directory service, ensure you configure the directory service in Console => System Settings.
Policy Service
Chapter 15
203
Created profiles and installers
Report Center Scanner Service Schema Manager Ensure you install or upgrade the required schema for the database (Inventory/Report Center) and the directory service (Policy Manager).
Tuner You must set the marimba.inventory.onramp.scan tuner property to true to allow the Scanner Service to scan custom keywords.
Created profiles and installers

When you create profiles and installers, ensure that you select the following options:
s
Installers should be configured for silent installation, so that they can run without requiring user interaction. You must use regular installers, not stub installers. Stub installers cannot be used to integrate tuner installation with OS provisioning. When creating installers, you must include the Scanner Service and Policy Service channels. For Policy Service, ensure you select Start this channel when the tuner is launched for the first time. Do not select Update the channel before running for the first time. For Linux platforms, select Start the tuner upon machine startup. For Windows platforms, ensure the installer name uses the DOS 8.3 format. For the profile, you can configure the following options under the Security tab: Remote Administration in case you want to remotely administer the tuners you are installing on the provisioned machines Trusted Transmitters so that the provisioned machines can subscribe to the applications as specified in the policy groups
204
Generating the script insert for provisioning machines

You must generate a script insert that you can add to the OS provisioning script or configuration file that you use with your OS provisioning tool. The script insert contains commands for performing the following actions:
s
After the OS is installed, install the tuner. If a policy group was specified, get the policy for the target machine and install the applications (and other information) associated with the policy. If custom keywords were specified, apply the keywords to the target machine so that they are available for Inventory to gather.
It also contains instructions for using the script insert.
NOTE
Before you generate the script insert, ensure that you have met the prerequisites described in Prerequisites for provisioning machines on page 203.
To generate the script insert 1 Log in to the CMS console. 2 Click the Installers tab. 3 From the list of available installers, choose the installer to provision to the target
machines.
4 Click Install with OS.

This option is not available in the following situations:
s s
You have not selected an installer. You chose an installer for an unsupported platform.
5 Identify the third-party provisioning service to use to install the operating system.
The available provisioning services depend on the operating system associated with the installer you chose. For example, if you chose an installer created for Solaris, then Solaris Jumpstart is available as a provisioning service.
Chapter 15
205
6 On the Policy Groups tab, specify policy groups to use as models when
provisioning the target machines. For more information, see Overview of the tuner integration with OS provisioning on page 200. To identify the policy group, use one of the following formats:
s
The fully qualified distinguished name (FQDN) For example, cn=group1,ou=groups,dc=company,dc=com or cn=group1,ou=groups,dc=company,dc=com, cn=group2,ou=groups,dc=company,dc=com, cn=group3,ou=groups,dc=company,dc=com
A relative distinguished name (RDN) For example, group1 or group1,group2,group3
NOTE
Use commas to separate group names. If a group name contains either a comma or a space, it must be enclosed in double quotation marks. If a group name contains double quotation marks, the quotation marks need to be escaped using a backslash. The wildcard character * is not valid.
7 Click Validate to verify that the names you entered are valid groups in the
directory service.
The following is displayed in the Validation Results table: the FQDN for the unique entry Unrecognized Entry Non-unique Entry
If the name you entered is... Found in a unique entry in the directory service Not found in the directory service Found in multiple entries in the directory service
Validation is optional. Even if the names you enter cannot be validated as unique entries, you can still choose to use them in your script insert. There are situations when you cannot validate the policy groups you want to use. For example, if you are in a testing environment and the actual policy groups exist only in the directory service in the production environment. For this reason, even if the names you entered cannot be found in the directory service (that is, they are marked with Unrecognized Entry), you can still include them when you generate the script insert. However, when multiple entries are found for the name you entered (that is, they are marked with Non-unique Entry), choose the entry to use by clicking Resolve Conflict and choosing one from the provided list. You cannot generate the script insert until you choose a single entry.
206
Using the script insert
If you skip validation and generate a script insert without validating the names you entered, ensure you enter FQDNs for the policy groups that you want to use as models.
8 On the Custom Keywords tab, enter custom keywords to specify for the target
machines:
A Click Add to add a new row in the Custom Keywords table. B In the new row, enter the name and value for the custom keyword.
The custom keywords to which you can assign target machines are stored as tuner properties and values on the target machines. They are added to the tuner properties.txt file after the tuner is installed, and the property names are identified with the prefix osm.ckw. After the machines are provisioned, you can use Inventory and Report Center to create collections of machines that have a particular custom keyword. For more information about creating collections, see the BMC BladeLogic Client Automation Report Center Guide, available on the BMC Customer Support website. There is no validation for custom keywords, so be careful and avoid spelling errors.
9 Click Generate Script Insert.

After you successfully generate the script insert, you can download the installer and a text file that contains the script insert from the Download Script Insert page. You can also copy the script insert from the text area on this page and paste it into your OS provisioning script or configuration file. For more information, see Using the script insert.
WARNING
Ensure you download the installer and script insert file (or copy the script insert) before you leave the Download Script Insert page. After you leave this page, the OS provisioning script insert that you generated is no longer available.
Using the script insert

After you successfully generate the script insert, you can download the installer and a text file that contains the script insert from the Download Script Insert page. You can also copy the script insert from the text area on this page and paste it into your OS provisioning script or configuration file.
Chapter 15
207
HP Ignite-UX
The script insert includes comments and instructions for using the script insert with the OS provisioning tools. In most cases, follow the instructions included in the script insert to save the tuner installer file to the appropriate directory. Also, ensure that you have sufficient file permissions and disk space on the machines that you are provisioning.
HP Ignite-UX
Ignite-UX enables you to specify the kernel parameters you want to set and the usersupplied scripts you want to run as part of the session. Many different script hooks are provided so you can add your own customizations during and after the installation.
To use the HP Ignite-UX script insert 1 Copy the generated script insert and paste it into the post-customization script file. 2 In the post-customization file, enter all the required information, which might
include the NFS server IP address, the export directory path, and the mount point on the endpoint. As an alternative, you can copy the generated script insert file to the following location on the HP-UX machine: /var/opt/ignite/scripts. To make the script insert file available under all configurations, edit the INDEX file found at the following location on the HP-UX machine: /var/opt/ignite. Add the following line at the end of the end of the INDEX file:
Scripts {/var/opt/ignite/scripts/hpux_script}
where hpux_script is the name of the generated script insert file.
IBM Network Install Manager (NIM)

NIM enables a cluster administrator to centrally manage the installation and configuration of AIX and optional software on machines within a network environment.
208
Red Hat Linux Kickstart
To use the IBM NIM script insert 1 Copy the generated script insert and paste it into the post-customization script file
that runs once after NIM installation. The customization script might be in the following directory: /export/nim.
2 In the post-customization file, enter all the required information, which might
include the NFS server IP address, the export directory path, and the mount point on the endpoint.
Red Hat Linux Kickstart

With Kickstart you can automate a Red Hat Linux installation by creating a single file that contains the answers to all the questions that are normally asked during a typical Red Hat Linux installation. For more information, see the Red Hat Linux Customization Guide.
To use the Kickstart script insert 1 Copy the generated script insert and paste it into the Kickstart configuration or
post-customization file, usually named ks.cfg. Ensure you paste the script in to the section %post of the Kickstart file.
2 In the configuration or post-customization file, enter all the required information,

which might include the NFS server IP address, the export directory path, and the mount point on the endpoint.
Solaris Jumpstart
The Jumpstart feature is an automatic installation process available in the Solaris operating environment. It enables system administrators to categorize machines on their network and automatically install systems based on the category to which a system belongs. Copy the generated script insert and paste it into the post-installation script file that runs after the OS installation. The post-installation or customization script file might be in the Jumpstart directory.
Chapter 15
209
Unattended Windows 2000/XP/2003
Unattended Windows 2000/XP/2003

1 Create a new batch (.bat) or .cmd file. Ensure the file name does not exceed eight
characters.
2 Copy the generated script insert and paste it into the new file that you just created. 3 Edit the file CMDLINES.TXT, and add the name of the .bat or .cmd file, enclosed by
double quotation marks. You add the .bat or .cmd files name so that the file is called when Windows Setup parses the file CMDLINES.TXT.
NOTE
If you cannot find the file CMDLINES.TXT, create it.
4 Place the .bat or .cmd file under the directory $OEM$. NOTE
Ensure that the appropriate graphics drivers are included when you provision the Windows operating system. Otherwise, the newly installed tuner might not run properly.
Integrating with Policy Management

Specifying policy groups as models enables you to quickly provision new machines with the required applications and content. This reduces the latency that is usually associated with waiting for Inventory and Policy Management to run, collect information, and apply policies to the new machines. After the tuner is installed on the newly provisioned machine, Policy Service runs and sends a request to the plug-in for the policies assigned to the specified policy groups. When the plug-in sends the policies, Policy Service applies them to the machine. Policy Service then considers this machine provisioned.
NOTE
Although Policy Service applies these policies during provisioning time, it no longer manages them after it considers the machine provisioned. After this time, to manage the machines policies, you must add the machine to the directory service and then use Policy Manager to assign it a policy.
210
Reboot behavior
For more information about Policy Management, see the BMC BladeLogic Client Automation Policy Management Guide, available on the BMC Customer Support website.
Reboot behavior
Because you can force a machine to reboot after installing particular applications, a new property called reboot.immediate is introduced. Set this property in the parameters.txt file in the package directory before publishing the packaged application.
s
If you set reboot.immediate to true, Policy Service forces the machine to reboot after installing the packaged application. If reboot.immediate is not set to true, Policy Service waits until all the packaged applications have finished installing before rebooting the machine.
Chapter 15
211
Reboot behavior
212
Chapter
16
213 214 215 216 216 218 219 220 223 224 224 225 225 226 227 228 229
16
Preparing for the upgrade

This chapter describes the preparatory tasks to perform before you begin the upgrade process. Supported upgrade paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of the upgrade process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying that you can log in as a primary administrator . . . . . . . . . . . . . . . . . . . . . . Backing up workspaces and databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing for the transmitter upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing for database schema upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disk space requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing for the Report Center upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing for the Patch Management upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying disk space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Saving patch edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Printing repository and Patch Service configuration settings . . . . . . . . . . . . . . . Changing the update schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Archiving the channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading channels from an earlier release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Whats next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supported upgrade paths

Before upgrading the product, refer to the Release Notes for information about the supported upgrade paths and any known issues that might affect the success of the upgrade.
Chapter 16 Preparing for the upgrade
213
Overview of the upgrade process
Overview of the upgrade process

To complete the upgrade, perform all the tasks listed in every chapter of the Upgrades part of this book in the order presented, skipping chapters that do not apply to your environment. You can upgrade your enterprise in phases, keeping certain groups of endpoints on an older version until you are ready to upgrade them. You can upgrade all products at one time, or you can pause at specified points. The places where you can stop are indicated in the procedure by <pause>.
1 Prepare for the upgrade, as described in Chapter 16, Preparing for the upgrade. 2 Upgrade the transmitter infrastructure from the master transmitter outwards. The
order is usually master transmitter, mirrors, repeaters, and then proxies; however, if there are proxies between the master transmitter and the repeaters, upgrade those proxies before the repeaters. For each machine in the infrastructure, update the tuner and then update the transmitter. See Chapter 17, Upgrading transmitters and proxies. <pause>
3 Upgrade the CMS console, as described in Chapter 18, Upgrading the CMS
console.
A Update the tuner hosting the CMS console.

<pause>
B Complete the preparation work. C Update the CMS channel on the CMS console.
The console hosts the rest of the Web applications.
D Update the Infrastructure Administration channel.

The channel handles updates and installations.
E Upgrade the Schema Manager application, as described in Upgrading Schema

Manager module on page 256.
4 In the Inventory module, upgrade Report Center and the plug-ins, as described in
Chapter 19, Upgrading Report Center.
5 To upgrade the Policy Management module, upgrade Policy Manager and the
Policy plug-in, as described in Chapter 20, Upgrading Policy Management.
214
Creating a test environment
<pause only if you use Deployment Manager and not Patch Management>
6 To upgrade the Patch Management module, update the existing Patch

Management channels and add the new Patch Source channels. See Chapter 21, Installing or upgrading Patch Management. If you did not purchase the Patch Management module, skip this step.
7 Enable inventory and Logging Service, as described in Updating Report Center

and the Inventory and Logging plug-ins on page 268. <pause>
8 To upgrade Deployment Manager, upgrade the tuner on the Deployment Manager

machine, and then upgrade the Deployment Management and Deployment Management Command Line channels, as described in Chapter 22, Upgrading Deployment Manager.
9 For endpoints, upgrade the Infrastructure Service and then install or upgrade the
following channels as necessary: Scanner Service, Policy Service, Deployment Service, Content Replicator, and Patch Service. See Chapter 23, Updating endpoints.
NOTE
The Infrastructure Service channel may be upgraded on endpoints before the rest of the channels, such as Scanner Service.
Creating a test environment

The components in your test environment should be representative of the systems and environments throughout your company. Tailor the test environment to include any site-specific settings or any customizing you did on the channels or to represent any complex deployment architectures. Review the hardware and software requirements in the BMC BladeLogic Client Automation Release Notes document and Chapter 5, Before you install to set up a test environment that meets those requirements. Use this environment to test the upgrade process. Refer to the Release Notes for any known issues that might affect the success of the upgrade.
215
Verifying that you can log in as a primary administrator
The database upgrade process might affect local customizations or optimizations. A test environment helps to ensure that local customizations and optimizations are still working after an upgrade.
Verifying that you can log in as a primary administrator

The following roles determine the capabilities of users when they log in to the CMS console.
s
Primary administrators have access to the system settings and all the configuration settings for particular applications. Primary administrators can also specify standard administrators who have specific access control functionality. Standard administrators can perform most tasks in the applications, but they cannot access systems settings or configuration settings. However, if a primary administrator gives a standard administrator permission for access control functionality, this standard administrator can access the access control functionality of system settings. Operators can log in to some applications and perform certain tasks, but they cannot make changes in the applications. (Operators cannot log in to the 6.x Policy Manager, Setup & Deployment, Transmitter Administrator, Proxy Administrator, Schema Manager, or System Settings.)
Because the process of upgrading often involves using system settings and checking or changing configuration settings, you must be able to log in to the CMS console as a primary administrator. To determine your user role, place the mouse pointer over the Status button in the top right corner of the console. For more information, see the chapter about user authentication and roles in the BMC BladeLogic Client Automation CMS and Tuner Guide.
Backing up workspaces and databases

Before you begin to upgrade the componentstransmitters, proxies, Deployment Manager, CMS console, and third-party storesor before you uninstall a previous version of the product, make backup copies of the workspaces and directories.
216
Backing up workspaces and databases
Your specific situation determines what to back up. For example, if you have repeaters that you cannot access because they are behind a firewall, you can back up only the master transmitter workspace and then, if you must reinstate the workspace, let the mirrors and repeaters replicate according to their usual schedule. You should also back up any other workspaces that contain information you configured and do not want to recreate, such as the tuner, Deployment Manager, and console. For example, backing up the console saves any Installers you created. Make backup copies of the following workspaces and directories:
s
Tuner workspace directory for the machine that hosts the BMC BladeLogic Client Automation server. The security certificates are stored in this directory. For more information, see To back up a tuner workspace on page 217. Transmitter workspace directory (including mirror or repeater transmitters and their master transmitters; transmitter extensions). To use the Transmitter Administrator Identification tab to determine the location of the workspace, see the procedure listed later in this section. Proxy workspace directory. Alternatively, you can save the proxy configuration by backing up the properties.txt file in the proxy workspace. Module databases. CMS console directory. When you back up a tuner workspace, you also back up the workspaces for these products. (Configuration settings for Report Center are stored in a database and not in the workspace.) Deployment Manager root directory. To determine the location, in Deployment Manager, click the Settings tab, and then click Set Root Directory. You can also use the -getRoot option of the command-line interface. These settings are documented in the BMC BladeLogic Client Automation Deployment Manager Guide and the BMC BladeLogic Client Automation Package Deployment CLI Guide, respectively.
Store these backup files in a clearly labeled directory or removable media, such as a CD.
To back up a tuner workspace 1 Verify the location of the tuner workspace by choosing Applications =>
Infrastructure Administration => Tuner Administration.
2 Stop the tuner.
217
Preparing for the transmitter upgrades
WARNING
If you do not stop the tuner, the backed-up workspace might not function correctly when restored because of file content interdependencies.
3 Make backup copies of the tuner workspace directory.

On Windows, if you use the default directory for the tuner workspace, use:
c:\installationDirectory\tuner\.marimba\keyword
If you changed the directory, use the new path. On UNIX, the default is $MARIMBAROOT/.marimba/keyword. If $MARIMBAROOT is not defined, it defaults to the login directory. If you changed the directory, use the new path.
4 Start the tuner.

Repeat this procedure for the other machines on which you want to back up workspaces.
To restore workspaces
s
Manually restore each workspace you backed up. Or
For transmitters, restore the master transmitter and let the mirrors and repeaters follow their replication schedule.
Preparing for the transmitter upgrades

If you are upgrading a set of mirror or repeater transmitters as a group, you can use tuner profiles to ensure that tuner and transmitter settings within groups are consistent.
218
Preparing for database schema upgrade
Preparing for database schema upgrade

Your plan for the database schema upgrade should include the following phases:
s s s
Create a backup of the database prior to upgrade. Perform the database schema upgrade. Perform the following post-upgrade tasks: Create a backup of the upgraded database. Apply post-upgrade adjustments. For example, shrink the database files to remove excess space needed for the upgrade process and review the upgraded database to ensure any tuning of the database prior to upgrade is still in effect. You might need to re-tune the database. Create a backup of the re-tuned database. After completion of schema upgrade for all the modules, it is recommended to rebuild the database indexes.
NOTE
When you use SQL Server, if there is a mismatch of collation specification between invdb and the tempdb temporary database on the database instance, then schema upgrade fails. Hence, while using SQL Server environment, you must ensure that both the invdb and the tempdb are of the same collation specification.
NOTE
If an error occurs while upgrading a database, you must restore the earlier database completely before retrying the upgrade. A complete database restoration occurs only when you can productively use the earlier versions of the applications against the restored database.
You must perform the following tasks for the invdb database for SQL Server and the Inventory and DBtree schemas for Oracle:
s
Create a full database backup. Ensure that enough disk space is available. For details, see Disk space requirements on page 220. For each customized extension or third-party application that integrates with nonBMC BladeLogic Client Automation products, create a database backup and run disk space checks.
219
Disk space requirements
For custom tables, BMC BladeLogic Client Automation does not upgrade queries in the Query Library, views, procedures, functions, triggers, scheduled jobs, and other database objects. You must assess these items in each custom table and any impact on the upgrade. The CHAR and VARCHAR data type data lengths can contain a maximum of 2,000 characters for Oracle and 4,000 characters for Microsoft SQL Server. You assess now how much work is involved because you must change these items manually after the upgrade.
s
Disable the inventory service plug in and policy service (See Preparing for the Report Center upgrade on page 223), Patch Management, and Policy Management. You do not want any scheduled updates to start. To prevent scheduled updates from occurring during the upgrade, change the Patch service update schedule to a time that is outside of the upgrade window.

Use the information in this section to calculate the required disk space for the database upgrades.
Inventory database space requirements

For the Inventory database upgrade, the disk space requirements by file type are provided in Table 1: Table 1
File DATA files: original-single byte, temporary backup tables-single byte, and final-double byte INDEX files: original-single byte, temporary backup tables-single byte, and final-double byte Transaction log
Disk space requirements for database upgrade (part 1 of 2)

Amount of space required If the maximum size is not configured to unlimited, add 50% more space to the existing size. If the maximum size is not configured to unlimited, add 50% more space to the existing size.
s
SQL Server: Allow twice the size of the largest table (If the maximum file size not unrestricted growth but restricted with a limit). Oracle UNDO log: If the maximum size is not set to unlimited, add 50% more space to the existing size. The size of the UNDO logs depend on system configuration and can vary among systems.
TEMP tablespace (Oracle only)
(Oracle only) Add 50% more space to the existing size
220
Table 1
File
Disk space requirements for database upgrade (part 2 of 2)

Amount of space required Add 25% more space to the existing size if the maximum size is not configured to unlimited. If the maximum size is not configured to unlimited, add an additional 50 MB. If the maximum size is not configured to unlimited, add an additional 50 MB.
System files DM_DBTREE_DATA file DM_DBTREE_INDEX file
Table 2 contains the specific files names for the databases. Table 2
File Microsoft SQL Server
Database file names

File name
DATA files INDEX files Transaction log System database file

Oracle
btreegroup1, invgroup1, logginggroup1, patchgroup1, dm_dbtreegroup1 dbtreegroup2, invgroup2, logginggroup2, patchgroup2, dm_dbtreegroup2 invlog invdbsys INV_DATA, INV_DATA2, LOG_DATA, PATCH_DATA, DBTREE_DATA, DM_DBTREE_DATA INV_INDEX, INV_INDEX2, LOG_INDEX, PATCH_INDEX, DBTREE_INDEX, DM_DBTREE_INDEX UNDOTBS1 TEMP SYSTEM, SYSAUX, USERS
DATA tablespaces
INDEX tablespaces
Transaction log (UNDO tablespace) TEMP tablespace System tablespaces
Planning for growth

The disk space used after the migration is the same as the disk space used during the migration. However, the actual used database storage space is much less than the allocated disk space. On both Oracle and Microsoft SQL Server, the files are manually managed and are reduced in size only after you perform a shrink operation. For planning the capacity growth after the migration, the disk space requirements by file type are provided in Table 3:
221
Table 3
File
Database file space requirements

Amount of space required If the maximum size is not configured to unlimited, add 50% more space to the existing size. If the maximum size is not configured to unlimited, add 50% more space to the existing size.
DATA files: growth INDEX files: growth
Deployment Manager space requirements

Table 4 contains the disk space requirements for each file. Table 4
File name Microsoft SQL Server DATA files logginggroup1 dm_dbtreegroup1 INDEX files logginggroup2 If the maximum size is not configured to unlimited, add 50% more space to the existing size. 50 MB Allow twice the size of the largest table (If the maximum file size not unrestricted growth but restricted with a limit) If the maximum size is not configured to unlimited, add 50% more space to the existing size.
Disk space requirements for specific file names

Space requirements
50 MB
dm_dbtreegroup2
Transaction log: invlog Oracle DATA tablespaces LOG_DATA DM_DBTREE_DATA
If the maximum size is not configured to unlimited, add 50% more space to the existing size 50 MB If the maximum size is not configured to unlimited, add 50% more space to the existing size
INDEX tablespaces
LOG_INDEX DM_DBTREE_INDEX Transaction log (UNDO tablespace)
50 MB
If the maximum size is not configured to unlimited, add 50% more space to the existing size (The size of the UNDO tablespace depends on system configuration and can vary among systems.)
222
Preparing for the Report Center upgrade
Preparing for the Report Center upgrade

Before you start the upgrade process, you need to disable or change the plug-in schedules so that they do no attempt to update the endpoints during the upgrade process. When the upgrade process is finished, you will need to reset these schedules to their original times. Ensure that you print the current configuration settings so you have a record of them. In the Report Center update procedure, you verify these settings with the updated ones, and then enable the plug-ins.
NOTE
If the Inventory and Logging plug-ins are replicated to mirrors and repeaters, you must wait for the settings that disabled the plug-ins to be replicated.
To disable the inventory plug-in 1 Log in to the CMS console as a primary administrator. 2 Access the Inventory Configuration (Plug-in) page: A Choose Applications => Report Center. B Select the Configuration tab. C Click Inventory Configuration. D On the Inventory Plug-In to Configure page, type a plug-in, or select a plug-in
URL, and click OK.
3 From Set plug-in state, select Disable. 4 Click Preview, and click Save & Publish. To change the schedule for the logging service plug-in 1 Log in to the CMS console as a primary administrator. 2 Access the Logging Configuration (Plug-in) page: A Choose Applications => Report Center. B Select the Configuration tab. C Click Logging Configuration.
223
Preparing for the Patch Management upgrade
D On the Logging Plug-In to Configure page, type a plug-in, or select a plug-in

URL, and click OK.
E On the Plug-in tab, select the Endpoint tab. F Either print the page or make a note of the current schedule settings. 3 Under Log Collection Schedule, select a time that is outside of the upgrade window. 4 Click Preview, and click Save & Publish.
Preparing for the Patch Management upgrade

Before you upgrade Patch Management, complete the following tasks:
s s s s
Verifying disk space Saving patch edits on page 225 Printing repository and Patch Service configuration settings on page 225 Changing the update schedules on page 226
Verifying disk space

For the Patch Management upgrade, you need 2.5 times the current size.
s
For the AIX platform, the amount of disk space needed depends on the operating system and minimum maintenance level, but in general, you need about 1 to 3 GB. For the Red Hat Enterprise Linux platform, the amount of disk space needed depends on the number of channels, but in general, you need about 3 to 12 GB.
For planning the capacity growth after the migration, you need about 1.5 times the current growth for the Solaris and Windows platforms. Specific files names follow:
Microsoft SQL Server

s s s
DATA files: dbtreegroup1, patchgroup1 INDEX files: dbtreegroup2, patchgroup2 Transaction log: invlog
224
Saving patch edits
Oracle
s s s
DATA tablespaces: PATCH_DATA, DBTREE_DATA INDEX tablespaces: PATCH_INDEX, DBTREE_INDEX Transaction log (UNDO tablespace): UNDOTBS1
Saving patch edits

Before upgrading, save the edits that you made to patches in earlier versions. If you do not save edits, they are discarded when you rebuild the repository after the upgrade.
To save patch edits 1 Log in to the CMS console as a primary administrator. 2 Choose Applications => Patch Manager. 3 On the Patch Repository page, choose File => Export/import patch metadata. 4 Click Export revised patch metadata. 5 Click Save to save the patch_metadata.xml file to a local directory.
You can then transfer the file to another database.
NOTE
If the file is empty, you did not have any edits and can delete the file.
6 Click Cancel to return to the Patch Repository page.
Printing repository and Patch Service configuration settings

Print the current repository and Patch Service configuration settings so you have a record of them. In the Patch Management update procedure, you verify these settings with the updated ones.
225
Changing the update schedules
To print the configuration settings 1 Log in to the CMS console as a primary administrator. 2 Go to the Repository Configuration page. A Choose Applications => Patch Manager. B Click the Configuration tab. C Click Repository. D Print the browser page. 3 Go to the Patch Services Configuration page. A Click the Configuration tab. B Click Patch Services. Enter or select a URL and then click OK. C Print the browser page.
Changing the update schedules

To avoid updates from occurring during the upgrade process, you need to modify the update schedules to a time after the upgrade period. When the upgrade process is finished, you can reset the upgrade schedules.
To change the Patch service update schedule 1 Log in to the CMS console as a primary administrator. 2 Access the Repository Configuration page: A Choose Applications => Patch Manager. B Select the Configuration tab. C Click Repository. 3 In the Repository update schedule section, click Modify, and select a future date. 4 Click Save.
226
Archiving the channels
To change the tuner profile update schedule 1 Log in to the CMS console as a primary administrator. 2 Access the Profiles page: A Choose Applications => Infrastructure => Setup & Deployment. B Select the Profiles tab. 3 On the Profiles page, select a profile, and click Edit. 4 On the Edit Profiles page, select the Tuner/Profile Updates tab. 5 Change the update schedule to a time past the time of the upgrade window. 6 Click Preview, and click Apply.
Archiving the channels

Before you begin copying new products to the master transmitter, move the old BMC BladeLogic Client Automation channels to an archive location. The tools used in the following procedure include Tuner Administrator and Transmitter Administrator. You can access information about these tools either by clicking the Help button in the product, or by reviewing the BMC BladeLogic Client Automation CMS and Tuner Guide. Perform these upgrade tasks first in a test environment.
To archive old channels 1 On the master transmitter, log in as a primary administrator. 2 Log in to Transmitter Administration. A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
necessary, enter the remote tuner admin user name and password.
C Click Manage Channels.
227
Upgrading channels from an earlier release
3 Archive all the BMC BladeLogic Client Automation channels that you are
currently using by copying the folder named Current or from the folder in which you have stored the channels for implementation.
A Click Add a Channel. B In Source URL, enter the path to the Marimba Current folder or click Browse and
select the Current folder. Do not include a channel name. This step copies every channel in the source folder to the destination folder, creating the destination folder if necessary.
C In Destination path, type /Marimba/Archive or another path indicating where you

want to place the archive.
D Copy the entire folder.

Because you are copying rather than moving the existing channels, the plug-in configuration settings for the service channels are retained.
Upgrading channels from an earlier release

This section describes how to use the Tuner Administrator and Transmitter Administrator to update channels to the current release. You can access information about these tools either by clicking the Help button, or by reviewing the BMC BladeLogic Client Automation CMS and Tuner Guide. BMC Software recommends that you not perform Update from on service channels (for example, Inventory service) or on Patch source channels (for example Windows Patch Source). Perform these upgrade tasks first in a test environment.
To upgrade channels from an earlier release 1 On the master transmitter, log in as a primary administrator. 2 Log in to Transmitter Administration. A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
Whats next?
C Click Manage Channels. 3 Click Add a Channel. 4 In Source URL, type http://products.marimba.com/ and click Browse to select the path
of the BMC CM transmitter. The channel name is Transmitter.
5 In Destination path, type the URL for the Transmitter channel.

Example: Version 7/Transmitter
6 Click Add Channel. 7 Log in to the CMS console as a primary administrator 8 Update the channel: A Choose Applications > Infrastructure > Tuner Administration. B Enter the name of the tuner on which the channel is running or subscribed. If
C Click Manage Channels. 9 If the channel is running, stop the channel: A Select the channel that needs to be stopped. B Click Stop. 10 Select the channel to update and under (Other actions), select Update from. 11 In Explorer User Prompt, type the new URL from which to update.
Whats next?
You have now finished preparing for the upgrade. The following chapter describes how to upgrade the master transmitter, mirrors, repeaters, and proxies. Later chapters describe how to upgrade the CMS console, the Web application channels, and the service channels on the endpoints.
229
Whats next?
230
Chapter
17
232 232 233 238 239 239 242 242 242 245 246 246 248
17
Upgrading transmitters and proxies

This chapter describes how to perform a tuner update for the tuner that hosts the transmitter or proxy. It then describes how to update the installed Transmitter channel or Proxy Server channel, and therefore, the transmitter or proxy storage and workspace. This chapter presents the following topics: Upgrade order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading the master transmitter and its tuner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading mirror transmitters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading a few mirrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading many mirrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading repeater transmitters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading a few repeaters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading many repeaters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading a few proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading many proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Whats next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NOTE
Perform these upgrade tasks in a test environment, as described in Creating a test environment on page 217, and verify that you have backed up the tuner, transmitter, and proxy workspaces, as described in Backing up workspaces and databases on page 218.
Chapter 17
231
Upgrade order
Upgrade order
The first step in a transmitter upgrade is to update the Infrastructure Service of the tuner on which the transmitter runs. This step requires the tuner to be restarted, which means that the transmitter is stopped and restarted. For this reason, it is essential to plan the correct order in which to upgrade all the transmitters, including masters, mirrors, and repeaters. You can use Infrastructure Service to review the settings and profiles that are on the machines. Usually several mirrors or repeaters rely on the master transmitter for updates. Many endpoint tuners can rely on mirrors and repeaters for updates. You should therefore upgrade the transmitters one class at a time: the master first, then mirrors, repeaters, and finally proxies.
Prerequisites
Use the following checklist to verify that you are ready to perform the upgrade. For the system requirements of BMC BladeLogic Client Automation 8.2.02 components, see Chapter 5, Before you install and the BMC BladeLogic Client Automation Release Notes document, available on the BMC Customer Support website. Table 1
Step 1
Preparation checklist
Task Ensure you have the access permissions and required disk space on the machine that hosts each transmitter and proxy: Verify that you have permission to access the machines involved. Contact your IT department if necessary. Verify that you have the required disk space for the upgrade. See the BMC BladeLogic Client Automation Release Notes document.
Ensure that all appropriate OS patches are applied to the machines that host the transmitters and proxies. This step applies mainly to UNIX platforms. For a list of the required patches, see the BMC BladeLogic Client Automation Release Notes document, which also lists URLs for downloading patches from OS vendors. Use Transmitter Verifier 8.2.02 or Proxy Verifier 8.2.02 to verify that no channel segments or files in the transmitter storage space are corrupt or missing. See To check for corrupted or missing segments and files on page 232.
To check for corrupted or missing segments and files

To verify that no channel segments or files in the transmitter storage space are corrupt or missing, use the current version of Transmitter Verifier in http://products.marimba.com/Current/Version8 or Proxy Verifier 8.2.02 At the time of publication, the latest version of Transmitter Verifier was 8.2.02
232
Upgrading the master transmitter and its tuner
1 Ensure that you have installed both the Console Window channel and the TxVerify
channel in the tuner that hosts the master transmitter.
TIP
Use Tuner Administrator to connect to the transmitters tuner and find out if the channels are installed. If not the channels are not installed, subscribe the tuner to them. The latest version of TxVerify is available from the following URL: http://products.marimba.com/Current/Version8/TxVerify.
2 Using Tuner Administrator, display the channels for the master transmitters
tuner, right-click the latest version of the TxVerify channel, and select Start console channel.
s s
This channel allows you to see log messages as the verification proceeds. You might not be able to launch the CMS console from some UNIX machines.
3 Right-click the latest version of the TxVerify channel and select Start w/Args. In the
pop-up window, type -delete and click OK. The -delete option automatically deletes corrupt files in the transmitter storage. It also removes any reference to the corrupt files from referring channel indexes and removes compressed versions of the file. If the transmitter workspace is large, this process could take some time.
NOTE
To check for corrupted files without deleting them, run the latest version of the TxVerify channel without using the -delete option.
4 For a proxy, use Proxy Verifier 8.2.02. You must connect to each proxy
individually, using Tuner Administrator to run the channel with the start argument -delete. Proxy Verifier 8.2.02 is located at: http://products.marimba.com/Current/Version8/ProxyVerify.

Upgrading the master transmitter involves updating the tuner that hosts the transmitter, updating the Transmitter channel, and then upgrading the workspace and storage.
Chapter 17
233
You upgrade the transmitter infrastructure from the master transmitter outwards. The order is usually master transmitter, mirrors, repeaters, and then proxies; however, if there are proxies between the master transmitter and the repeaters, upgrade those proxies before the repeaters. Changes are forward-compatible. A new master transmitter can communicate with an old mirror, but an new mirror might not be able to communicate with an old master transmitter. You can print and use the worksheet in Table 2. Table 2
Step 1 2
Upgrade checklist for the master transmitter

Task Upgrade the Infrastructure Service channel. Upgrade the Transmitter channel.
You can use the 8.x Infrastructure Administration to upgrade the master transmitter and tuner to version 8.2.02
Before you begin

Before you upgrade, run TxVerify on the master transmitter and ensure that no workspace corruptions exist. For more information about this procedure, see page 232.
To upgrade the Infrastructure Service channel 1 Log in to the CMS console as a primary administrator. 2 Log in to Transmitter Administration. A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
C Click Manage Channels. 3 Copy the Infrastructure Service channel from the transmitter to the master
transmitter:
A Click Add a Channel. B In Source URL, enter the path http://products.marimba.com/Current/version8/ or

click Browse to select the path of the transmitter. The channel name is InfrastructureService.
234
C In Destination path, enter the URL of the Infrastructure Service channel.

Example: /Marimba/Current/InfrastructureService
D Click Add Channel. 4 Upgrade the tuner: A Choose Applications => Infrastructure => Tuner Administration. B Enter the name of the tuner on which the master transmitter is running. If
C On the Manage Channels link, select the Transmitter Channel and click the
Stop button. The Transmitter Channel must stop. You can also use the Transmitter Administration to stop the Transmitter service.
D Under (select an action), select Update tuner and then click Go.
This action causes the Infrastructure Service channel to run, which updates and restarts the tuner.
TIP
The Update tuner action works only if you are subscribed to the Infrastructure Service channel. Otherwise, you must use Tuner Administrator to subscribe to the Infrastructure Service channel and then start it (instead of using the Update Tuner action).
5 Verify that the tuner version is correct by checking the version number on the
Tuner Administration page.
TIP
If the tuner version is not updated to 8.2.02, start the Infrastructure Service channel again. If you have multiple server tuners managed with a profile, this process can be automated by having Infrastructure Service 'start.schedule' property or tuner property 'marimba.tuner.update.schedule' set to check for periodic update. These tuners would automatically update to the new version published to the URL in step 3.
6 Update the JVM memory settings of the tuner: A Choose Applications => Infrastructure =>Tuner Administration. B Enter the name of the tuner on which the master transmitter is running. If
C Click Edit Settings.
Chapter 17
235
D Select the Custom Properties tab. E Update the value of marimba.launch.javaArgs as:
-Xms128m -Xmx640m -XX:PermSize=32m -XX:MaxPermSize=160m.
In case of 64-Bit transmitters, update the value as: -Xms128m -Xmx8192m -XX:PermSize=32m -XX:MaxPermSize=2560m
F Click Preview. G Click Apply to save the settings. H Click Restart Tuner. To upgrade the Transmitter channel 1 Log in to the BMC CM console as a primary administrator. 2 Log in to Transmitter Administration. A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
necessary, enter the transmitter admin user name and password.
C Click Manage Channels. 3 Copy the Transmitter channel from the BMC CM transmitter to the master
transmitter. The channel name is Transmitter.
A Click Add a Channel. B In Source URL, type the path http://products.marimba.com/Current/version8/ or

click Browse and select the path of the transmitter.
C In Destination path, enter the URL of the Transmitter channel; for example,
/Marimba/Current/Transmitter.
D Click Add Channel. 4 If the URL of the installed transmitter on the master transmitter points to itself,
perform the following steps to update the Transmitter; otherwise, skip to step 5.
236
A Stop the Transmitter publish and replication services:

1. From Applications => Infrastructure => Transmitter Administration, enter the name of the tuner on which the master transmitter is running. If necessary, enter the Tx admin user name and password. 2. Click Edit Settings. 3. Select the General tab. 4. Clear the Allow publishing and Allow replication checkboxes.
B Use Tuner Administrator to update the Transmitter channel:

1. Choose Applications => Infrastructure => Tuner Administration. 2. To update one master, enter the name of the tuner on which the master is running. If necessary, enter the remote tuner admin user name and password. 3. Under (select an action), select Update transmitter and then click Go. 4. From Applications => Infrastructure => Tuner Administration, enter the name of the tuner on which the master transmitter is running. If necessary, enter the Tuner admin user name and password. 5. Click Manage Channels. 6. Click BBCA Channels. 7. Select the Transmitter channel check box. 8. Stop the Transmitter Channel. 9. Select the Transmitter channel check box. 10. Start the Transmitter Channel.
5 If the URL of the installed transmitter on the master is not pointing to itself,
perform the following steps; otherwise, skip to step 6 on page 238:
A Stop the Transmitter publish and replication services:

1. From Applications => Infrastructure => Transmitter Administration, enter the name of the tuner on which the master transmitter is running. If necessary, enter the Tx admin user name and password. 2. Click Edit Settings.
Chapter 17 Upgrading transmitters and proxies 237
Upgrading mirror transmitters
3. Select the General tab. 4. Clear the Allow publishing and Allow replication checkboxes.
B Use Tuner Administrator to update the Transmitter channel:

1. From Applications => Infrastructure => Tuner Administration, enter the name of the tuner on which the master transmitter is running. If necessary, enter the Tx admin user name and password. 2. Click Manage Channels. 3. Click BBCA Channels. 4. Select the check box against Transmitter channel. 5. Click Stop to stop the Transmitter Channel. 6. Select the Transmitter channel check box. 7. From the other actions list, select Update from. 8. Enter the Transmitter channel URL from which to update. 9. Click OK. 10. Select the Transmitter channel check box. 11. Click Start to start the Transmitter Channel.
6 Use Transmitter Administrator to verify that the transmitter version is correct. A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
necessary, enter the Tx admin user name and password.

The transmitter version is displayed at the top of the page
Upgrading mirror transmitters

When you finish upgrading the master transmitter, you can then upgrade the mirror transmitters.
238
Upgrading a few mirrors
TIP
If the mirrors are set to upgrade from the master transmitter, you can continue with this section. If, however, the mirror transmitters are set to upgrade from a mirror layer, then you can start replication now to copy the new channel on the master transmitter.
Upgrade the transmitter infrastructure from the master transmitter outwards. The order is usually master transmitter, mirrors, repeaters, and then proxies; however, if there are proxies between the master transmitter and the repeaters, upgrade those proxies before the repeaters.
Upgrading a few mirrors

If you have a small number of mirrors, upgrade them one by one so that you can monitor the success of the upgrade. This method uses Tuner Administrator and Transmitter Administrator.
Upgrading many mirrors

If you have a large number of mirrors, upgrading them one by one might not be feasible; for example, if you do not have time, resources, or access. You can, however, upgrade the mirrors using the following methods:
s
Upgrade the mirrors as a group. This method uses Tuner Administrator and Transmitter Administrator. You can administer the mirrors by using previously-created profiles. (This method does not create profiles for the transmitters.) You have more control using this method than using Policy Manager.
Use your current version of Policy Manager. Ensure Policy Service is already installed on each transmitters tuner.
You can print and use the worksheet in Table 3 on page 239. Table 3
Step 1 2
Upgrade checklist for mirrors using Tuner Administrator and Transmitter Administrator
Task Log in to the CMS console as a primary administrator. Use Tuner Administration to update the tuners on the mirrors. You can update mirrors one by one or in groups.
Chapter 17
239
Table 3
Step 3 4
Upgrade checklist for mirrors using Tuner Administrator and Transmitter Administrator
Task Use Tuner Administration to update and restart the Transmitter channel on the mirrors. You can update mirrors one by one or in groups. Use Transmitter Administrator to verify that the transmitter version is now 8.2.02.
When you created profiles for mirrors, you might have set Infrastructure Service to Never so that there are no automatic upgrades and installations. The following procedure starts Infrastructure Service.
To upgrade mirror transmitters using Tuner Administrator and Transmitter Administrator 1 Log in to the CMS console as a primary administrator. 2 Assuming that the mirrors already have Infrastructure Service installed, update
the tuners on the mirrors:
A Choose Applications => Infrastructure => Tuner Administration. B To update one mirror, enter the name of the tuner on which the mirror is
running. If necessary, enter the remote tuner admin user name and password.
C To update more than one mirror, enter the list of tuners on which the mirrors
are running. If necessary, enter the remote tuner admin user name and password. (It is assumed they use the same credentials.)
D Under (select an action), select Update tuner and then click Go.
Infrastructure Service runs on the mirrors tuners and then updates and restarts the tuners.
3 Update the JVM memory settings of the tuner: A Choose Applications => Infrastructure =>Tuner Administration. B Enter the name of the tuner on which the mirror transmitter is running. If
C Click Edit Settings. D Select the Custom Properties tab. E Update the value of marimba.launch.javaArgs as:
240
F Click Preview. G Click Apply to save the settings. H Click Restart Tuner. 4 Use Tuner Administrator to update the Transmitter channel.
Ensure the URL of the installed transmitter on the mirror points to the master transmitter and that the 8.2.02 version of the transmitter is replicated to the mirror. Therefore, when you update the channel, it updates to 8.2.02.
A Choose Applications => Infrastructure => Tuner Administration. B To update one mirror, enter the name of the tuner on which the mirror is
D To update more than one mirror, enter the list of tuners on which the mirrors
are running. If necessary, enter the remote tuner admin user name and password. (Tuners must use the same credentials.)
E Under (select an action), select Update transmitter and then click Go. 5 To update the version, restart the Transmitter channel. 6 Use Transmitter Administrator to verify that the mirror version is correct. A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the mirror is running. If necessary, enter
the remote tuner admin user name and password.

The mirror version is displayed near the top of the page.
Chapter 17
241
Upgrading repeater transmitters
NOTE
You can also use the List information about my transmitters query, located in the Report Center Query Library under BMC CM Infrastructure => Infrastructure Components => Mirrors.
Upgrading repeater transmitters

When you finish upgrading the master and mirrors, you can upgrade the repeaters.
TIP
If the repeaters are set to upgrade from the master transmitter, you can continue with this section. If, however, the repeater transmitters are set to upgrade from a repeater layer, then you can start replication now to copy the new channel on the master transmitter.
Upgrading a few repeaters

If you have a small number of repeaters, you should upgrade them one by one so that you can monitor the success of the upgrade. This method uses Tuner Administrator and Transmitter Administrator.
Upgrading many repeaters

If you have a large number of repeaters, upgrading them one by one might not be feasible; for example, if you do not have time, resources, or access. You can, however, upgrade the repeaters using the following methods:
s
Upgrade the repeaters as a group. This method uses Tuner Administrator and Transmitter Administrator. You can administer the repeaters by using previously-created profiles. (This method does not create profiles for the transmitters.) You have more control using this method than using Policy Manager.
242
Use your current version of Policy Manager. Ensure Policy Service is already installed on each transmitters tuner.
You can print and use the following worksheet. Table 4

Step 1 2 3 4 5
Upgrade checklist for repeaters using Tuner Administrator and Transmitter Administrator
Task Log in to the CMS console as a primary administrator. Use Tuner Administration to update the tuners on the repeaters. You can update repeaters one by one or in groups. If necessary, replicate the mirrors. Use Tuner Administration to update and restart the Transmitter channel on the repeaters. You can update repeaters one by one or in groups. Use Transmitter Administrator to verify that the transmitter version is 8.2.02
When you created profiles for repeaters, you might have set Infrastructure Service to Never so that there are no automatic upgrades and installations. The following procedure starts Infrastructure Service.
To upgrade repeater transmitters using Tuner Administrator and Transmitter Administrator 1 Log in to the CMS console as a primary administrator. 2 Verify that the Infrastructure Service and transmitter channels are replicated to
mirrors and repeaters. This replication normally takes about double the scheduled replication time. The first replication time moves the updates from the master transmitter to the mirrors. The second replication time moves the updates from the mirrors to the repeaters.
3 If necessary, you can force replication by performing the following steps: A Choose Applications => Infrastructure => Transmitter Administration. B Enter the list of tuners on which the mirrors are running. If necessary, enter the
user name and password. (Tuners must use the same credentials).
C Under (select an action), select Start replication and then click Go. D Repeat step B and step C for repeaters.
Chapter 17
243
4 Update the tuners on the repeaters: A Choose Applications => Infrastructure => Tuner Administration, and perform one
of the following options:
s
To update one repeater, enter the name of the tuner on which the repeater is running. If necessary, enter the remote tuner admin user name and password. To update more than one repeater, enter the list of tuners on which the repeaters are running. If necessary, enter the remote tuner admin user name and password. (Tuners must use the same credentials.)
B On the Manage Channels link, select the Transmitter Channel and click the
Stop button. The Transmitter Channel must stop. You can also use the Tuner Administration to stop the Transmitter service.
C Under (select an action), select Update tuner and then click Go.
Infrastructure Service runs on the repeaters tuners, and then updates and restarts the tuners.
5 Update the JVM memory settings of the tuner: A Choose Applications => Infrastructure =>Tuner Administration. B Enter the name of the tuner on which the repeater is running. If necessary, enter
F Click Preview. G Click Apply to save the settings. H Click Restart Tuner. 6 Use Tuner Administrator to update the Transmitter channel.
Upgrading proxies
Ensure the URL of the installed transmitter on the repeater points to the mirror name and that the 8.2.02 version of the transmitter is replicated to the repeater. Therefore, when you update the channel, it updates to 8.2.02.
A Choose Applications => Infrastructure => Tuner Administration. B To update one repeater, enter the name of the tuner on which the repeater is
C To update more than one repeater, enter the list of tuners on which the repeaters
are running. If necessary, enter the remote tuner admin user name and password. (All specified tuners must use the same credentials.)
D Under (select an action), select Update transmitter and then click Go. E Restart the Transmitter channel. 7 Use Transmitter Administrator to verify that the transmitter version is correct: A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the repeater is running. If necessary, enter

The repeater version is displayed near the top of the page.
Upgrading proxies
When you finish upgrading the master, mirrors, and repeaters, you can upgrade the proxies.
NOTE
Chapter 17
245
Upgrading a few proxies
Upgrading a few proxies

If you have a small number of proxies, upgrade them one by one so that you can monitor the success of the upgrade. This method uses Tuner Administrator and Proxy Administrator.
Upgrading many proxies

If you have a large number of proxies, upgrading them one by one might not be feasible; for example, if you do not have time, resources, or access. You can, however, upgrade the proxies as a group. This method uses Tuner Administrator and Proxy Administrator. You can administer the proxies by using previously-created profiles. (This method does not create profiles for the transmitters.) You can print and use the following worksheet. Table 5
Step 1 2 3
Upgrade checklist for proxies using Tuner Administrator and Proxy Administrator
Task Log in to the CMS console as a primary administrator. Use Tuner Administration to update the tuners on the proxies. You can update the proxies one by one or in groups. Use Tuner Administration to update and restart the proxy channel on proxies. You can update proxies one by one or in groups.
To upgrade proxies using Tuner Administrator and Proxy Administrator 1 Log in to the CMS console as a primary administrator. 2 Assuming that the proxies already have Infrastructure Service 8.2.02 installed,
update the tuners on the proxies:
A Choose Applications => Infrastructure => Tuner Administration. B To update one proxy, enter the name of the tuner on which the proxy is running.
If necessary, enter the remote tuner admin user name and password.
246
Upgrading many proxies
D To update more than one proxy, enter the list of tuners on which the proxies are
running. If necessary, enter the remote tuner admin user name and password. (All specified tuners must use the same credentials.)
E Under (select an action), select Update tuner and then click Go.
Infrastructure Service runs on the proxies tuners, and then updates and restarts the tuners.
3 Update the JVM memory settings of the tuner: A Choose Applications => Infrastructure =>Tuner Administration. B Enter the name of the tuner on which the master transmitter is running. If
F Click Preview. G Click Apply to save the settings. H Click Restart Tuner. 4 Use Tuner Administrator to update the Proxy Server channel.
Ensure the URL of the installed transmitter on the proxy points to the master transmitter or to itself and that the 8.2.02 version of the transmitter is replicated to the proxy. Therefore, when you update the channel, it updates to 8.2.02.
A Choose Applications => Infrastructure => Tuner Administration. B To update one proxy, enter the name of the tuner on which the proxy is running.
If necessary, enter the remote tuner admin user name and password.
C To update more than one proxy, enter the list of tuners on which the proxies are
running. If necessary, enter the remote tuner admin user name and password. (All specified tuners must use the same credentials.)
Chapter 17 Upgrading transmitters and proxies 247
Whats next?
D Under (select an action), select Update proxy and then click Go. 5 Restart the Proxy Server channel. 6 Use Proxy Administrator to verify that the proxy version is correct: A Choose Applications => Infrastructure => Proxy Administration. B Enter the name of the tuner on which the proxy is running. If necessary, enter
Whats next?
Now that you have finished upgrading the master transmitter, mirrors, repeaters, and proxies, upgrade the CMS console, as described in Chapter 18, Upgrading the CMS console, on page 251.
248
Chapter
18
18
Upgrading the CMS console

This chapter describes how to update the CMS console. You update, in order, the tuner on the console, the console, the Infrastructure Administration channel, and the Schema Manager channel. This chapter presents the following topics: Upgrading the tuner on the console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Upgrading the CMS console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Upgrading Infrastructure Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Upgrading Schema Manager module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Upgrading the directory services schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Updating the Inventory database schema modules, query libraries, and custom objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Using the Easy update option to update the Inventory database schema modules and query libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Using the Custom update option to update the Inventory database schema modules and query libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Adding custom objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Updating the Infrastructure Status Monitor schema . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Using the Easy update option to update the Infrastructure Status Monitor database schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Using the Custom update option to update the Infrastructure Status Monitor database schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Whats next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 This chapter is part of the console and Web applications upgrade section. You must complete this chapter and the rest of the Web application chapters as one unit.
Upgrading the tuner on the console

Before you can update the console, you must update the tuner on the console.
Chapter 18
249
Upgrading the tuner on the console
Before you begin

You must be subscribed to the Infrastructure Service channel. Otherwise, use Tuner Administrator to subscribe to the Infrastructure Service channel and then start it.
To upgrade the tuner on the console 1 Log in to the CMS console as a primary administrator. 2 Log in to Tuner Administration: A Choose Applications => Infrastructure => Tuner Administration. B Enter the name of the tuner on which the CMS console is running. If necessary,
enter the remote tuner admin user name and password.
3 Under (select an action), select Update tuner and then click Go.
This action runs Infrastructure Service, which updates and then restarts the tuner.
4 Update the JVM memory settings of the tuner: A Choose Applications => Infrastructure =>Tuner Administration. B Enter the name of the tuner on which the CMS console is running. If necessary,
C Click Edit Settings. D Select the Custom Properties tab. E Update the value of marimba.launch.javaArgs = -Xms128m -Xmx640m XX:PermSize=32m -XX:MaxPermSize=160m.
F Click Preview. G Click Apply to save the settings. H Click Restart Tuner. Where to go from here
Proceed to the procedures described in Upgrading the CMS console on page 251.
250

After you upgrade the tuner hosting the CMS console and make the necessary preparations, you are ready to upgrade the console. The checklist in Table 1 provides an overview of the upgrade process. Table 1
1 2 3 4 5 6
Checklist for a CMS console update

Step Task Log in to the CMS console as a primary administrator. Log in to Transmitter Administration. Copy the Common Management Services channel to the master transmitter. Copy the Infrastructure Administration channel to the master transmitter. Update the CMS console. Verify the directory service connection.
Before you begin

s
Ensure that you prevent the upgrade process from overwriting the msf.txt file. Updating the console overwrites the msf.txt file, which contains the configurations you set in CMS, for example, database configurations, host ports, port numbers, and so on. To use the information in the original msf.txt file, perform one of the following actions:
s
Open the original msf.txt and print it. After you update the console, go to the new msf.txt and enter the original settings. Back up the original msf.txt. After you update the console, copy the new msf.txt file and save it with a different name. Then replace the new msf.txt file with the original msf.txt file. (You should always keep a copy of the new msf.txt file.) For UNIX systems, verify that the permissions of the original file are the same as the new file.
The msf.txt file is located at Marimba/Tuner/.marimba/Marimba/CMSchannel/data. Use Marimba/Tuner/.marimba/Marimba/map.txt to find the CMS channel number.
s
Ensure that all channels point to the URL for the master transmitter.
Chapter 18
251
To update the console to version 8.2.02 1 Log in to the CMS console as a primary administrator. 2 Log in to Transmitter Administration: A Choose Applications => Infrastructure => Transmitter Administration. B Type the name of the tuner on which the master transmitter is running. If
necessary, type the remote tuner admin user name and password.
C Click Manage Channels. 3 Copy the Common Management Services channel from the transmitter to the
master transmitter.
A Click Add a Channel. B In Source URL, type http://products.marimba.com/Current/Version8/ or click Browse

and select the path of the transmitter.
C In Destination path, enter the URL of the Common Management Services

channel. Ensure the channel name is cms.
D Click Add Channel. 4 Copy the Infrastructure Administration channel from the transmitter to the master
transmitter:
A Click Add a Channel. B In Source URL, type http://products.marimba.com/Current/Version8/ or click Browse

C In Destination path, enter the URL of the Infrastructure Administration channel.

Verify that the channel name contains no spaces: InfrastructureAdministration.
D Click Add Channel. 5 Update the Common Management Services channel on the console: A Choose Applications => Console => System Settings. B Click Applications Manager. C Click Update Console.
252
6 Restart the console to ensure that the upgrade was applied: A Choose Applications => Console => System Settings. B Click Restart the Console. 7 Verify the directory service connection: A Click the Data Source tab and then click Directory Service. B Select a directory service and click Edit.
s s s
Ensure that the correct directory service type is selected. If applicable, select Use this directory service to authenticate users. For Active Directory, ensure the auto-discover feature is enabled so you can access data in Active Directory.
C Click OK. 8 Log in again. 9 Add the taskmgr.threadpool.maxthreads property to the msf.txt file:
This property sets the threads assigned for lightweight and heavyweight task throttling. Increasing the property value increases the resources assigned for both tasks.
A Open the msf.txt file in a text editor.

You can find this file in the CMS\data folder. Example: If the CMS channel is channel 20, the file is in
installationDirectory\Tuner\.marimba\<profile name>\ch.20\data
B Add taskmgr.threadpool.maxthreads=30. C Save and close the file. 10 Specify an SMTP (mail) server for e-mail notifications: A Select Applications =>Console => System Settings. B On the General Settings page, select E-mail Notifications. C Specify the host name and port number for the mail server that will send e-mail
notifications, and click OK.
Chapter 18
253
Upgrading Infrastructure Administration
Upgrading Infrastructure Administration

This section describes how to upgrade the Infrastructure Administration channel.
Before you begin

s
s s
Upgrade the CMS console, as described in Upgrading the CMS console on page 251. Ensure that all channels point to the URL for the master transmitter. Subscribe the Infrastructure Administration channel to the transmitter.
To upgrade the Infrastructure Administration channel 1 Log in to the CMS console as a primary administrator. 2 Update the Infrastructure Administration channel on the console. A Choose Applications => Console => System Settings. B Click Applications Manager. C For Infrastructure Administration, under Actions, select Stop and then select
Update.
When the Infrastructure Administration channel has finished updating, the version number changes to 8.2.02. Troubleshooting tip: If the version number does not change, click Refresh.
3 Restart the channel. Where to go from here

Upgrade Schema Manager, as described in Upgrading Schema Manager module on page 254.
Upgrading Schema Manager module

A new version of Schema Manager contains the database schema module changes and new database schema modules for the latest version of the product. Before you upgrade the rest of the product modules, you must upgrade Schema Manager.
254
Upgrading Schema Manager module
Before you begin

s
Ensure that all channels point to the URL for the master transmitter. For Oracle, in the init.ora file, ensure that the sessions parameter value is set to 500 or higher. Increasing the sessions parameter value prevents session count validation errors during the schema upgrade. You must restart the database after you modify the sessions parameter.
To upgrade Schema Manager 1 If necessary, log in to the CMS console as a primary administrator. 2 Log in to Transmitter Administration. A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
C Click Manage Channels. 3 Copy the Schema Manager channel from the transmitter to the master transmitter: A Click Add a Channel. B In Source URL, type http://products.marimba.com/Current/Version8/ or click Browse
C In Destination path, enter the URL of the Schema Manager channel. Ensure the
channel name contains no spaces: SchemaManager.
D Click Add Channel. 4 Update the Schema Manager channel on the console: A Choose Applications => Console => System Settings. B Click Applications Manager. C For Schema Manager, under Actions, select Stop and then select Update.
When the channel has finished updating, the version number changes to 8.2.02. If the version number does not change, click Refresh.
5 To restart Schema Manager, select Start from the Schema Manager Actions list.
Chapter 18
255
Upgrading the directory services schema

Following the Schema Manager upgrade, the Schema Modules sub tab shows the schema modules that have updates for this release. This page also shows any new database schema modules for this release. When you have finished upgrading Schema Manager, you can proceed to the following tasks:
s
Upgrading the directory services schema Updating the Inventory database schema modules, query libraries, and custom objects on page 257 Installing the Inventory database schema modules and query libraries on page 100
Upgrading the directory services schema

You must upgrade the directory services schema whenever a new version of Schema Manager includes a schema change for directory services. To see if you need to update the directory services schema, consult the Release Notes or you can start this task to see if the Update button is available for Directory Services.
Before you begin

You must upgrade the Schema Manager channel before you can upgrade the databases and other associated items.
To upgrade the directory services schema 1 Choose Applications => Console => Schema Manager, and select the Directory Service
tab.
2 On the Choose a Directory Service page, select the directory service you are using,
and click Connect.
3 Select the Schema Modules tab, and click Update. 4 Verify that the values are correct, and click Update. 5 Click the update link for the new schema. 6 On the Download LDIF Scripts page, click the link to download the .zip file that
contains the LDIF scripts that you need to run. Save the .zip file before opening it. The .zip file contains two types of files:
Updating the Inventory database schema modules, query libraries, and custom objects
An LDIF script that contains the schema changes and commands for creating containers for Policy Management. A batch file (.bat) for running the LDIF script. When you run the batch file on Active Directory, you must provide credentials for a user with schema administrator rights. For example, on the command prompt, you can type: install_ad.bat userName password.
7 On the computer where the directory service is installed, run the batch file to
execute the LDIF script and install the directory service schema. The LDIF script makes changes to your directory service schema so that it can be used with Policy Management. If you are using distributed Active Directory, updates to the schema result in directory service replication traffic across your network. Because this traffic can be significant, run the scripts at an off-peak time. You can print or view the script for reference. Commented text at the beginning of the file provides instructions for running the script.
NOTE
If you are using ADAM / AD LDS, download the .zip file into the ADAM installation directory (the default is C:\Windows\ADAM). Otherwise, you see an error like Add error on line 35:Invalid DN Syntax when you use the batch file to run the LDIF scripts. This error also occurs if the script is not using the default ADAM ldifde.
Updating the Inventory database schema modules, query libraries, and custom objects
When you update the Inventory schema modules, you also update the query libraries that contains predefined queries that you can use to generate reports in Report Center. Following the upgrade of the Schema Manager module, if later versions of the Inventory database schema modules are available, you can use Schema Manager to update those schema modules. When you access the Schema Modules sub tab on the Database Schemas page, any schema module with changes has an Update button. When you update the Inventory schema modules, you can choose from options that mirror the installation options.
Chapter 18
257
Using the Easy update option to update the Inventory database schema modules and query libraries
Table 2
Inventory schema module update options

Description Updates both the database schema and the query library at the same time. You can select this option if you do not need to modify any custom configurations. Enables you to update the schema modules and query libraries and change settings from the initial schema module installation. Enables you to run update scripts from a command line. When you manually update the database schema, you can control the custom tables and scripts to use. A schema update that you execute from the command line completes in less time than any update option that you execute from the GUI. When you select this option, you download an update script for each schema module to update. For detailed information about this option, see Appendix C, Manual database schema installation and updates, on page 333. This section includes information about using manual processes to install and upgrade database schemas.
Update option Easy update
Custom update Manual update
Upgrade Scripts for Core, Patch Management & Software Usage modules
Enables you to download a single update script that you can run from a command line to update several schema modules. By downloading the script from the CMS console, you can avoid errors that might occur when you append the scripts from different modules yourself. A schema update that you execute from the command line completes in less time than any update option that you execute from the GUI.. For detailed information about this option, see Appendix C, Manual database schema installation and updates, on page 333. This section includes information about using manual processes to install and upgrade database schemas.
Ensure that the Inventory database is Unicode compliant.
The Easy update option updates both the database schema and the query library at the same time. You can select this option if you do not need to modify any custom configurations.
258
If you used the Custom install option to install the Core schema, you can select the Easy update option if you do not need to change any additional database properties. With the exception of the dbtree user, any database properties or passwords that you changed during the installation are retained during the easy update process.
Before you begin

s
You must upgrade the Schema Manager channel before you can upgrade the database schema modules. Ensure you have performed the preparatory work described in Preparing for database schema upgrade on page 221. Terminate all user connections to the database instance.
TIP
Because of the amount of data in the Inventory database, database schema updates can take a long time. If you delete old records before you upgrade, you can shorten the upgrade time.
To use the Easy update option to update the database schema modules and query libraries 1 In the Schema Manager module, connect to the Inventory database as the system
administrator. The Database Schemas page is displayed.
2 Click the Schema Modules sub tab under Action, click Update for Core. 3 On the Update options page, select Easy update, and click Update.
When the operation is finished, a dialog box is displayed and the Schema Modules sub tab shows the updated version number.
4 Repeat step 2 through step 3, as necessary, to update the database schema and
query libraries for other schema modules.
5 Update or install other modules:

s
To update the database schema for other modules, go to the Schema Modules tab and then click the appropriate Update buttons. If you are upgrading the Software Usage module on Oracle, see Appendix C, Manual database schema installation and updates.
Chapter 18
259
Using the Custom update option to update the Inventory database schema modules and query libraries
To install the database schema for new modules, go to the Schema Modules tab and then click the appropriate Install buttons.
The Custom update option enables you to update the schema modules and query libraries and change settings from the initial schema module installation.
NOTE
If you used the Custom install option to change passwords or other database attributes, with the exception of the dbtree password, you do not need to use the Custom update option to preserve those changes. Use the custom upgrade to
s
Apply any new custom settings to the schema modules during the update process. Change the password for the dbtree user. If you used the Custom install option to change this password, you must use the Custom update option to change it again. Update the schema or the query library, but not both at the same time. Modify the database size parameters for the Core schema. (You can review the current settings by selecting the Custom update option.) Change the location of the database files for the Core schema. Example: You use Microsoft SQL Server, but you did not install the database in the default location on the C drive.
Before you begin

s
Terminate all user connections to the database instance. If you started using Report Center and already configured the Inventory plug-in to insert data into your database, disable the Inventory plug-in. For instructions about disabling the plug-in, see the Report Center online Help. Back up the database and prepare it for the update as described in Preparing for database schema upgrade on page 221. Ensure that there are no user connections to the database instance.
260
NOTE
If any application user connection to the inventory database instance persists, and you run any of the Oracle maintenance tasks, then you will view the 40071 Error terminating users error message. If any application user connection to the inventory database instance persists, and you run any Oracle install, reinstall, or upgrade tasks, then you will view the ORA-01940: cannot drop a user that is currently connected error message. Since these errors appear due to a known Oracle Server behavior, it is recommended to ensure that there are no persisting user connections to the inventory database, before you attempt to run any install, reinstall, upgrade, or maintenance tasks.
To use the Custom update option to update the database schema modules and query libraries 1 In the Schema Manager module, connect to the Inventory database as the system
administrator. The Database Schemas page is displayed.
2 On the Schema Modules sub tab under Action, click Update for Core. 3 On the Update Options page, select Custom update. 4 Modify the settings as necessary for your database, and click Update.
When the operation is finished, a dialog box is displayed.
5 Repeat step 2 through step 4, as necessary, to update the database schema and
query libraries for other schema modules. When the operation is finished, the Schema Modules tab shows the new version number for the schema. To monitor the progress of the schema update, see Monitoring the progress of a schema update on Oracle on page 354.
Chapter 18
261
Adding custom objects
Adding custom objects

If you created and use a scanner extension to collect information that the Scanner Service does not collect by default, you can also create custom table that has a Cascade Delete relationship with the Machine table. This cascade relationship internally deletes data from Custom table whenever data is deleted from the Machine table. The following example shows how to create a cascade delete for a foreign key:
alter table customtable add CONSTRAINT c_customtable_machine_id FOREIGN KEY (machine_id) REFERENCES customtable (id) on delete cascade
Updating the Infrastructure Status Monitor schema

When a new version of the Infrastructure Status Monitor schema becomes available, you can use one of the update options to update the schema to the latest version.
s
To update the database schema and retain any custom settings from a custom installation, you can use the Easy update option. To change some database settings as you update the schema, use the Custom update option. To download the database scripts and update the schema from the command line, use the Manual update option. For information about how to use this option, see Using a script to update the Infrastructure Status Monitor database schema on page 353.
Using the Easy update option to update the Infrastructure Status Monitor database schema
If you do not need to modify any custom settings during the Infrastructure Status Monitor database schema update, you can choose the Easy update option.
Before you begin

s s s
Terminate all user connections to the database instance. Back up the database and prepare it for the update. Log on to the CMS console as a primary administrator.
262
Using the Custom update option to update the Infrastructure Status Monitor database schema
To use the Easy update option to update the Infrastructure Status Monitor database schema 1 In the Schema Manager module, connect to the Infrastructure Status Monitor
database as the system administrator.
2 On the Infrastructure Status Monitor Database Schema page, select the

Infrastructure Status Monitor Database Schema Modules tab.
3 Under Action, select Update. 4 On the Update Options page, select Easy update, and click Update.
A completion page is displayed when the schema update is finished. To monitor the progress of the schema update, see Monitoring the progress of a schema update on Oracle on page 354.
Using the Custom update option to update the Infrastructure Status Monitor database schema
The Custom update option enables you to modify the Infrastructure Status Monitor database schema and change settings from the initial schema installation. If you used the Custom install option to change passwords or other database attributes, you do not need to use the Custom update option to preserve those changes. Use the Custom update option to
s
Apply any new custom settings to the schema modules during the update process. Change the password again. Modify the database size parameters. (You can review the current settings by selecting the Custom update option.) Change the name of the Infrastructure Status Monitor database. Change the location of the database files for the Infrastructure Status Monitor schema.
Example: You use Microsoft SQL Server, but you did not install the database in the default location on the C drive.
Chapter 18
263
Whats next?
Before you begin

You must be logged on to the CMS console as a primary administrator.
To use the Custom update option to update the Infrastructure Status Monitor database schema 1 In the Schema Manager module, connect to the Infrastructure Status Monitor

Infrastructure Status Monitor Database Schema Modules tab.
3 Under Action, select Update. 4 On the Update Options page, select Custom update, modify the database settings,
and click Update. A completion page is displayed when the schema update is finished. To monitor the progress of the schema update, see Monitoring the progress of a schema update on Oracle on page 354.
Whats next?
You have now upgraded the master transmitter, mirrors, repeaters, and proxies, and finished upgrading the CMS console, the console tuner, the Infrastructure and Schema Manager channels, and the databases. The following chapters describe how to upgrade the rest of the Web application channels (which you do as part of this upgrade section). A later chapter describes upgrading the service channels on the endpoints.
NOTE
At this point you will still not have re-enabled Scanner Service, Logging Service, Policy Service, or Patch Service.
264
Chapter
19
19
Upgrading Report Center

This chapter describes how to upgrade the components in Report Center, an inventory management and reporting system. You must upgrade Report Center before the rest of the Web applications. This chapter presents the following topics: Overview of upgrading Report Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Updating Report Center and the Inventory and Logging plug-ins . . . . . . . . . . . . . . 266 This chapter is part of the console and Web applications upgrade section. You must complete this chapter and the rest of the Web application chapters as one unit.
NOTE
Perform these upgrade tasks in a test environment, as described in Creating a test environment on page 217. It is also assumed that you have disabled the plug-in and printed out the inventory and logging configuration pages, as described in Preparing for the Report Center upgrade on page 225.
Overview of upgrading Report Center

The upgrade process involves updating the following components:
s
Database schema Verify that the database schema is updated. (See Updating the Inventory database schema modules, query libraries, and custom objects on page 259.) Report Center Inventory plug-inthe server-side component of the Report Center module. Enable the plug-in and review the settings for new scheduling options.
Chapter 19
265
Updating Report Center and the Inventory and Logging plug-ins
Logging plug-inEnable the plug-in and reviewing your settings. Scanner Service and Logging Servicethe client-side components of the Report Center and Logging modules. Updating these components involves updating the channels on endpoints after the updated plug-ins are configured. For details, see Chapter 23, Updating endpoints.
NOTE
The upgrade of the "Scanner Service and Logging Service" is not mandatory at this step. However, you must upgrade at least the plug-in before re-enabling these services.

When you have finished updating the Inventory database schema and, if necessary, adding schema for new modules, you can update Report Center, the Inventory plugin, and the Logging plug-in. You can print and use the worksheet in Table 1. Table 1
Step 1 2 3 4 5 6 7 8 9 10 11
Upgrade checklist for Report Center and Inventory and Logging plug-ins
Task Log in to the CMS console as a primary administrator. Log in to Transmitter Administration. Copy the Report Center channel to the master transmitter. Update Report Center on the CMS console. Verify that access control is turned off. Verify that the Query Library was successfully updated. Verify that other query-related functions work correctly. Copy the .configurator segment of the 8.2.02 plug-in for Inventory Service or the complete channel to the transmitter. Use Report Center to enable the Inventory plug-in. Copy the .configurator segment of the 8.2.02 plug-in for Logging Service or the complete channel to the transmitter. Use Report Center to enable the Logging plug-in.
266
To upgrade Report Center and the Inventory and Logging plug-ins 1 Log in to the CMS console as a primary administrator. 2 Log in to Transmitter Administration: A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
C Click Manage Channels. 3 Copy the Report Center channel from the transmitter to the master transmitter.
The channel name is ReportCenter.
A Click Add a Channel. B In Source URL, type http://products.marimba.com/Current/version8/ or click Browse

C In Destination path, type the URL of the Report Center channel; for example,
/Marimba/Current/ReportCenter.
D Click Add Channel. 4 Update the Report Center channel on the console. A Choose Applications => Console => System Settings. B Click Applications Manager. C For Report Center, under Actions, select stop and then select Update.
When the channel has finished updating, the version number changes to 8.2.02. Troubleshooting tip: If the version number does not change, click Refresh.
5 Restart the channel. 6 Verify that Report Center access control is disabled.
Do not enable Report Center access control until you complete planning and preparation for its use.
A Choose Applications => Report Center. B Click the Configuration tab.

Chapter 19 Upgrading Report Center 267
C Click Access Control Configuration. D Ensure all check boxes are clear. E Click OK. 7 Verify that the Query Library has been successfully imported: A Choose Applications => Report Center. B On the left side of the Query View page, you should see Queries and Query
Library folders.
C Expand the Query Library folder and run one of the queries. D If you installed the Software Usage schema, you should see a Software Usage
folder.
E If you installed the Patch Management schema, you should see a Patch
Management folder.
8 Verify that other query functions work correctly. A Expand the Queries folder. You should see folders from earlier versions and new
BMC-specific folders (which are empty). If you installed the Patch Management schema, you should see an empty Patch
Management folder.
B Run some of the queries. C Display the Machine Details page for a machine. D If you use collections, run a collection by selecting the Collections folder and
then click the Options button. On the Collections page, select a collection and click Run Now.
9 Copy the .configurator segment of the 8.2.02 plug-in for Inventory Service or the
complete channel to the transmitter.
NOTE
Copying only the .configurator segment does not change the channel version after the upgrades of the channel.
268
10 Enable, configure, and publish the Inventory plug-in: A In Report Center, click the Configuration tab and then click Inventory
Configuration. Enter or select a plug-in URL and click OK.
B Click the Plug-in tab. C Under Plug-in State, in Set plug-in state, select Enable.
You can compare the settings with the Preview Inventory Configuration page you printed. For details, see Preparing for the Report Center upgrade on page 225. For details about the settings, see the BMC BladeLogic Client Automation Report Center Guide or the Report Center Help.
D Click the Endpoint tab. E Ensure the Scanning on/off button is set to On. F If the Software Usage component is present, in the Application Scanner section,
select Scan for software usage.
G If you want, change schedules for the scan components. H If you want, edit the scanner extension settings for each component.
You can specify that the scanner extension run at the time of one or more of the component scans. You can also assign a different scanner extension to each of the components.
I Click Preview, verify the settings, and then click Save & Publish.
You can compare the settings with the Preview Inventory Configuration page you printed. For details, see Preparing for the Report Center upgrade on page 225.
11 Copy the .configurator segment of the 8.2.02 plug-in for Logging Service or the
complete channel to the transmitter.
NOTE
Copying only the .configurator segment does not change the channel version after the upgrades of the channel.
Chapter 19
269
If you have not installed the Infrastructure Status Monitor schema module, the following error message appears in the Logging Plug-in log file: Could not connect to ISM tables. Check the plugin configuration if it is configured with the valid ISM database user.
12 Enable, configure, and publish the Logging plug-in: A Click the Configuration tab and then click Logging Configuration. B Enter or select a plug-in URL and click OK. C Review the settings.
Compare the settings with the Preview Logging Configuration page you printed. For details, see Preparing for the Report Center upgrade on page 225. For details about the settings, see the BMC BladeLogic Client Automation Report Center Guide or the Report Center Help.
D Click Preview, verify the settings, and then click Save & Publish. Where to go from here
You have now updated Report Center and enabled the Inventory-related channels. The following chapters describe how to complete the console/Web applications upgrade section by upgrading the rest of the Web application channels. A later chapter describes how to upgrade the service channels on the endpoints. If you plan to use the Infrastructure Status Monitor, see Chapter 8, Setting up the Infrastructure Status Monitor, on page 113.
270
Chapter
20
Upgrading Software License Compliance

20
This chapter describes how to upgrade the Software License Compliance Module. This chapter presents the following topics: Updating Software License Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 This chapter is part of the console and Web applications upgrade section. You must complete this chapter and the rest of the Web application chapters as one unit.
NOTE
Updating Software License Compliance

When you have finished updating the Inventory database schema and, if necessary, adding schema for new modules, update Report Center, the Inventory plug-in, and the Logging plug-in, and then you can update Software License Compliance . You can print and use the worksheet in Table 1.
Chapter 20
271
Table 1
Step 1 2 3 4
Upgrade checklist for Software License Compliance

Task Log in to the CMS console as a primary administrator. Log in to Transmitter Administration. Copy the Software License Compliance channel to the master transmitter. Update Software License Compliance on the CMS console.
To upgrade Software License Compliance 1 Log in to the CMS console as a primary administrator. 2 Log in to Transmitter Administration: A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
C Click Manage Channels. 3 Copy the Software License Compliance channel from the transmitter to the master
transmitter. The channel name is SoftwareCompliance.

C In Destination path, type the URL of the Software License Compliance channel;
for example, /Marimba/Current/SoftwareCompliance.
D Click Add Channel. 4 Update the Software License Compliance channel on the console. A Choose Applications => Console => System Settings. B Click Applications Manager. C For Software License Compliance , under Actions, select stop and then select
Update.
272
5 Restart the channel.
Chapter 20
273
274
Chapter
21
21
Upgrading Policy Management

This chapter describes how to upgrade the components in the Policy Management system (previously known as Subscription Policy Management system). This chapter presents the following topics: Overview of upgrading Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Updating Policy Manager and the Policy Service plug-in . . . . . . . . . . . . . . . . . . . . . . 276 This chapter is part of the console and Web applications upgrade section. You must complete this chapter and the rest of the Web application chapters as one unit.
NOTE
Perform these upgrade tasks in a test environment, as described in Creating a test environment on page 217.
Overview of upgrading Policy Management

The upgrade process involves updating the following components:
s
Policy ManagerUpdate Policy Manager first. Policy Service plug-inthe server-side component of the Policy Management module. Use Policy Manager to publish the Policy Service plug-in. Policy Servicethe client-side component of the Policy Management module. These components are updated as part of the endpoint upgrade unit. For details, see Chapter 23, Updating endpoints.
Chapter 21 Upgrading Policy Management
275
Updating Policy Manager and the Policy Service plug-in

This section directs you to copy the new Policy Management-related channels to the master transmitter and update the Policy Manager channel. You can print and use the following worksheet. Table 2
Step 1 2 3 4 5 6
Upgrade checklist for Policy Manager and Policy Service plug-in

Task Log in to the CMS console as a primary administrator. Log in to Transmitter Administration. Copy the Policy Manager channel to the master transmitter. Update Policy Manager on the CMS console. If necessary, enable the Policy plug-in. Verify that Policy Manager was successfully updated.
To get the new channels and update Policy Manager 1 Log in to the CMS console as a primary administrator. 2 Log in to Transmitter Administration. A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
C Click Manage Channels. 3 Copy the Policy Manager channel from the transmitter to the master transmitter.
The channel name is SubscriptionManager.

C In Destination path, enter the URL of the Policy Manager channel; for example,
/Marimba/Current/SubscriptionManager.
D Click Add Channel.
276
4 Update the Policy Manager channel on the console: A Choose Applications => Console => System Settings. B Click Applications Manager. C For Policy Manager, under Actions, select stop and then select Update.
D Restart the Policy Manager channel. E To have Policy Manager obtain the current configuration settings from the
console, restart the console by choosing Applications => Console => System Settings and click Restart the Console.
F Copy the Policy Service channel to the Master transmitter. 5 Configure and publish the Policy plug-in: A Log in to the CMS console as a primary administrator. B Choose Applications => Policy Manager. C Click the Configuration tab and then click Plug-in. D Review the settings.
For details about the settings, see the BMC BladeLogic Client Automation Policy Management Guide or Policy Management Help.
E Click Preview, verify the settings, and then click Save & Publish. 6 Verify that Policy Manager was successfully updated.
s
Ensure that the existing policies are still available. Create a new policy that assigns both a package and a property to a target. Save the policy. Deploy the new policy.
Chapter 21 Upgrading Policy Management
277
NOTE
To enable policy compliance, choose Application => Console => System Settings, click the Data Source tab, click the LDAP-to-Database Synchronization Service link, and get a schedule for LDAP Synchronization to occur. The first LDAP synchronization can take a significant time (for example, up to 30 minutes for 40,000 endpoints). Policy compliance and Report Center access control do not function completely until this initial synchronization is finished.

You have now upgraded Policy Management. If you are upgrading Patch Management, proceed to Chapter 21, Installing or upgrading Patch Management. A later chapter describes how to upgrade the service channels on the endpoints.
278
Chapter
22
280 280 281 282 283 286 287 288 288 291 293 295 296 298 301 302 303 304 304 305
Installing or upgrading Patch Management

22
This chapter presents the following topics: Overview of installing or upgrading Patch Management . . . . . . . . . . . . . . . . . . . . . . If you are installing Patch Management for the first time. . . . . . . . . . . . . . . . . . . If you are upgrading Patch Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before you install or update Patch Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites for the Red Hat Enterprise Linux Patch Source channel . . . . . . . . Recommendations for machine roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patch repository update times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing Patch Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the Patch Management channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the patch repository and installing the Patch Sources . . . . . . . . . . Configuring the Patch Service plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying the Patch Service channel to endpoints . . . . . . . . . . . . . . . . . . . . . . . . Upgrading Patch Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading the Patch Source channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rebuilding the patch repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Upgrading Patch Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Updating the endpoints to Patch Service 8.2.02 . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying that the upgrade is in place . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying the success of the upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Whats next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
This chapter is part of the console and Web applications upgrade section. You must complete this chapter, the console chapter, and the rest of the Web application chapters as one unit.
Chapter 22 Installing or upgrading Patch Management
279
Overview of installing or upgrading Patch Management
Overview of installing or upgrading Patch Management

This section summarizes the actions to perform when you install or upgrade Patch Management.
If you are installing Patch Management for the first time

This section gives an overview of the installation procedure. You should read the entire section before you begin the installation so you are familiar with the process. It is important to follow the installation process exactly.
Patch Management channels

When you install Patch Management 8.2.02, the following channels are added to machines in the BMC BladeLogic Client Automation infrastructure:
s
Patch ManagerPatch Manager is installed on the console server and accessed through the CMS console. Part of installation involves configuring the patch repository. Patch Source channelsThe Patch Source channels are Windows, Solaris, Red Hat Enterprise Linux, AIX, Dell, and HP-UX; the channels you use depend on the machines in your enterprise. These channels contact the appropriate Microsoft, Sun, Red Hat Enterprise Linux, IBM, Dell, and HP websites, respectively, to get patch information. Patch ServiceThis is the client-side component of the Patch Management module. The channel is installed on endpoints. Patch Service performs the following tasks: Downloads the Patch Info channel that is created after you publish a patch group Uses the Patch Info channel to determine the patches that are appropriate for the machine Performs actions such as installing, uninstalling, and staging patches Provides compliance information after it finishes performing actions
280
If you are upgrading Patch Management
Patch Service plug-inThis is the server-side component of the Patch Service channel. Patch Manager publishes the plug-in.
Patch Management installation process

The patch management installation is described in Table 1. Table 1
1
Summary of Patch Management installation

Copy the Patch Management channels to the master transmitter and install Patch Manager on the CMS console as described in Installing the Patch Management channels on page 288. (Patch Management database schema and the Query Library must be installed). Configure the patch repository, which automatically installs the Patch Source channels as described in Configuring the patch repository and installing the Patch Sources on page 291. Configure the Patch Service plug-in, which includes specifying the URL of the Patch Information channel and the Content Replicator (if used) as described in Configuring the Patch Service plug-in on page 293. Use either Policy Manager or Deployment Manager to send the Patch Service channel to endpoints. For more information, see Deploying the Patch Service channel to endpoints on page 295.
Section Summary of actions
If you are upgrading Patch Management

This section gives an overview of the upgrade procedure. Read the entire section before you begin the upgrade so you are familiar with the process. It is important to follow the upgrade process exactly.
Patch Management channels upgraded

When you upgrade to Patch Management, the following channels are upgraded:
s
Patch ManagerPatch Manager is upgraded on the console server. The patch repository is upgraded as needed; for example, if you added a Patch Source channel and have to configure it. Patch Source channelsDepending on the machines in your enterprise, you upgrade the Windows and Solaris Patch Source channels and install the new Red Hat Enterprise Linux, AIX, Dell, and HP-UX Patch Source channels. These channels contact the appropriate Microsoft, Sun, Red Hat Enterprise Linux, IBM, Dell, and HP websites, respectively, to get patch information.
281
Before you install or update Patch Management
Patch Servicethe client-side component of the Patch Management module. The channel is installed on endpoints. Patch Service plug-inthe server-side component of the Patch Service channel. You use Patch Manager to publish the plug-in.
NOTE
Patch Management upgrade process

The Patch Management upgrade process is described in Table 2. Table 2
Section 1 2
Summary of Patch Management upgrade

Summary of actions Upgrade Patch Manager as described in Upgrading Patch Management on page 296. Upgrade the Windows and Solaris Patch Source channels on the master transmitter and on the hosting Patch Source tuners as described in Upgrading the Patch Source channels on page 298. Prepare and rebuild the patch repositories. For the procedure, see Rebuilding the patch repository on page 301. Add additional channels. Upgrade Patch Service on the master transmitter and verify the configuration as described in Upgrading Patch Service on page 302. Update the endpoints: depending on the update schedule, this update is either automatic or must be done manually. For the procedure, see Updating the endpoints to Patch Service 8.2.02 on page 303. Verify that the upgrade is successful. For the procedure, see Verifying that the upgrade is in place on page 304.
3 4 5 6
Before you install or update Patch Management

Before you install or update Patch Management, read these topics about Red Hat Enterprise Linux, machines specifics, and patch repository update times.
282
Prerequisites for the Red Hat Enterprise Linux Patch Source channel
Before you are add a Red Hat Enterprise Linux Patch Source channel, you must complete the tasks in this section.
Using the Up2Date agent

No simulationBecause the Up2Date agent handles installing Red Hat patches, you cannot simulate a deployment. Also, a Red Hat endpoint might get a patch that you did not target to it. Latest RPM always installedThe Up2Date agent always installs the latest version of an RPM, even if you deploy an earlier version as part of a patch group. The RPM is relative to the Satellite server with which the Up2Date agent is registered.
Required steps before installation

Before you install the Patch Source channel, you must do the following procedure. Instructions are provided for step 2; Red Hat provides instructions for the rest of the steps.
To prepare for the installation 1 Set up and deploy a Red Hat Satellite.
For instructions, see the Red Hat documentation.
A Set up the database. B Set up the operating system. C Set up the network. D Set up the Satellite server.
Troubleshooting tip: During the network setup, ensure you use a fully qualified domain name. Use the format staticIP localhost.LocalDomain localhost. For example, 123.45.678.90 mycomputer.acme.com mycomputer.
2 During the Satellite server setup in the previous step, you create an SSL certificate.
You must now manually install the certificate in two places. When installed, the certificate lets you configure the Red Hat Enterprise Linux section of the Patch Service configuration page.
283
There are two ways to install the certificate. For details, see Manually installing an SSL certificate.
s s
Install the certificate on the Red Hat Enterprise Linux Patch Source tuner. Install the certificate as a root certificate on the Patch Manager tuner.
NOTE
You can copy the certificate to the machines hosting the tuners and install from those machines. If both tuners are on the same machine, install the certificate only once.
3 Apply the Red Hat license and ensure the Red Hat Enterprise Linux subscription is
current. For instructions, see the Red Hat documentation.
4 Synchronize the Red Hat Enterprise Linux software channels that apply to your
environment. For instructions, see the Red Hat documentation.
5 Set up and register each endpoint with the Red Hat Satellite server using the
registration utilities that Red Hat provides. For instructions, see the Red Hat documentation.
Manually installing an SSL certificate

You can manually install an SSL certificate in two ways, using a profile or using Certificate Manager. You must install the certificate on both the Red Hat Enterprise Linux and Patch Manager tuners.
To manually install the SSL certificate using a profile 1 Log in to the CMS console. 2 Choose Applications => Infrastructure => Setup & Deployment. 3 Click the Profiles tab. 4 Select the profile for machine that is hosting one of the tuners and click Edit. 5 Under Core Settings for Profile, click the Security tab. 6 Click the Certificates tab. 7 Click Browse and select the certificate at /var/www/html/pub/RHN-ORG-TRUSTEDSSL-CERT on the Satellite server machine or, if you copied it, that location.
8 Click Preview, review the settings, and then click Apply.

9 Log in to Tuner Administration. A Choose Applications => Infrastructure => Tuner Administration. B Enter the name of the tuner on which the CMS console is running. If necessary,
10 Under (select an action), select Update tuner and then click Go.
NOTE
(troubleshooting) The Update tuner action does not work if you are not subscribed to the Infrastructure Service channel. If this is the case, you must use Tuner Administrator to subscribe to the Infrastructure Service channel and then start it (instead of using the Update Tuner action).
11 Repeat step 2 on page 284 through step 10 for the second tuner. Manually installing the SSL certificate using Certificate Manager
There are two methods of installing the certificate with Certificate Manager, the user interface or the command-line interface.
To manually install the SSL certificate using the user interface 1 Go to the certificate at /var/www/html/pub/RHN-ORG-TRUSTED-SSL-CERT on the
Satellite server machine or, if you copied it, that location.
2 Using a text editor, delete all information up to (but not including) Begin
Certificate. Save the file.
3 Go to Products/Current/version8/CertificateManager and open Certificate Manager. 4 Click Root. 5 Click Import. 6 Select the certificate file. 7 Enter a password if you have one or leave the field blank, and then click OK. 8 Enter a nickname or leave the field blank, and then click OK. If you leave the field
blank, a default nickname is assigned.
9 Scroll to the end of the list and select the SSL certificate.
285
Recommendations for machine roles
10 Under Trust type, select the SSL check box. 11 Choose File => Quit. To manually install the certificate using the command-line interface 1 Import the root certificate using the following command:
runchannel URLofCertificateManager -i root certificateFilePath password
where URLofCertificateManager is where the channel is hosted and certificateFilePath is /var/www/html/pub/RHN-ORG-TRUSTED-SSL-CERT on the Satellite server machine or, if you copied the file, that location. If you do not use a password, type (two double quotes). For example,
runchannel.exe http//.../CertificateManager -i root /var/www/html/pub/RHN-ORGTRUSTED-SSL-CERT
This outputs the distinguished name. For example,

cn=widget.acme.com;o=Acme;ou=Engineering;l=San Francisco;sp=California;c=US
2 Set the trust type to SSL with the distinguished name from the previous step using
runchannel URLofCertificateManager -s ssl distinguishedName
Example:
runchannel.exe http//.../CertificateManager -s ssl cn=widget.acme.com;o=Acme;ou=Engineering;l=San Francisco;sp=California;c=US

When you install a Patch Source channel for the first time, either during a new installation or by adding a channel during an upgrade, you must first decide which machine to use and verify that it meets system requirements. For details, see Table 3 on page 287 and the BMC BladeLogic Client Automation Release Notes document.
286
Patch repository update times
Table 3

Recommendation Ensure the machine has enough disk space to accommodate all the patches you need to publish. The Windows Patch Source channel must be installed on a Windows machine. The Solaris Patch Source channel can be on any machine that has a tuner port. If you already use a Solaris machine to manually download patches, you can install the Solaris Patch Source on that machine. You can then set up the Solaris Patch Source to use the same storage directory that you used previously. The Red Hat Enterprise Linux Patch Source channel can be on any machine that has a tuner port.
Machine role hosting the master transmitter hosting the Windows Patch Source channel hosting the Solaris Patch Source channel
hosting the Red Hat Enterprise Linux Patch Source channel
hosting the AIX Patch Source The AIX Patch Source channel can be on any AIX machine channel that has a tuner port. hosting the Dell Patch Source The Dell Patch Source channel can be on any Windows or channel Dell machine that has a tuner port. hosting the HP-UX Patch Source channel The HP-UX Patch Source channel can be on any HP-UX machine that has a tuner port.
Patch repository update times

If you choose to retrieve patches and download all binaries, then when you complete the Repository Configuration page, updating the repository can take the following amount of time:
s
For Solaris, the process can take several hours due to the large data volume (approximately 8 GB) and the third-party systems used to retrieve it. For Windows, the process can take more than an hour the first time you create the repository. For Red Hat Enterprise Linux, the process takes approximately 34 hours for each channel if each channel has 3,0005,000 patches.
If you choose to download binaries only when a patch group is published, the process is completed much faster, usually in less than an hour. During the time that the patch repository is being updated, you can continue to use the product.
287
Installing Patch Management
Installing Patch Management

You install the latest version of Patch Management by completing the following tasks:
s s s s
Installing the Patch Management channels Configuring the patch repository and installing the Patch Sources on page 291 Configuring the Patch Service plug-in on page 293 Deploying the Patch Service channel to endpoints on page 295
Installing the Patch Management channels

You copy the latest Patch Management channels to the master transmitter and then subscribe to the Patch Manager channel. You can print and use the checklist in Table 4. Table 4
Step 1 2 3 4 5 6 7 8 9 10
Channel installation checklist for Patch Management

Task Log in to the CMS console as a primary administrator. Log in to Transmitter Administration. Copy the Patch Manager channel to the master transmitter. Copy the Patch Service channel to the master transmitter. Copy the Windows Patch Source channel to the master transmitter. Copy the Solaris Patch Source channel to the master transmitter. Copy the Red Hat Enterprise Linux Patch Source channel to the master transmitter. Copy the AIX Patch Source channel to the master transmitter. Copy the HP-UX Patch Source channel to the master transmitter. Install or update Patch Manager on the CMS console.
Before you begin

Ensure that you have upgraded to the 8.2.02 version of Infrastructure Administration, tuner, CMS console, and Schema Manager. For information, see Upgrading the CMS console on page 253.
288
To get the new channels and install Patch Manager 1 Log in to the CMS console as a primary administrator. 2 Log in to Transmitter Administration. A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
C Click Manage Channels. 3 Copy the Patch Manager channel from the transmitter to the master transmitter.
The channel name is PatchManager.
A Click Add a Channel. B In Source URL, type http://products.marimba.com/Current/version8/PatchManager

or click Browse and select the path of the channel on the transmitter.
C In Destination path, type the URL of the Patch Manager channel; for example,
/Marimba/Current/PatchManager.
D Click Add Channel. 4 Copy the Patch Service channel from the transmitter to the master transmitter. The
channel name is PatchService. Repeat step 3 using PatchService in the source URL and the destination path.
5 If you are getting patch information from Microsoft, copy the Windows Patch
Source channel from the transmitter to the master transmitter. The channel name is WindowsPatchSource. Repeat step 3 using WindowsPatchSource in the source URL and the destination path.
6 If you are getting patch information from Sun Microsystems, copy the Solaris
Patch Source channel from the transmitter to the master transmitter. The channel name is SolarisPatchSource. Repeat step 3 using SolarisPatchSource in the source URL and the destination path.
7 If you are getting patch information from Red Hat Enterprise Linux, copy the Red
Hat Enterprise Linux Patch Source channel from the transmitter to the master transmitter. The channel name is LinuxPatchSource. Repeat step 3 using LinuxPatchSource in the source URL and the destination path.
289
8 If you are getting patch information from IBM, copy the AIX Patch Source channel
from the transmitter to the master transmitter. The channel name is AIXPatchSource. Repeat step 3 on page 289 using AIXPatchSource in the source URL and the destination path.
9 If you are getting patch information from HP, copy the HP-UX Patch Source
channel from the transmitter to the master transmitter. The channel name is HPUXPatchSource. Repeat step 3 on page 289 using HPUXPatchSource in the source URL and the destination path.
10 If you are getting patch information from Dell, copy the Dell Patch Source channel
from the transmitter to the master transmitter. The channel name is Dell Patch Source. Repeat step 3 on page 289 using Dell Patch Source in the source URL and the destination path
11 Subscribe to the Patch Manager channel on the console. A Choose Applications => Console => System Settings. B Click Applications Manager. C Click Subscribe to a New Application. Enter the URL for the Patch Manager
channel or browse to and select it on the master transmitter.
D Click Subscribe. After a minute or two, click Refresh.

Patch Manager appears on the console. You might need to click Refresh again if the application takes longer than expected to install. Patch Manager appears in the Applications menu. If it does not appear, log out and then log in again.
NOTE
The Patch Service channel is updated when you update the endpoint.

Now that you have installed the channels, proceed to Configuring the patch repository and installing the Patch Sources on page 291.
290
Configuring the patch repository and installing the Patch Sources

After you have installed the Patch Management database schema (in Updating Report Center and the Inventory and Logging plug-ins on page 68) and installed Patch Manager, you can configure the patch repository. As part of this configuration, you specify the machines on which you want to install the Patch Source channels. The channels are then automatically installed when you save the patch repository configuration settings.
To configure the patch repository 1 Log in to the CMS console as a primary administrator. 2 Go to the Repository Configuration page. TIP
For more information about the fields, place the cursor over the underlined field name to display rollover help, or click Help to display online help for configuring the repository.
A Choose Applications => Patch Manager.

If this is the first time you are using Patch Manager, the Repository Configuration page appears and you can go to the next step. Otherwise, continue with this step.
B Click the Configuration tab. C Click the Repository link. 3 Fill out the Repository Configuration page.
For details about the settings, see the BMC BladeLogic Client Automation Patch Management Guide or Patch Management online Help.
A In Master transmitter, specify the URL for the master transmitter where you want
to publish patch metadata and patch binaries; for example, http://nycmaster:5282. Note: All patches must be published to one master transmitter.
B If publish permission is required to publish patches to the transmitter, fill in

User name for publishing and Password for publishing.
291
C If you are installing the Windows, Solaris, Red Hat Enterprise Linux, AIX, Dell,
or HP-UX Patch Source channels, in the Platforms section, select the appropriate check boxes and fill in the information.
4 To publish the configuration settings, click Preview, review the settings, and then
click Save. The Patch Source channels are installed or updated on the machines you specified (a .configurator segment [plug-in] is updated on the applicable Patch Source channels on the transmitter). The Patch Source channels are then started, and begin collecting information about patches. This step updates the patch repository and can take several minutes to complete.
NOTE
For Windows patches, the patch information is written to the pkgdir subdirectory of the data directory in the Windows Patch Source channel directory. For Solaris patches, if you specified a storage directory, patch information is placed inside that directory. If you did not specify a storage directory, the information is placed inside the data directory in the Solaris Patch Source channel directory. Use map.txt in the tuner workspace to find the name of the Patch Source channel directory (for example, ch.10).
5 After the patch repository update is complete, verify that the Patch Information
channel was created on the transmitter.
A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
C Click Manage Channels and then click the Content tab. D Click the expander triangle to display the folders on the transmitter and look for
the PatchManagement folder. This folder should be at the same level as the Marimba folder.
E Expand this folder and verify that it contains the PatchInfo channel. TIP
If you cannot find the PatchManagement/PatchInfo channel on the transmitter, use the Patch Manager Manage patch repositories command or publish a patch group. Both actions create the PatchInfo channel. For details about creating a patch group, see Patch Manager online Help or the BMC BladeLogic Client Automation Patch Management Guide.
292
Configuring the Patch Service plug-in

Now that you have installed the Patch Management channels, configured the patch repository, and installed the Patch Source channels, the next step is Configuring the Patch Service plug-in.

The Patch Service channel resides on each endpoint and is managed by Policy Manager. The Patch Service channel is responsible for applying patch download policies assigned to the endpoint tuner on which it is running. The service has no graphical user interface (GUI). Patch Service starts at scheduled intervals and stops after it applies all installation actions that the patch download policy requires. After you configure and publish the Patch Service plug-in, you can deploy the Patch Service channel to an endpoint.
Before you begin

Verify that you have installed the Patch Management channels, configured the patch repository, and installed the Patch Source channels.
To configure the Patch Service plug-in 1 Log in to the CMS console as a primary administrator. 2 Go to the Patch Service Configuration page. A Choose Applications => Patch Manager. B Click the Configuration tab. C Click Patch Service. D Enter or select the URL of the Patch Service channel.
s
In Enter Patch Service URL, enter the URL or Browse a transmitter and navigate through folders to select a Patch Service channel. Note: The URL must end with PatchService, such as http://mytransmitter:7717/Marimba/PatchService.
In Select Patch Service URL, select a URL from the list of URLs that were previously entered.
293
E Click OK. NOTE

If subscribe permission is set for the channel that contains the plug-in, you must supply the user name and password. If password-only access control is set, leave User name blank.
3 Complete the Patch Service Configuration page.

For details about the settings, see the BMC BladeLogic Client Automation Patch Management Guide or Patch Management online Help.
A In the Patch Service update schedule section, specify how frequently you want
the Patch Service channel updated.
B To set requirements for publishing and subscribing to the Patch Service plug-in,
enter user names and passwords as needed in the Patch Service Options section.
C In the Endpoint Options section, set additional URLs, timeout values, and other
platform-specific items.
D To set the Snooze and Reboot window options, complete the Custom Reboot
Options section.
E If you need to set the Red Hat Enterprise Linux satellite, in the Satellite Server
Configuration section, select Satellite Server Configuration and enter the
information.
4 To publish the configuration settings, click Preview, review the settings, and then
click Save.

Now that you have installed the Patch Management channels, configured the patch repository, installed the Patch Source channels, and configured the Patch Service plug-in, proceed to Deploying the Patch Service channel to endpoints on page 295.
294
Deploying the Patch Service channel to endpoints
Deploying the Patch Service channel to endpoints

You configured the patch repository and the Patch Service plug-in, and can now subscribe the endpoints to the Patch Service channel. You can use any of the following methods:
s s s
If you have Policy Manager, you can use a policy. If you have Deployment Manager, you can create and run a deployment job. To test the channel on one endpoint at a time, you can use the CMS console Tuner Administration to subscribe the endpoint to the Patch Service channel.
When the endpoints have received the Patch Service channel, you can use Report Center to run a query that tells you the number of endpoints that have the channel. For example, you can use Query Builder to create a query that searches for channel URLs such as *PatchService, and then refine the query to search for channel versions that are either equal to or not equal to 7* or 8.2.02 (depending on whether you want to know the number of endpoints that did or did not get the channel). To verify that Patch Service interacts correctly with other channels on the endpoint, perform the following procedure on at least one endpoint.
To complete installation on an endpoint 1 After you have deployed the Patch Service channel to an endpoint, using one of the
methods mentioned at the beginning of this section, start the Scanner Service on the endpoint. After the scanner is finished, Patch Service starts.
2 When Patch Service finishes running, verify that the ScanData.xml file was created.
The file is located in a subdirectory of the Patch Service channel directory (the path is tunerWorkspace\ch.X\data\scanner\ScanData.xml), where tunerWorkspace is the path to the tuner workspace and ch.X indicates the channel directory for the Patch Service. Use the map.txt file in the tuner workspace to determine the correct channel number. Scanner Service uses this file to send patch-related information to the database.
3 Verify that the Patch Info channel is installed on the endpoint. Do one of the
following actions:
s
Go to the console Tuner Administration to view the channels installed on the endpoint and look for the Patch Information channel.
295
Upgrading Patch Management
Go to the map.txt file in the tuner workspace on the endpoint and look for the PatchInfo URL.
For the rest of the endpoints in the infrastructure, this process happens automatically the next time the Scanner Service performs a System/Hardware scan of the endpoint (after the Patch Service is installed). Data about installed patches and patches that are applicable but not yet installed is then sent to the database. You can then use Report Center to create queries and see this data, or you can use the Patch Management queries in the Report Center Query Library to see this data.
NOTE
If you configured the Patch Service plug-in to include a URL for Content Replicator, and Content Replicator is not currently installed on the endpoint (using that URL), Content Replicator is automatically installed when the endpoint receives instructions to install a Content Replicator custom patch. If the endpoint never receives a Content Replicator patch, Content Replicator is not downloaded and installed.

If you want a start-to-finish procedure, you can print and use the following checklist. Table 5
Step 1 2 3 4 5 6 7 8
Upgrade checklist for Patch Management

Task Upgrade Patch Manager. Copy the latest versions of the Patch Source channels to the master transmitter. Upgrade the Patch Source channels on the hosting Patch Source tuners and restart the tuners Upgrade the existing patches so they are sorted by platform (new organization of the patch dictionary). Rebuild the patch repositories. Upgrade Patch Service on the master transmitter and update the Repository Configuration page. Verify that the Patch Service Configuration page is correct. The endpoints are automatically upgraded; or, if the update schedule is set to Never, upgrade the endpoints manually with Policy Manager or Deployment Manager. Verify that the upgrade is successful.
296
Before you begin

Verify that you upgraded to the 8.2.02 version of the master transmitter, Infrastructure Administration, tuner, CMS console, Schema Manager, and Report Center. In addition, you must complete the prerequisites in Preparing for the Patch Management upgrade on page 226 and Before you install or update Patch Management on page 282.
To upgrade Patch Manager 1 Log in to the CMS console as a primary administrator. 2 Log in to Transmitter Administration. A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
C Click Manage Channels. 3 Copy the Patch Manager channel from the transmitter to the master transmitter.
The channel name is PatchManager.

C In Destination path, enter the URL of the Patch Manager channel; for example,
/Marimba/Current/PatchManager.
D Click Add Channel. 4 Update the Patch Manager channel on the CMS console. A Choose Applications => Console => System Settings. B Click Applications Manager. C Go to the Patch Manager line, and under Actions, select stop and then select
Update.
297
Upgrading the Patch Source channels
NOTE
If channels on the master are replicated to mirrors and repeaters, either wait for the replication to occur, or use Transmitter Administration to force replication.
D Restart the Patch Manager channel.

You now upgrade the Patch Source channels, first on the master transmitter and then on the tuners.
Before you begin

s s s
Upgrade the Tuner kernel. Ensure that you update the patch source tuners. To ensure that you have enough memory to complete this task, verify that your JVM arguments contain the following setting: -Xms128m -Xmx640m -XX:PermSize=32m -XX:MaxPermSize=160m
To modify the JVM arguments on the tuner 1 Choose Applications => Infrastructure => Tuner Administration. 2 On the Connect to a Tuner page, specify a tuner, or select one from the list, and
click Edit Settings.
3 On the Edit General Tuner Settings page for the selected tuner, select the Advanced
tab.
4 On the Advanced tab, select JVM. 5 In JVM arguments, type the following value as:
In case of 64-Bit transmitters, update the value as -Xms128m -Xmx8192m -XX:PermSize=32m -XX:MaxPermSize=2560m
6 Click Preview, and click Apply.
298
To copy the Patch Source channels to the master transmitter 1 Open Channel Copier: A If necessary, start the Channel Manager. B If necessary, subscribe to Channel Copier. C In Channel Manager, double-click Channel Copier. NOTE
You use Channel Copier because you cannot copy specific channel segments in the Transmitter Administration user interface. However, you can copy these segments using the Transmitter Administrator command-line interface.
2 Create a new job: A Click New. B To show the individual channel segments, click Show segments. C In Select source, type http://products.marimba.com/Current/version8/ or select the
path on the transmitter for the Windows Patch Source, and press Enter.
D In Select destination, type the URL of the Windows Patch Source channel on the
master transmitter, and press Enter. Example, /Marimba/Current/WindowsPatchSource.
E Expand the Windows Patch Source channel and select the Windows,x86/any
segment.
Important: Do not select the .configurator segment.
F Click Add. G In Select source, type http://products.marimba.com/Current/version8/ or select the

path on the transmitter for the AIX, Red Hat Enterprise Linux, HPUX, or Solaris Patch Source, and press Enter
H In Select destination, type the URL for the AIX, Red Hat Enterprise Linux,
HPUX, or Solaris Patch Source channel on the master transmitter, and press Enter. Example: /Marimba/Current/SolarisPatchSource. Press Enter.
299
I Expand the AIX, Red Hat Enterprise Linux, HPUX, or Solaris Patch Source
channel and select the any/any segment. Do not select the .configurator segment.
J Click Add. K Click Close. 3 Select the two segments.

Ensure you select the correct segments.
4 Click Copy.
You next upgrade the Patch Source channels on a tuner that hosts them and then restart the tuner and the channels. You repeat this procedure for all the tuners that host Patch Source channels.
NOTE
You restart a tuner only once, so you must first upgrade all the channels for that tuner and then restart the tuner. You then upgrade all the channels for the next tuner and restart that tuner, and so on.
To upgrade the Patch Source channels on the tuners 1 If you have configured Patch Source channels on the Repository Configuration
page, create a list of the channels and their tuners:
A Choose Applications => Patch Manager. B Click the Configuration tab and then click Repository. C For each Patch Source channel, in the Destination section, write down the URL
in Patch Source channel.
2 Log in to Tuner Administration. A Choose Applications => Infrastructure => Tuner Administration. B Enter the name of the tuner on which the Patch Source channels are running.
(Use the list created in the previous step.) If necessary, enter the remote tuner admin user name and password.
C Click Manage Channels. D Click the BBCA Channels tab.

Rebuilding the patch repository
3 Select the Patch Source channels, and under Actions, click Stop for each selection.
Stop all the Patch Source channels before you update them.
4 Select the Patch Source channels, and under Actions, select Update for each
selection. Ensure all Patch Source channels on the tuner are updated before you restart the tuner.
5 Restart the tuner by clicking Restart Tuner in the tuner information box above the
tabs.
6 Select the Patch Source channels, under Actions, select Start for each selection. 7 For each additional tuner, repeat step 2 on page 300 through step 6. NOTE
The full Patch Service 8.2.02 must be deployed as part of the upgrade.

Rebuild the patch repositories by completing the procedures in Rebuilding the patch repository.
Rebuilding the patch repository

When you have finished upgrading the Patch Source channels on the tuner, you can rebuild the patch repository.
To rebuild the patch repository 1 Click the Patches tab. 2 Choose File => Manage patch repository. 3 For each vendor, under Actions, select Rebuild. 4 Click Cancel to return to the patch repository.
301
Upgrading Patch Service

Use the procedure described in Upgrading Patch Service to upgrade the client.
Upgrading Patch Service

To upgrade the Patch Service, you must publish it to the master transmitter.
To publish the Patch Service to the master transmitter 1 Open Channel Copier. NOTE
You use Channel Copier because you cannot copy specific channel segments in the Transmitter Administration user interface. However, you can copy these segments using the Transmitter Administrator command-line interface.
A Click New to create a new job. B To show the individual channel segments, click Show segments. C In Source URL, enter the path http://products.marimba.com/Current/version8/ or
click Browse and select the path on the transmitter. Press Enter.
D In Destination path, enter the URL of the Patch Service channel; for example,
/Marimba/Current/PatchService. Press Enter.
E Expand the Patch Service channel and, one at a time, select all the segments
except .configurator, and click Add after each selection. Important: Do not select the .configurator segment.
F Click Close. G Select the segments. Ensure you select the correct segments. H Click Copy. 2 Verify and, if necessary, modify the Patch Service configuration settings. A Log in to the CMS console as a primary administrator. B Choose Applications => Patch Manager, click the Configuration tab, and then click
the Patch Services link.
302
Updating the endpoints to Patch Service 8.2.02
C Verify the settings. You can compare the settings to the configuration page you
printed out in Printing repository and Patch Service configuration settings on page 227.
D If necessary, modify the settings. E Click Preview, review the changes, and then click Publish. Where to go from here
Use the procedure in Updating the endpoints to Patch Service 8.2.02 to update the endpoints.
Updating the endpoints to Patch Service 8.2.02

If you set an update schedule, each endpoint automatically updates to Patch Service 8.2.02.
s
On the next scheduled update, Patch Service 8.x upgrades to version 8.2.02. On the first run of Patch Service 8.2.02, the PatchInfo channel is deleted and resubscribed. This updates the PatchInfo channel, which now contains the necessary platform-specific segments for version 8.2.02. If the platform-specific segments are available, the upgrade is complete. If not, the next scheduled Patch Service runs make the segments available.
If you have set the update schedule to Never, you must update the endpoint manually.
To update the endpoints manually 1 Go to Deployment Manager. 2 Create and run a task that upgrades Patch Service on the endpoints. Where to go from here
Use the procedure in Verifying that the upgrade is in place on page 304 to verify the upgrade.
303
Verifying that the upgrade is in place
Verifying that the upgrade is in place

You can use Report Center to run a query to ensure that Patch Service 8.2.02 is installed on the endpoints. You can use Query Builder to create a query that searches for channel URLs, for example, *PatchService. You can then refine the query to search for channel versions that are either equal to or not equal to 8.2.02 (depending on whether you want to know the number endpoints that did or did not get the channel updates).
Verifying the success of the upgrade

Check the transmitter and proxy operations to verify everything is working. Use the following procedure to verify subscribing to channels, publishing channels, and that plug-ins on the transmitter can connect to the appropriate database or LDAP server.
To check transmitter and proxy operations 1 To ensure that the channels hosted on the transmitter work as expected, subscribe
to some channels on the transmitter, especially channels that have plug-ins, such as Scanner Service or Policy Service.
2 If you have not already done so (as part of one of the earlier procedures), verify
that repeaters, mirrors, and proxies can replicate channels correctly from the upgraded master transmitter.
3 Ensure that transmitter plug-ins can establish a connection to the directory service
or database:
A On an endpoint, start a Scanner Service or Policy Service channel with a URL

that points to the newly updated transmitter. For Inventory, starting the channel results in scan report being created and sent to the plug-in on the transmitter. The plug-in, in turn, connects to the database and inserts the scan report.
B Look at the channel plug-in logs on the transmitter to verify that the plug-in
successfully connected to the database or directory service.
4 Repeat this procedure for each upgraded service.

This task applies to the channels Scanner Service, Policy Service, and Logging Service.
304
Whats next?
5 If there are compatibility problems, examine the transmitter admin log.
Whats next?
You now have installed or upgraded Patch Management. If you are upgrading more applications, go to the following chapters, which describe how to upgrade the rest of the Web application channels. A later chapter describes how to upgrade the service channels on the endpoints.
305
Whats next?
306
Chapter
23
23
Upgrading Power Usage Manager

This chapter describes how to upgrade the Power Usage Manager Module. This chapter presents the following topics: Updating Power Usage Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
This chapter is part of the console and Web applications upgrade section. You must complete this chapter and the rest of the Web application chapters as one unit.
NOTE
NOTE
Before you upgrade Power Usage Manager, you must upgrade Report Center, Inventory plug-in, and Logging plug-in. For more information, see 19Upgrading Report Center on page 265
Updating Power Usage Manager

When you have finished updating the Inventory database schema and, if necessary, adding schema for new modules, update Report Center, Inventory plug-in, and Logging plug-in, and then you can update Power Usage Manager. You can print and use the worksheet in Table 1.
Chapter 23 Upgrading Power Usage Manager
307
Updating Power Usage Manager
Table 1
Step 1 2 3 4
Upgrade checklist for Power Usage Manager

Task Log in to the CMS console as a primary administrator. Log in to Transmitter Administration. Copy the Power Usage Manager channel to the master transmitter. Update Power Usage Manager on the CMS console.
To upgrade Power Usage Manager 1 Log in to the CMS console as a primary administrator. 2 Log in to Transmitter Administration: A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
C Click Manage Channels. 3 Copy the Power Usage Manager channel from the transmitter to the master
transmitter. The channel name is PowerUsageManager.

C In Destination path, type the URL of the Power Usage Manager channel; for
example, /Marimba/Current/PowerUsageManager.
D Click Add Channel. 4 Update the Power Usage Manager channel on the console. A Choose Applications => Console => System Settings. B Click Applications Manager. C For Power Usage Manager, under Actions, select stop and then select Update.
5 Restart the channel.

Chapter
24
24
Upgrading Deployment Manager

This chapter describes how to upgrade Deployment Manager and related channels. Deployment Manager depends on other BMC BladeLogic Client Automation modules and is not a standalone product. This chapter presents the following topics: Compatibility with Application Packager and Content Replicator . . . . . . . . . . . . . . 309 Upgrading Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 You must upgrade Deployment Management during the same maintenance window in which the database was upgraded as part of the console web service upgrade.
NOTE
Important: You must follow all the instructions in this chapter only if you are performing an upgrade from M6 to M7.
NOTE
Compatibility with Application Packager and Content Replicator

To use the Application Packager and Content Replicator commands in Deployment Manager requires the presence of Application Packager and Content Replicator. You need to update only the Application Packager and Content Replicator channels that are installed on the tuner that is running Deployment Manager.
Chapter 24 Upgrading Deployment Manager
309

The following section describes how to upgrade Deployment Manager. You can print and use the following worksheet. Table 2
Step 1 2 3 4 5 6 7 8 9 10 11
Upgrade checklist for Deployment Manager

Task Extract the Deployment Manager workspace. Log in to the CMS console as a primary administrator. Log in to Transmitter Administration. Copy the Deployment Manager channel to the master transmitter. Copy the Deployment Manager Command Line channel to the master transmitter. Copy the Content Replicator channel to the master transmitter. Copy the Application Packager channel to the master transmitter. Update Deployment Manager, Deployment Manager Command Line, and Content Replicator on the tuner. Update the Deployment Manager settings page. Populate the Deployment Manager workspace. Verify that Deployment Manager was successfully updated.
Before you begin

Before you update Deployment Manager, back up the workspace, as described in Backing up workspaces and databases on page 218.
To update Deployment Manager 1 Use the -exportDM command line in the Deployment Manager to extract the
Deployment Manager workspace in a .zip file. You use this file to populate the workspace after you upgrade to version 8.2.02. The -exportDM command line also exports the user and group permissions associated with each Deployment Manager object. You can also use the exportUserDB command line to export Deployment Manager users, groups, permissions, and configuration settings to a file. You can then use the importUserDB command line to import these values to another Deployment Manager. See the BMC BladeLogic Client Automation Package Deployment CLI Guide for information about the command-line options in Deployment Manager.
2 Log in to the CMS console as a primary administrator.
310
3 Log in to Transmitter Administration. A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If
C Click Manage Channels. 4 To Upgrade the Deployment Manager Tuner, copy the Infrastructure Service
Channel to the Master Transmitter.

C In Destination path, enter the URL of the Deployment Manager tuner channel;
for example, /Marimba/Current/InfrastructureService.
D Click Add Channel. 5 Copy the Deployment Manager channel from the transmitter to the master
transmitter. The channel name is SDM.
A Click Add a Channel. B In Source URL, enter the path http://products.marimba.com/Current/version8/SDM

or click Browse and select the path of the transmitter.
C In Destination path, enter the URL of the Deployment Manager channel; for
example, /Marimba/Current/SDM.
D Click Add Channel. 6 From Transmitter Administrator, copy the Deployment Manager Command Line
channel from the transmitter to the master transmitter. The channel name is SDMCmd. Repeat step 5 on page 311 using SDMCmd in the source URL and the destination path.
7 If you are using or want to use Content Replicator with Deployment Manager,
copy the Content Replicator channel from the transmitter to the master transmitter. The channel name is Rep. Repeat step 5 on page 311 using Rep in the source URL and the destination path.
311
8 If you are using or want to use Application Packager with Deployment Manager,
copy the Application Packager channel from the transmitter to the master transmitter. The channel name is ApplicationPackager. Repeat step 5 on page 311 using ApplicationPackager in the source URL and the destination path.
9 Upgrade the Deployment Manager tuner: A Log in to Tuner Administration by choosing Applications Infrastructure =>
Tuner Administration.
B Enter the name of the tuner on which the Deployment Manager is running. If
C Under (select an action), select Update tuner and click Go.

10 Update the Deployment Manager, Deployment Manager Command Line, Content

Replicator, and Application Packager channels on the tuner.
A Choose Applications => Infrastructure => Tuner Administration. B Enter the name of the tuner on which the Deployment Manager tuner is
C Click Manage Channels and then click the BBCA Channels tab. D Go to the BBCA Products section. E For the Deployment Manager channel, under Actions, select Update.
After the channel updates, the version number changes to 8.2.02 and the channel restarts.
F Repeat 10E on page 312 for each of the following: the Deployment Manager
Command Line, Content Replicator, and Application Packager channels.
312
11 To specify the database and console information, update the Deployment Manager
Settings page:
A Open Deployment Manager and click the Settings tab. B Click Configure Database Settings and enter the database information. Click OK.
s
Select a database type. Enter the host name, port number, and, for an Oracle database, the database system ID (for SQL Server, the database name is always invdb). The host name must be the same database you used when you set up Schema Manager 8.2.02. The default port numbers are 1521 for Oracle and 1433 for SQL Server. Enter the minimum connections to the database. The default is 5. Enter the maximum connections to the database. The default is 30. Enter the user name. It must be the same user name for the Inventory database. Enter the password. To validate the database connection, click Check Connection. Click OK.
C Restart Deployment Manager if it does not automatically restart. D Choose Settings => Advanced Settings => Configure Console Settings. E Select Enable Report Center Integration, and enter the console information.
You supply the credentials that let you run a Report Center query. The list of machines returned by the query can be used to create a server group.
s
Enter the tuner host name and tuner administration port of the machine on which Report Center (and therefore the console) runs. Use the format host:port. If the console machine is SSL-enabled, use the format https://host:port. The default port is 7717. For example, acme1:7717 or https://acme2:7717. Enter the console user name. Enter the console user password. To validate the console connection, click Check Connection.
313
NOTE
Point to the same console you used when you set up Report Center 8.2.02.
12 Populate the Deployment Manager workspace. A Run the -importDM command in Deployment Manager Command Line to
populate the workspace with the Deployment Manager objects. The data is from the zip file you created in step To on page 310. Deployment Manager stores the workspace in the database.
B To import the log files, run the -importDMLogs command. This step is optional. C Restart Deployment Manager. 13 Open a browser window, log in to Deployment Manager, and verify that the
updated version is running correctly:
s s
In About, verify that the version is now 8.2.02. If you use directory service for authentication, log in as a user other than admin and ensure the correct folder and contents are displayed.
If the upgrade is not successful, or you want to still use the previous version in your production environment, downgrade Deployment Manager back to the earlier version and restore the Deployment Manager workspace.

You have now updated Deployment Manager. The next chapter, Chapter 23, Updating endpoints, on page 311, discusses upgrading the service applications, except for Patch Service.
314
Chapter
25
315 316 316 320 321 321 321 323 324 324
25
Updating endpoints
This chapter describes how to update the tuners on the endpoints and presents the following topics: Disk space requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling MESH in tuners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automatically upgrading the endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manually upgrading endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Troubleshooting endpoint updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . When to use debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before you turn on debugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Turning on debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the debugging log messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Turning off debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ensure you have upgraded the transmitters, including master, mirrors, repeaters, and proxies, the CMS console, and the Web applications on the console before you upgrade the endpoints. You can upgrade the tuners on endpoints only after the transmission infrastructure is upgraded.

During the update process, more disk space is required than during a new installation. Before the tuner update, you need at least 70 MB (80 MB recommended) for Windows machines. You need at least 105 MB of partition space for UNIX machines (110 MB recommended).
Chapter 25
Updating endpoints
315
Enabling MESH in tuners
Enabling MESH in tuners

When upgrading tuners to version 8.2.02, you can enable tuners to use the multiendpoint sychronized host (MESH) feature, which reduces the need for more mirrors, repeaters, and proxies.
To enable MESH in tuners 1 Add the following custom property to the profile: marimba.tuner.p2p.enabled=true.
You can also set this value to true after the tuner is upgraded to 8.2.02.
NOTE
You upgraded Patch Service in an earlier chapter.
Automatically upgrading the endpoints

Upgrading happens automatically when the endpoints check for updates; you can then verify the upgrades. If you do not want to wait for a scheduled upgrade, you can manually upgrade an endpoint. If you are upgrading endpoints using a profile, copy the Infrastructure Service 8.2.02 to the existing Infrastructure Service location. Upgrade the tuner to version 8.2.02 before upgrading the service channels. You can print and use the following worksheet. Table 3
Step 1 2 3 4 5 6 7 8
Upgrade checklist for endpoints (part 1 of 2)

Task Log in to the CMS console as a primary administrator. Log in to Transmitter Administration. Copy Infrastructure Service to the master transmitter. Copy Scanner Service to the master transmitter. Copy Logging Service to the master transmitter. Copy Policy Service to the master transmitter. Copy Deployment Service to the master transmitter. Copy Content Replicator Service to the master transmitter.
316
Table 3
Step 9 10
Upgrade checklist for endpoints (part 2 of 2)

Task Use the schedule to update the endpoints. Verify the upgrade.
You can upgrade from start to finish, or you can stop after each Web application. At the places where you can stop, you can verify the previous step (you must wait until the update schedule runs, however). The places where you can stop are indicated in the procedure by <pause>.
NOTE
If the tuner update order does not matter, you can update Infrastructure Service anywhere between step 3 on page 318 through step 8 on page 319.
Before you begin

s
Before upgrading endpoints, ensure the following applications are added to the firewall exception list. tuner.exe java.exe minituner.exe If these applications are blocked by the firewall, you cannot access the endpoint tuner through the Transmitter Administrator. For more information on firewall requirements and options, see Firewall considerations on page 58.
When upgrading from version 7.5.00, and you had installed on Windows 2008 or Windows Vista, delete the existing Windows Vista,x86/any segment from your master transmitter so that the endpoints can upgrade using the enhanced Windows,x86/any segment. Alternatively, you can copy the 8.2.02 version of the Infrastructure Service to a new location on the master transmitter and make the endpoints perform an Update from.
Chapter 25
Updating endpoints
317
To upgrade the endpoints 1 Log in to the CMS console as a primary administrator. 2 Log in to Transmitter Administration. A Choose Applications => Infrastructure => Transmitter Administration. B Enter the name of the tuner on which the master transmitter is running. If

<pause>
3 Copy the Infrastructure Service channel from the transmitter to the master
transmitter. The channel name is InfrastructureService.

C In Destination path, type the URL of the Infrastructure Service channel; for
example, /Marimba/Current/InfrastructureService.
D Click Add Channel.

<pause>
4 Copy the Scanner Service channel from the transmitter to the master transmitter.
The channel name is InventoryService. Repeat step 3 using InventoryService in source URL and destination path. <pause>
5 If you want, copy the Logging Service channel from the transmitter to the master
transmitter. The channel name is LoggingService. Repeat step 3 using LoggingService in the source URL and the destination path. <pause>
6 If you upgraded Policy Manager, copy the Policy Service channel from the
transmitter to the master transmitter. The channel name is SubscriptionService. Repeat step 3 using SubscriptionService in the source URL and the destination path.
318
NOTE
The Policy Compliance feature depends on Scanner Service and Policy Service scanned data. Hence, it is recommended to upgrade the endpoint's service channels to the latest version before using the Policy Compliance feature.
<pause>
7 If you upgraded Deployment Manager, copy the Deployment Service channel

from the transmitter to the master transmitter. The channel name is SDMClient. Repeat step 3 on page 318 using SDMClient in the source URL and the destination path. <pause>
8 If you upgraded Content Replicator, copy the Content Replicator Service channel
from the transmitter to the master transmitter. You set the channel name during installation. Repeat step 3 on page 318 using the channel name in the source URL and the destination path. <pause>
9 Wait for the endpoints to receive updates at their next scheduled update. The tuner
update schedule was set when you created the profiles for these endpoints.
NOTE
To update the endpoints before the scheduled update time, you can run a manual update. For more information, see Manually upgrading endpoints on page 320.
10 Verify the endpoint updates.

You can use Report Center to run a query that tells you the number of endpoints that have the new versions of the tuner. For example, you can use Query Builder to create a query that searches for tuners for which the release version equals 8.2.02.
NOTE
If the tuner update fails on a particular endpoint, you can use the debugging feature to correct the problem. For instructions, see Troubleshooting endpoint updates on page 321.
For specific applications, you can create a query that searches for channel URLs. For example:
s s
Report Center*InventoryService and *LoggingService Policy Management*SubscriptionService
Chapter 25
Updating endpoints
319
Manually upgrading endpoints
You can then refine the query to search for channel versions that are either equal to or not equal to 8.2.02 (depending on whether you want to know the number of endpoints that did or did not get the channel updates). When the upgrade is finished, the tuner.exe file shows the previous version number until the endpoint is rebooted.
Manually upgrading endpoints

You can make endpoints receive updates sooner than their next scheduled update by using Tuner Administrator or Deployment Manager.
To manually upgrade endpoints 1 Log in to the CMS console as a primary administrator. 2 Use Tuner Administrator to update endpoints: A Choose Applications => Infrastructure => Tuner Administration. B To update one endpoint, enter the name of the tuner on which the endpoint is
C To update more than one endpoint, enter the list of tuners on which the
endpoints are running. If necessary, enter the remote tuner admin user name and password. (All specified tuners must use the same credentials.)
D Select Update tuner action and then click Go 3 You can use Deployment Manager to update endpoints. A Create a custom channel command that starts the Infrastructure Service channel
(leave the Wait for Exit setting as false).
B Use the following Infrastructure Service log IDs in the command:

s s s
32044 for success 32009 for failure 3200032999 for the range
C Create a job that runs the command on a server group that includes the
endpoint or group of endpoints. Because you supply the log IDs, Deployment Manager monitors the success of the tuner upgrade.
320
Troubleshooting endpoint updates
When the upgrade is finished, the Tuner properties still shows the previous version number until the endpoint is restarted.
Troubleshooting endpoint updates

This section describes how to turn on the debugging feature if the profile changes are not applied to a particular endpoint or if the tuner update fails. This debugging feature works for the core tuner properties in profiles, but it does not work for the transmitter-specific settings in transmitter profiles or the proxy-specific settings in proxy profiles.
When to use debugging

You can turn on debugging for the following situations:
s
The Infrastructure Service on the endpoint restarts the tuner even though the profile and the Infrastructure Service on the transmitter have not changed and therefore no update is made. The Infrastructure Service on the endpoint does not restart the tuner even though the profile has changed or a newer version of the Infrastructure Service is available on the transmitter. A tuner update or profile update (of core profile settings) fails.
Before you turn on debugging

Before you turn on debugging, contact BMC Customer Support or use the -preview and -print commands.
s
The -preview command compares the files in the index with the files installed on the file system. This command enables you to verify the current tuner files before performing the update. Running this command is useful when diagnosing problems with the currently installed tuner files. For example, an end user edited a file, such as the properties.txt file, that should not be changed manually, and this is causing the tuner to restart when it should not.
Chapter 25
Updating endpoints
321
Before you turn on debugging
The -print command shows the files that Infrastructure Service has in its index and their corresponding states. These files include profile-related files, binary files, and properties files. This command is useful when you run Infrastructure Service to get a tuner update and no update occurs. This command helps you find out why an update failed by answering these types of questions: Did Infrastructure Service get updated files from the transmitter? Are there subscription permission problems with the transmitter? Did updated files fail to install? Do any files have the wrong state?
Using history.log files

To diagnose upgrade issues, look in the history.log files in the Infrastructure Service channel directory. You do not need to turn on debugging to see the helpful information that is written to these logs.
s
32353 - No changes necessary. If the index shows that neither the tuner binaries in the Infrastructure Service nor the core profile settings (that is, tuner properties) changed, then this message is printed. No changes need to be downloaded from the transmitter. 32465 - No changes to install. Changes were downloaded from the transmitter, but when they were compared to the currently installed tuner binaries and core profile settings, no changed files need to be installed. 32400 - Profile requested. and 32401 - Profile not on the transmitter.
When the profile is not applied at the endpoint, these messages help you find out if the name of the profile that the Infrastructure Service is requesting matches the name of the profile that actually exists on the transmitter. (For example, did you incorrectly type the name of the profile for the Infrastructure Service to use?) The Infrastructure Service channel directory is located in workspaceDir\Ch.X\history1.log where workspaceDir is the tuner workspace directory and Ch.X specifies the channel number for the Infrastructure Service channel. On Windows, the default workspace location is C:\Program Files\Marimba\Tuner\.marimba\keyword\ where keyword is the endpoint keyword. The default keyword is the profile name. On UNIX, the default is /opt/Marimba/Tuner/.marimba/keyword/. To determine the channel number, open the map.txt file in the workspace.
322
Turning on debugging
Turning on debugging
To use the debugging feature on an endpoint, you must add a debug flag. Using the command line is the preferred way to add a flag because debugging is automatically turned off the next time you start the tuner.
s
On UNIX and Windows, you can add the flag by starting the endpoint tuner at the command line with the -java argument. For example, the UNIX syntax is:
./tuner -java -DDEBUGFLAGS=INFRASERVICE=level
Note: If you start the tuner with other tuner arguments, type the -java -DDEBUGFLAGS argument before any other arguments.
s
On Windows, you can alternatively add the flag by adding the

marimba.launch.javaArgs=-DDEBUGFLAGS=INFRASERVICE=level tuner property to the prefs.txt file in the endpoint tuner workspace and then restart the tuner.
The default location of the tuners workspace is C:\Progam Files\BMC Software\BBCA\Tuner\.marimba\keyword\ where keyword is the endpoint keyword that was assigned during installation. The default keyword is the profile name.
Specifying the debug level

The debug level determines the granularity of the debug information. To set the debug level, use one of the values in Table 4. Table 4
Levels 1 2 3 4 5
Debug levels
Description
Print tuner properties that are being applied to the endpoint and the source of each property. Print channel properties that are being applied to the endpoint. Print all files that get mapped and those that get skipped. Print the source for each tuner property. Print the name and length of every file that is installed.
Start with level 2. At that level, you can determine which files that Infrastructure Service needs to create, update, or delete. If the Infrastructure Service is restarting the tuner when it should not, then you can check the files that Infrastructure Service needs to update. If level 2 does not give you enough information, try level 4.
Chapter 25
Updating endpoints
323
Using the debugging log messages
Using the debugging log messages

The debugging information is written to the history.log files in the tuner workspace.
Log file retention

By default, the tuner history logs are rolled according to size (when they reach 128 kilobytes), and one version besides the current version is retained.
Log file locations

On Windows, the default location of the tuners workspace is c:\Program Files\Marimba\Tuner\.marimba\keyword\ where keyword is the endpoint keyword that was assigned during installation. The default keyword is the profile name. On UNIX, the default is /opt/Marimba/Tuner/.marimba/keyword/.
Viewing the log files

You can also view the log messages by starting a Console Window channel. The messages are written to both the Console Window and the logs. On UNIX, the messages are also written to the command-line window following the tuner command.
Turning off debugging

When you finish debugging, turn off debugging. The debugging feature can generate a large volume of log messages, which can cause the history logs to roll sooner than expected. If logs roll too frequently and older logs are deleted, you can lose important information.
s
If you edited the prefs.txt file to turn debugging on, then turn off debugging by deleting the -DDEBUGFLAGS line from the prefs.txt file, and restart the tuner. If you turned debugging on by starting the tuner at the command line and using the -java -DDEBUGFLAGS option, then turn off the feature by restarting the tuner without the -java -DDEBUGFLAGS option.
324
Part
Part 5
Appendices
This part presents the following appendices: Appendix A Database tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Appendix B Using a ghost image to deploy product modules. . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Appendix C Manual database schema installation and updates . . . . . . . . . . . . . . . . . . . . . . . . . 333 Appendix D Migrating to more recent versions of the database type . . . . . . . . . . . . . . . . . . . . . 363
Part 5
Appendices
325
326
Appendix
A
327 328 328 328 331
Database tuning
The commands and guidelines in this appendix provide information that you can use to configure and optimize performance for the Inventory Management System. This appendix presents the following topics: SQL Server database tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Oracle database tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting recommended configuration parameter values. . . . . . . . . . . . . . . . . . . . . Setting recommended configuration parameter values. . . . . . . . . . . . . . . . . . . . . Selecting an Oracle licensing model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SQL Server database tuning

As a best practice, BMC Software recommends that you schedule the following jobs for the SQL Server 2005 or 2008 database.
s
Every week, run the following jobs: DBCC INDEXDEFRAG (invdb, 'dbo.machineapplication') Run this job on all tables in INVDB. exec sp_updatestats
Every month, run DBCC DBREINDEX('invdb.dbo.machineapplication') To keep the database in single user mode, run this job on all tables in INVDB.
Appendix A
Database tuning
327
Oracle database tuning
Oracle database tuning

This section describes how to configure and maintain your Oracle database. In addition to providing specific jobs that you can run to maintain the database, this section also describes how to configure specific components of your Oracle database for the Inventory database.
Setting recommended configuration parameter values

Table 1 lists the recommended parameter settings for an Oracle database. For additional Oracle requirements, see Prerequisites for Oracle on page 55. Table 5
Parameter name
Recommended configuration values for Oracle parameters

Recommended setting 10g Notes + + + + + 500 +
cursor_sharing
db_block_size db_file_multiblock_read_count 8 JOB_QUEUE_PROCESSES greater than 0 max_processess open_cursors
force 8 KB
Indicates how many processes to start. The range is 0 to 10 (default is 0).

Sets the maximum number of processes.
defines the maximum number of open cursors (context areas) a single-user process can have at the same time. Specifies the maximum number of operating system user processes that can simultaneously connect to an Oracle server. A value of 500 or higher prevents session count validation errors during the schema upgrade.
optimizer_mode processes
ALL_ROWS 100
+ +
session_cached_cursors
sessions
100
500
328
Default date format

Use the default date format DD/MON/RR. All Report Center queries are written with the assumption that the DD/MON/RR format is used.
To determine your current date format 1 Log in to sqlplus as the system user. 2 At the command line, execute the following command:
SELECT value FROM V$nls_parameters WHERE parameter ='NLS_DATE_FORMAT';
If the command returns a result other than assumed default format, have your DBA change the date format.
Oracle license and number of endpoints

Consult BMC Customer Support or Oracle to determine your license requirements.
Additional configuration recommendations to consider

s
Rollback (undo) segments: Oracle 10g databases can manage their own rollback (undo) segments. You do not need to plan and refine the number and size of rollback segments. To manage rollback segments on 10g databases, BMC Software recommends that you use the default auto undo management that the Oracle server provides. By default, one million logging records are kept in the mastlog table of the Inventory database. A job runs every hour to ensure that no more than one million records are retained, but you can change the settings that control this job. You can use your database management tools to change the schedule and the number of records kept. For more information, see the appendix in the BMC BladeLogic Client Automation Report Center Guide about managing the mastlog table.
Oracle server disk configuration

Typically, BMC BladeLogic Client Automation recommends RAID disks for the product inventory systems. The ideal setup is a combination of RAID 1 and RAID 5. Place redo log files and archived logs on RAID 1, as these files are written to sequentially (that is, writes are quicker if the disk head does not move in between two successive writes).
Appendix A
Database tuning
329
Additionally, these files tend to be written to more often than read. Also, keep rollback segment data files on RAID 1, as access tends to be sequential. Because other data files tend to have random access, place these on RAID 5. The exception to this is temp data files, which are better suited to RAID 1. The other common configuration is the multiple fixed disks option. Consult Oracle documentation and an Oracle DBA for the many possible combinations of disks. A typical setup follows:
s s s s s s s s
Disk 1: Oracle software, system, tools, control file 1 Disk 2: High-transactions data Disk 3: High-transactions index Disk 4: Rollback segments, control file 2 Disk 5: Low-transactions data Disk 6: Low-transactions index Disk 7: Redo log files 1, export files Disk 8: Redo log files 2, archive log files
Table 6 on page 330 shows the way in Oracle recommends to use RAID disks with database files. Table 6
RAID 0 1 1+0 3 5
Recommendations for RAID disks with Oracle database files

Type of RAID Striping Shadowing Striping with static parity Striping with rotating parity Control file Avoid Best OK OK Database file Redo log file Archive log file OK OK Best OK Best if RAID0-1 not available Avoid Best Avoid Avoid Avoid Avoid Best Avoid Avoid Avoid
Striping and Shadowing OK
Use automatic shared memory management on Oracle 10g

On Oracle 10g, use the automatic shared memory management. Set the SGA_TARGET to the amount of memory you are willing to allocate for the Oracle instance. For instance if you have 3GB of memory to allocate, assign 1GB to the SGA_TARGET and set the SGA_MAX_SIZE to 3GB. Based on load, Oracle dynamically increases the SGA_TARGET up to the SGA_MAX_SIZE value. In addition, set the size of the shared_pool, java_pool, large_pool and db_cache_size to 0. Oracle automatically sizes these values as needed.
330
Selecting an Oracle licensing model

This section provides information about the Inventory database to help you choose an appropriate Oracle licensing model. The BMC BladeLogic Client Automation Inventory Management System uses a middle-tier process to multiplex a large number of clients through a fixed-size pool of SQL*NET connections. The size of this pool is typically five concurrent connections. Using this model, each inventory endpoint (tuner) is counted as an Oracle user. A common mistake is to assume a five-user license. Typically, a processor-based license is required, as this is usually more cost-effective that a per-user license for all inventory endpoints. You should consult your Oracle sales representative before deciding on any particular licensing model.
Appendix A
Database tuning
331
332
Appendix
Using a ghost image to deploy product modules

B
To create a ghost image of a Windows machine to deploy your tuners and the Scanner Service channel to endpoints, perform the tasks described in this appendix to avoid having all the endpoints later return the same (duplicate) tuner ID and machine ID when inventory information is collected. Perform the following tasks prior to creating the Ghost image. Instructions for both Windows and UNIX machines are provided.
s
For Windows, running a command deletes the properties, files, and registry entries that contain the tuner ID and machine ID information. For UNIX machines that you might similarly want to clone to take an image, manually delete the specified properties and files.
This appendix presents the following topics: Preparing a machine to create a ghost image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Using the Software Usage component and ghosting . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Appendix B
333
Preparing a machine to create a ghost image

This section describes the steps that you can take to avoid having all your endpoints report that they have the same machine ID and tuner ID if you use a Ghost image. The issue of duplicate IDs occurs under the following conditions:
s
On the machine that is to be used for creating the image, a tuner is installed and the Scanner Service is run. After the Scanner Service is run, which causes a tuner ID to be created, a Ghost image is taken of the machine. The Ghost image is then installed on the endpoint machines in the enterprise. When the Scanner Service runs again and sends scan reports to the database, all the endpoints report having the same machine and tuner IDs.
You can avoid duplicate endpoints if the Scanner Service is not run prior to the Ghost image being created.
NOTE
After you follow these procedures, you can no longer retrieve the tuner ID that you removed.
Before you begin

Ensure that the tuner is not running.
To prevent the ghost image from creating duplicate tuner IDs on Windows 1 Using a text editor, add the following line to prefs.txt:
marimba.security.token.enable=false
You can find prefs.txt in the following locations:

s s
(Windows) installationDirectory\BMC Software\BBCA\Tuner\.marimba (UNIX) /opt/Marimba/Tuner/.marimba
2 Start the tuner from the command line with the -anonymize argument.
For example, if your tuner is installed in C:\Program Files\BMC Software\BBCA\ Tuner, type the following command:
C:\Program Files\BMC Software\BBCA\Tuner tuner -anonymize
334
To prevent the ghost image from creating duplicate tuner IDs on UNIX 1 Delete the properties.txt file located in the tuners workspace.
The tuners workspace is usually located in:
/usr/local/Marimba/Tuner/.marimba/ws3/keyword/properties.txt
where keyword is the keyword (by default, the profile name).
2 Delete the following properties and their values from the application.txt file in the
Scanner Service channel directory:
s s
scanner.mac scanner.mac.previous
The scanner.mac properties contain the machine ID and must be deleted. The application.txt file that contains these scanner.mac properties is located in the Scanner Service channel directory:
/usr/local/Marimba/Tuner/.marimba/ws3/profileName/ch.X/
where ch.X represents the channel number. You can use the map.txt file in the tuners workspace to find the channel number for Scanner Service (Tip: the URL name is InventoryService).
3 Optionally, delete the following properties and their values from the application.txt
file in the Scanner Service channel directory:
s s
scanner.newchecksum scanner.newchecksum.previous
These scanner.newchecksum properties tell the Scanner Service to send a differential scan report, rather than a full scan report, which is not appropriate the first time the scanner runs on a new machine. Therefore, it is best to delete these properties.

Create the Ghost image.
Appendix B
335
Using the Software Usage component and ghosting
Using the Software Usage component and ghosting

If you created ghost images of Windows machines, and if you are using the software usage component, complete the following procedure so that software usage information is correctly scanned and reported. If you complete the first four steps of this procedure before you create ghost images, software usage information is correctly scanned and reported. As an alternative to this procedure, you can delete the Scanner Service channel on all ghost machines, and then re-subscribe to this channel on the machines.
To obtain software usage information if you use ghosting 1 Delete the following properties from the channel.txt file in the Scanner Service
channel folder: scanner.swu.harvested=2 scanner.swu.sent=2
2 Set these same properties in the application.txt file in the Scanner Service channel
folder to a value of -1:
3 Delete the following folders:

s s
SoftwareUsageOutput swucache
4 Delete the sum-discovered-dictionary.xml file in the data folder for the Scanner
Service channel.
5 Run the Scanner Service channel twice to generate two .sum files.
336
Appendix
Manual database schema installation and updates

C
This appendix describes how to download files to perform the manual options for installing, reinstalling, and updating the Inventory database schema modules. This appendix presents the following topics: Manually installing or reinstalling the database schema. . . . . . . . . . . . . . . . . . . . . . . Downloading the database schema scripts to install the schema modules . . . . Configuring Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using scripts to update the Inventory database schema . . . . . . . . . . . . . . . . . . . . . . . Update considerations for installation scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changes that are supported from the command line . . . . . . . . . . . . . . . . . . . . . . Updating the Inventory database schema using a single script . . . . . . . . . . . . . . Updating the Inventory database schema using multiple scripts . . . . . . . . . . . . Using a script to update the Infrastructure Status Monitor database schema . . . . . Monitoring the progress of a schema update on Oracle . . . . . . . . . . . . . . . . . . . . . . . Reporting database using SQL Server replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 338 340 342 344 345 345 346 349 357 358 359
Manually installing or reinstalling the database schema

When you manually install the Inventory database schema modules by running scripts from the command line, you can modify the scripts to add or modify tables and choose which scripts to use.
Appendix C Manual database schema installation and updates
337
Schema patch level upgrade support
You might want to manually install or update the database schema

s s s
To control the database schema upgrade scripts, including SQL or Oracle scripts. If you prefer working from the command line instead of the GUI. To divide the upgrade process among different people or groups.
NOTE
If you have installed the Core and other schemas, and then manually reinstall the Core schema, the reinstallation process uninstalls all of the modules and reinstalls only the Core schema.
Schema patch level upgrade support

Before you upgrade the schema, ensure that the target Schema Manager version has the appropriate version level to upgrade your current schema version to the target schema version. This condition is dependent on the dates on which the Schema Manager versions are released. For example, if you are using Schema Manager 8.2.01.003 and you want to upgrade the schema to a higher version in the 8.2.02 category, then you can upgrade to the latest version of the 8.2.02 schema branch (for example, 8.2.02.001), only if Schema Manager 8.2.01.003 is released after 8.2.02. In this scenario, Schema Manager 8.2.01.003 does not support the 8.2.01.003 to 8.2.02 upgrade path, but supports upgrade to 8.2.02.001.
Downloading the database schema scripts to install the schema modules

To install or reinstall the database schema requires that you download the necessary scripts from the Schema Manager module GUI.
Before you begin

Create directories to which you can download the zip files that contain the scripts.
s s
Ensure that each target directory had Read and Write access. To keep track of the directories, assign the schema names to the directories. For example, you might create the following directories: core, swusage, and so forth.
338
Downloading the database schema scripts to install the schema modules
To download the Inventory database schema scripts to install the schema modules 1 In the Schema Manager module, select the Inventory Database tab, and connect to
the Inventory database as the system administrator or inventory user. The Database Schemas page is displayed.
2 On the Schema Modules sub tab, click Install (or Reinstall) for Core. 3 On the Install Options page, select Manual install (or Manual reinstall). 4 Click the link to save the zip file to the directory that you created for the schema.
This zip file also contains scripts for inventory, logging, LDAP synchronization, and Deployment Manager.
NOTE
To download installation scripts for other modules, such as the Software Usage component or the Patch Management module, repeat step 2 on page 339 through step 4 on page 339 for those modules.
5 Extract the directories and files from the .zip file or files you downloaded. For
example, extract the files from the core.zip file to a directory named core_scripts.
6 Copy the appropriate directories to the location where you want to run the scripts.
If you extracted the .zip file to the computer that hosts your database server, you can run the scripts from the location where you extracted them. After you download the scripts, you configure them to work with Report Center, and run them, as described in Configuring Oracle or Configuring Microsoft SQL Server on page 342.
339
Configuring Oracle
Configuring Oracle
The following procedure creates a new invdb database that has the following users: dbo, dbtree, inventory, and user_view. The procedure also grants the necessary permissions for the users that it creates.
Before you begin

s
Verify that your environment meets all necessary prerequisites listed in Prerequisites for Oracle on page 55. Verify that SQL*Plus or a similar SQL client is installed. Configuring the database requires that SQL*Plus or a similar SQL client is installed to source the Inventory database setup scripts. Ensure the sqlplus program is in your execution path. Verify the Oracle parameters for job processes. For details, see Prerequisites for Oracle on page 55. Perform the steps described in To download the Inventory database schema scripts to install the schema modules on page 339.
To configure the new Oracle database 1 Open a command prompt and change to the oracle directory where you
downloaded the Core database scripts, for example:
scriptsDir\installation\oracle\
where scriptsDir is the path to the directory where you extracted the files from the .zip file you downloaded.
2 To change the passwords for the database users, use a text editor to open the
define_variable_values.sql script file, found in the scriptsDir\installation\oracle\inventory\ directory, and change the passwords by
editing the following lines:

DEFINE MRBA_inventory_password = inventory DEFINE MRBA_user_view_password = user_view DEFINE MRBA_dbtree_password = dbtree
The define_variable_values.sql script file is used as an input file to install_inventory.bat which creates the install_inventory.sql script.
340
Configuring Oracle
NOTE
For security reasons, BMC recommends that you change the passwords for the database users (inventory, dbtree, and user_view) that are created during database creation.
3 To change the paths to various data, index, and log files that are created during
installation, use a text editor to open the define_variable_values.sql script file, found in the scriptsDir\installation\oracle\inventory\ directory. This file also enables you to change the file size parameters. You can change the values of any variables that appear in this file. Changing other items besides those listed in this file is not supported.
4 Verify that the database server is running. 5 Run the install_inventory.bat file that creates the install_inventory.sql database script
using the values specified in the define_variable_values.sql file. The batch file starts SQL*Plus, which you must authenticate with the sa user password. This batch file creates tables for inventory, centralized logging, ldapsync, and Report Center. If you want only the centralized logging table to be created, you can run the install_logging.sql script instead of the install_inventory.bat batch file.
6 Respond to the prompts displayed by the script, as follows: A For mrba_system_user, type system, which is the same value you used when
you started sqlplus.
B For mrba_system_password, type manager, which is the same value that you
used when you started sqlplus.
C For mrba_service_name, type the same value that you used for the SID when
you started sqlplus.
NOTE
If security is a concern, be aware the information you enter is screen visible and is also stored as text in the scripts log file.
Information-processing output from the script is displayed including several error messages. These messages are normal during initial installation and are generated when the script attempts to drop existing tables when there are no existing tables to drop. As processing completes, Grant Succeeded and several Synonym created messages are displayed.
341
Configuring Microsoft SQL Server
7 Verify that the installation was successful: A Reconnect to the database. B Type the following command: describe inventory.machine
s
If the command returns information about the machine table, your installation was successful. If an error message is returned, the installation was not successful. Look in the install_inventory.log file for information about the problem. These files are created in directory where you ran the script.
Installing other schemas

To manually install additional schemas, such as the Software Usage schema, LDAP Sync schema, or schemas for other modules (such as Patch Management or Deployment Manager), change to the directory where you initially downloaded the Core database scripts, and using the appropriate script, repeat the procedure described in To configure the new Oracle database on page 340.

The following procedure creates a new invdb database that has the following users: dbo, dbtree, inventory, and user_view. The procedure also grants the necessary permissions for the users that it creates.
s s s s
See Prerequisites for Microsoft SQL Server on page 55. Ensure that osql.exe is in your execution path. Ensure that the sa user on the database server has administrator rights. Perform the steps described in To download the Inventory database schema scripts to install the schema modules on page 339.
To configure the new SQL Server database 1 To change the passwords for the database users, open the following script files
with a text editor:
s s
scriptsDir\installation\sqlserver\inventory\create_database.sql scriptsDir\installation\sqlserver\dbtree\create_dbtree_login.sql
and change the passwords by editing the following lines:

set @MRBA_inventory_password = 'inventory' 342 BMC BladeLogic Client Automation Installation Guide
set @MRBA_user_view_password = 'user_view' set @MRBA_dbtree_password = 'dbtree'
NOTE
For security reasons, BMC recommends you change the passwords for the database users (inventory, dbtree, and user_view) created during database creation.
2 To change the paths to various data, index, and log files created during
installation, open and edit the following script files with a text editor: scriptsDir\installation\sqlserver\inventory\create_database.sql scriptsDir\installation\sqlserver\dbtree\set_datafile_values.sql scriptsDir\installation\sqlserver\dbtree\set_indexfile_values.sql scriptsDir\installation\sqlserver\logging\install_logging.sql Dbtree_dm_scriptsDir\installation\sqlserver\dbtree\dm\set_datafile_values.sql Dbtree_dm_scriptsDir\installation\sqlserver\dbtree\dm\set_indexfile_values.sql Patch_scriptsDir\installation\sqlserver\create_patch_filegroups.sql Health_monitoring_scriptsDir\installation\sqlserver\create_hm_db.sql To install the SQL schema in a custom location, use the following script file: scriptsDir\installation\sqlserver\install_inventory.sql To reinstall the SQL schema in a custom location, use the following script file: scriptsDir\installation\sqlserver\Reinstall_inventory.sql scriptsDir\installation\sqlserver\dbtree\install_dbtree.sql
NOTE
Change any of the values that you need to change. For example, if your database is installed on the D drive rather than the C drive, then change the file paths accordingly. If needed, you can also change the file sizes.
You can change the values of any of the variables in the lines that begin with set @MRBA_. Changing any other items is not supported.
3 Open a command prompt and change to the sqlserver directory where you
downloaded the Core database scripts (scriptsDir\installation\sqlserver\).
4 Run the install_inventory.bat file: A If necessary, edit the install_inventory.bat batch file and modify the values in the
osql line, which are located near the end of the file, as follows: osql -U<sa> -P<xxx> -S<yyy> -iinstall_inventory.sql
343
Using scripts to update the Inventory database schema
where <sa> is the admin user ID, <xxx> is the admin password, and <yyy> is the remote server name (necessary only if you are executing the script from a remote client). The default listed in the file is:
osql -Usa -iinstall_inventory.sql
That is, the admin user ID is sa, and there is no password.
NOTE
Your current directory must be the sqlserver directory listed in this step.
B Run the install_inventory.bat file locally on the server.

This file creates tables for both inventory and centralized logging. Alternatively, if you want only the centralized logging table to be created, you can run install_logging.bat instead of install_inventory.bat. To run the install_inventory.bat (or install_logging.bat) file remotely, add the name of your server as a parameter to the osql line (-SserverName) in install_inventory.bat or install_logging.bat, as mentioned in the previous step.
5 To install the software usage database schema (or schema for other modules you
purchased, such as Patch Management), change to the sqlserver directory where you downloaded the software usage database scripts (or other scripts), and run install_su_schema.bat (or other .bat file).
Using scripts to update the Inventory database schema

Many DBAs prefer to execute scripts to update the database schema modules, but some circumstances can require that you use this update method. After you determine that is the update method to use, you then choose whether you want to download a single script that when run will update the schemas or download a script for each schema to update.
344
Update considerations for installation scripts
NOTE
Before you start any task of reinstallation, uninstallation or upgrade, against an Oracle instance, you must ensure that none of the BBCA application user connections exist against that Oracle instance. If any of the BBCA application user connection exists, the reinstallation, uninstallation or upgrade task fails on Oracle. This happens because of an existing behavior of the Oracle server which requires unspecified time to completely remove the traces of a killed user connections internally. This is a known limitation in Oracle server, and hence it is mandatory to ensure that none of the BBCA application user connections exist against that Oracle instance before starting a reinstall, uninstall or upgrade task.
Update considerations for installation scripts

When you originally installed the Inventory database, if you edited the scripts to make modifications that are not supported, then you must run the database scripts at the command line, and not from the Schema Manager module. Before you run the scripts, however, you must edit them to make the same modifications that you made for the original installation scripts.
s
If you are using Oracle, review lines that begin with DEFINE MRBA_ in the following file: scriptsDir\installation\oracle\inventory\define_variable_values.sql
If you are using SQL Server, review lines that begin with set @MRBA_ in the following files: scriptsDir\installation\sqlserver\inventory\create_database.sql scriptsDir\installation\sqlserver\dbtree\dm\set_datafile_values.sql scriptsDir\installation\sqlserver\dbtree\dm\set_indexfile_values.sql
In these paths, scriptsDir is the path to the directory where you extracted the files from the .zip file you downloaded.
Changes that are supported from the command line

In these files, you can modify variable values, such as paths to various data, index, and log files that are created during installation, as well as file size parameters and passwords for the various database user accounts. BMC Software does not support changes to items that are not listed in these files. Although you can change the paths to the files, you must not change the names of the files.
345
Updating the Inventory database schema using a single script
If you are using Oracle, BMC Software supports changes to variable values in the lines that begin with DEFINE MRBA_. If you are using SQL Server, BMC Software supports changes to variable values in lines that begin with set @MRBA_.
If you change only items that are supported, when you run the upgrade, the changes are automatically applied and preserved. If you change items that are not supported, then before you continue, you must edit the 8.1.00 scripts so that they match the original changes. After you make these changes, you must run the scripts at the command line.

The single-script update option enables you to use SQL*Plus (Oracle) or an OSQL command (Microsoft SQL Server) to run a single script that updates the following schemas:
s s s s
Core LDAP Sync Patch Management Software Usage
The single update script has the following limitations:

s
For Oracle database, you can run the single update script against your database, regardless of the installed schemas. The update script ignores any schemas that are not installed in your database. For Microsoft SQL Server databases, you can run the single update script against your database only if the Core and other schema modules are installed. The single update script does not update the schema for Software License Compliance. To update the Software License Compliance schema from a command line, you must run the update script for that module. You can use the single script option to update the other schema modules and then use the procedure under Updating the Inventory database schema using multiple scripts on page 349 to update the schema for the Software License Compliance module.
346
Before you begin

s
Locate the information in Table 8 on page 349 for the Inventory database schema. Table 7
Item Database type Host name Port number
Database settings required to connect to the Inventory database

Note Select Oracle or Microsoft SQL Server. Host name of the computer on which the database is installed. Commonly used port numbers:
s s
Oracle: 1521 SQL Server: 1433
Database System ID (SID)
For SQL Server, the database name is invdb, unless you edited all the necessary database setup scripts to change this value, which is not recommended. For Oracle RAC, type the net service name, and select Use Net Service Name.
Use Net Service Name
Indicates that the entry in SID is a net service name

s
System administrator user name
Default system administrator user name for Oracle: system Default system administrator user name for SQL Server: sa Default inventory user name: inventory.
System administrator password
Password required to authenticate the user
password for the inventory The default is inventory. user

Note: If a custom password is set, you must provide the appropriate password.
password for the user_view user
The default is user_view.

Your database administrator (DBA) can provide you with these values.
s
Ensure that there are no user connections to the database instance. If necessary, terminate the connections. Create a directory to which you can download the script. Ensure that this directory has Read and Write access.
347
NOTE
If any application user connection to the inventory database instance persists, and you run any of the Oracle maintenance tasks, then you will view the 40071 Error terminating users error message. If any application user connection to the inventory database instance persists, and you run any Oracle install, reinstall, or upgrade tasks, then you will view the ORA-01940: cannot drop a user that is currently connected error message. Since these are known Oracle defects, it is recommended to ensure that there are no persisting user connections to the inventory database.
To download the single script to update the Inventory database schema 1 Log on to the CMS console as a primary administrator. 2 In the Schema Manager module, select the Inventory Database tab, and connect to
3 On the Schema Modules sub tab, for Upgrade Scripts for Core, Patch Management &
Software Usage modules, click Download.
4 In the download dialog box, click Save, and save the zip file to the temporary
directory that you created for the download script.
5 Extract the files to the temporary directory.

The files are extracted to oracle and sqlserver directories below your temporary directory.
To execute the single script to update the Inventory schemas 1 In the directory for your database type, locate the script that corresponds to your
update path. Example: To update the schema modules on Oracle from version 8.2.00, access the oracle directory, and select upgrade_all_8200_current.sql.
2 If you use SQL Server, change to the <extracted directory>\sqlserver directory;

otherwise, skip to 33 on page 353.
3 If you use Oracle, change to one of the following directories:

s s
(Windows) <extracted directory>\oracle (UNIX) <extracted directory>\oracle setup
348
Updating the Inventory database schema using multiple scripts
To match the database installation choices, modify as necessary the lines that begin with DEFINE @MRBA_ in the following file that corresponds to your upgrade path. For example, if you are upgrading from 8.2.00, use upgrade_all_8200_current.sql. To work with the Deployment Manager sizing, see Deployment Manager space requirements on page 224. If you do not use Deployment Manager, the default values increase the size of the database by about 60 megabytes.
4 From the command line, run the script that corresponds to your upgrade path.
Example:
s
For SQL Server, and upgrading from 8.2.00, run upgrade_all_8200_current.bat which is in <extracted directory>\sqlserver. For Oracle, and upgrading from 8.2.00, run upgrade_all_8200_current.sql which is in <extracted directory>\oracle. Use the sqlplus command-line.
5 When prompted for productname and version, type the following values:
set @MRBA_productname = 'Core/inventory' set @MRBA_version = '8.2.01'

When you manually update the database schema, you can control the custom tables to upgrade and the scripts to use.
Before you begin

s
Locate the information in Table 8 for the Inventory database schema. Table 8
Item Database type host name port number

Note Select Oracle or Microsoft SQL Server. Host name of the database server The default port numbers are 1521 (for Oracle) and 1433 (for SQL Server). For SQL Server, the database name is always invdb
database system ID
349
Table 8
Item

Note
s
system administrator user name and password
On SQL Server, the user name is often sa with no password by default. On Oracle, the user name is often system with a default password of manager.
password for the inventory The default is inventory. user

password for the user_view user
The default is user_view.

Your database administrator (DBA) can provide you with these values.
s
Ensure that there are no user connections to the database instance. If necessary, terminate the connections. For each schema to update, create a directory to which you can download the necessary scripts. Ensure that each directory has Read and Write access. To keep track of the directories, assign the schema names to the directories. For example, you might create the following directories: core, swusage, and so forth.
NOTE
If any application user connection to the inventory database instance persists, and you run any of the Oracle maintenance tasks, then you will view the 40071 Error terminating users error message. If any application user connection to the inventory database instance persists, and you run any Oracle install, reinstall, or upgrade tasks, then you will view the ORA-01940: cannot drop a user that is currently connected error message. Since these are known Oracle defects, it is recommended to ensure that there are no persisting user connections to the inventory database.
To update the Inventory schemas using multiple scripts 1 Log on to the CMS console as a primary administrator. 2 In the Schema Manager module, select the Inventory Database tab, and connect to
350
3 On the Schema Modules sub tab under Action, for Core, click Update.
The Core schema contains the Inventory and LDAP synchronization schemas. If you use Deployment Management, the Inventory schema also includes the Deployment Management tables.
4 On the Update Options page, select Manual update, and click Next. 5 Click the Update Core Schema link and save the zip file to the directory that you
created for the core schema. The file contains scripts that database administrators can use to upgrade the Core database tables that support functionality for inventory, logging, LDAP synchronization, and Deployment Management.
6 Click Cancel to return to the Schema Modules tab on the Database Schemas page.
Rebuilding an index using Microsoft SQL Server Management Studio

You can rebuild an index or all indexes on a table using Object Explorer in SQL Server Management Studio. Rebuilding an index drops and recreates the index. This removes fragmentation, reclaims disk space by compacting the pages based on the existing fill factor setting, and reorders the index rows in contiguous pages.
To rebuild an index 1 In Object Explorer, connect to an instance of the SQL Server Database Engine and
then expand that instance.
2 Expand Databases, expand the database that contains the table with the specified
index, and then expand Tables.
3 Expand the table in which the index belongs and then expand Indexes. 4 Right-click the index to rebuild and then click Rebuild. 5 Click OK to start the rebuild operation. To rebuild all indexes on a table 1 In Object Explorer, connect to an instance of the SQL Server Database Engine and
then expand that instance.
2 Expand Databases, expand the database that contains the table with the specified
indexes, and then expand Tables.
351
3 Expand the table in which the indexes belong. 4 Right-click Indexes and then click Rebuild All. 5 Click OK to start the rebuild operation. Table information for machine_patch_history and machine_patch_history_property
From version 7.2.02 and later, the Patch history (machine_patch_history and machine_patch_history_property) implementation was disabled by default. This means that there are no real dependencies on that data by any other feature or application. You can purge the following two tables using truncate table statements. Because this is historical data, there is no harm in making a backup of the data in the two tables and keeping it for reference as well as for future analysis before running these two truncate commands.
To purge the tables using truncate table statements

Run the following two commands as user "sa" against the invdb context to cleanup the history data. If you want to keep any of the data, back up the tables before proceeding.
truncate table machine_patch_history go truncate table machine_patch_history_property go
To execute the scripts to update the Inventory database schema 1 From the hard disk, extract the directories and files from core.zip. 2 If you are using SQL Server, go to installation\sqlserver; otherwise, skip to step 3
on page 353.
352
Deployment Manager uses the database to store required data. To match the database installation choices, modify as necessary in installation\sqlserver\dbtree\dm\ the lines that begin with set @MRBA_ in the following files.
s s s s s
create_dbtree_login.sql (change dbtree password) create_userview_login.sql (change user_view password) install_dbtree.sql (set location and sizes) set_datafile_values.sql (set location and sizes) set_indexfile_values.sql (set location and sizes)
To work with the Deployment Manager sizing, see Deployment Manager space requirements on page 224. If you do not use Deployment Manager, the default values increase the size of the database by about 60 megabytes.
3 If you use Oracle, go to upgrade\oracle (Windows) or upgrade/oracle (UNIX).

To match the database installation choices, modify as necessary the lines that begin with DEFINE @MRBA_ in the following files.
s s
define_variable_values.sql
The file that corresponds to your upgrade path. For example, if you are upgrading from 8.2.00, use upgrade_core_8200_current.sql To work with the Deployment Manager sizing, see Deployment Manager space requirements on page 224. If you do not use Deployment Manager, the default values increase the size of the database by about 60 megabytes.
4 From the command line, run the script that corresponds to your upgrade path.
Note: If you want to upgrade from a pre-8201 version to 8202, before you run the upgrade batch file, perform the following steps: For SQL Server database: If you want to change the file paths of the pm_data and pm_index datafiles, open the core_changes_8200_8201.sql file located in installation\sqlserver, and change the C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\ default power management datafile path to the required file path. For Oracle database: If you want to place the datafiles in a custom location other than the default Oracles datafile location, before you run the the upgrade_core_xxxx_current.sql file, open the define_variable_values file located in upgrade\oracle, and modify the pm_data and pm_index file path to the required location.
353
Example:
s
For SQL Server, and upgrading from 8.2.00, run upgrade_core_8200_current.bat which is in installation\sqlserver. For Oracle, and upgrading from 8.2.00, run upgrade_core_8200_current.sql which is in upgrade\oracle. Use the sqlplus command-line.
5 When prompted for productname and version, type the following values:
set @MRBA_productname = 'Core/inventory' set @MRBA_version = '8.2.00'
6 Run the LDAP Synchronization schema upgrade script that is appropriate for your
database type. Example:
s
For SQL Server, and upgrading from 8.2.x, run upgrade_ldapsync_82x_current.bat, which is in installation\sqlserver\ldapsync. For Oracle, and upgrading from 8.2.x, run upgrade_ldapsync_82x_current.sql, which is in installation\oracle\ldapsync. Use the sqlplus command line.
7 If you previously installed Software Usage, update its schema module: A In Schema Manager, click the Schema Modules tab and then click Update for the
Software Usage module.
B On the Update Options page, select Manual update. C Click the software usage script file link and save the zip file to the directory that
you created for the Software Usage schema.
D From the hard disk, extract the directories and files from swusage.zip. E If you are using Oracle, go to installation\oracle\upgrade; otherwise, skip to step
7F. To match the database installation choices, modify as necessary the lines that begin with DEFINE MRBA_ in the file that is appropriate for your upgrade path. For example, to upgrade from version 8.2.00, use upgrade_swu_8x_current.sql.
F From the command line, run the script that is appropriate for your database
type. For example:
s
For SQL Server and upgrading from 8.0.00 or later, run upgrade_swu_8x_current.bat which is in installation\sqlserver.
354
For Oracle and upgrading from 8.0.00 or later, run upgrade_swu_8x_current.sql which is in installation\oracle\upgrade. Use the sqlplus command-line.
G When prompted for productname and version, type the following values:
set @MRBA_productname = 'softwareusage' set @MRBA_version = '8.2.01'
8 If you have previously installed Patch Management, update the schema for this
module:
A In Schema Manager, click the Schema Modules tab and then click Update for the
Patch Management module.
B On the Update Options page, select Manual update. C Click the Patch Management script file link and save the zip file to the hard disk.
For example, create a folder called patch. (You might create more folders for other modules. To keep track of folders, consider using the module name as the folder name.)
D From the hard disk, extract the directories and files from patch.zip. E If you use SQL Server, there are no files to modify. Skip to step 8G. F If you are using Oracle, go to installation\oracle\upgrade.
To match the database installation choices, modify as necessary the lines that begin with DEFINE MRBA_ in the appropriate file that corresponds to your upgrade path. For example, if you are upgrading from 8.2.00, use upgrade_patch_8000_current.sql.
G From the command line, run the script that is appropriate for your upgrade path
and database type. For example:
s
For SQL Server and upgrading from version 8.2.00, run upgrade_patch_8000_current.bat, which is in installation\sqlserver. For Oracle and upgrading from version 8.2.00, run upgrade_patch_8000_current.sql, which is in installation\oracle\upgrade. Use the sqlplus command-line.
A In Schema Manager, click the Schema Modules tab and then click Update for the
module.
B On the Update Options page, select Manual update.
355
C Click the script file link and save the zip file to the hard disk. For example,
create a folder called slc.
D From the hard disk, extract the directories and files from swcompliance.zip. E From the command line, run the script that corresponds to your upgrade path.
For example:
s
For SQL Server, and upgrading from 8.0.00, run upgrade_swc_8000_current.bat which is in sqlserver\upgrade. For Oracle, and upgrading from 8.0.00, run upgrade_swc_8000_current.sql which is in oracle\upgrade. Use the sqlplus command-line.
9 Install any new schemas.

For each module, follow step 3 on page 351 through step 6 on page 351 with the following changes:
s
Set up Software_Usage, Patch_Management, and Device_Management folders in which to extract the .zip files. SQL Server: There are no files to modify for Software Usage and Device Management. For Patch Management, go to installation\sqlserver and modify as necessary the lines that begin with set @MRBA_ in the create_patch_filegroups file. Oracle: For Software Usage, Patch Management, and Device Management, go to installation\oracle and modify as necessary the lines that begin with DEFINE MRBA_ in the define_variable_values.sql file. From the command line, run one of the scripts in Table 9. Table 9
Database Software Usage SQL Server Oracle Patch Management SQL Server Oracle Device Management SQL Server Oracle install_pda_schema.bat install_pda_schema.sql installation\sqlserver installation\oracle install_patch_schema.bat install_patch_schema.sql installation\sqlserver installation\oracle install_su_schema.bat install_su_schema.sql installation\sqlserver installation\oracle
Schema scripts
Script name Location
10 In Schema Manager, for each module, reinstall the Query Library:

Using a script to update the Infrastructure Status Monitor database schema
A Click the Schema Modules tab. B For a module, click Reinstall. C On the Reinstall Options page, select Custom reinstall. D Select only the Query Library check box.
Selecting Schema overwrites the updates you have already completed.
E Click Reinstall. F For each module, repeat step 10B through step 10E.
Using a script to update the Infrastructure Status Monitor database schema

You can customize the schema update scripts and then run those scripts from the command line interface to update the Infrastructure Status Monitor database schema. To access the schema update scripts, you use the Manual install option to download a zip file that contains scripts.
Before you begin

Create a directory to which you can download the file. Ensure that this directory has Read and Write access.
To download scripts to update the Infrastructure Status Monitor database schema 1 In the Schema Manager module, connect to the Infrastructure Status Monitor

Infrastructure Status Monitor Database Schema Modules sub tab.
3 Under Action, select Update. 4 On the Update Options page, select Manual update, and click the download link. 5 In the File Download box, click Save, and specify the directory that you created for
the file.
357
Monitoring the progress of a schema update on Oracle
To execute the script to update the Infrastructure Status Monitor database schema 1 From the hard disk, extract the directories and files from health_monitoring.zip. 2 From the command line, run the script that corresponds to your upgrade path.
Examples:
s
(SQL Server) When upgrading from 8.0.00, run upgrade_hm_8000_current.bat, which is in upgrade\sqlserver. (Oracle) When upgrading from 8.0.00, run upgrade_hm_8000_current.sql which is in upgrade\oracle. Use the sqlplus command-line. If you are running that on a database server on which only a single Oracle instance is running, run the upgrade_hm_8000_current.bat batch file. If you try to connect a Oracle instance remotely, connect to the appropriate Oracle instance through Sqlplus as a user and then run upgrade_hm_8000_current.sql script, as in the following example:
SQL/>@upgrade_hm_8000_current.sql
3 When the upgrade is completed, check the upgrade_hm_8000_current.log file for any
upgrade problems. You can find the log file in the directory from where you executed the update script.
Monitoring the progress of a schema update on Oracle

You can monitor the progress of the schema updates on Oracle by executing a query from an SQL client tool like SQuirreL SQL Client or Toad. The results of the following SQL query list the progress of the update. The results also include the activities being performed by the upgrade script with timestamps and error messages.
To monitor the progress of a schema update on Oracle 1 At the SQL prompt, execute the following query:
Select * from vlog order by log desc;
358
Reporting database using SQL Server replication
Reporting database using SQL Server replication

The SQL Server database replication strategy is to move reporting to a different database, so that the Report Center read connections can point to the reporting (that is, the Subscriber) database, and all other modules such as inventory, patch, ISM and LDAPDBSync write connections can point to the Master, i.e Publisher database. Starting from 8.2.02, BBCA supports replication configuration for both fresh schema installation, and schema upgrade for replicated enabled environment A Transactional Replication scheme, which specifies unidirectional replication from the publisher to the subscribers through distributors, is used. The data can be sent in real-time. As the data is transmitted to the subscriber, all data changes are processed in the order they were made on the publisher.
Schema Manager
Transactional Replication is typically used with databases where the data changes frequently and constant refreshing of the data is required. The replication process watches the publisher's database for any changes, and distributes the changes, if any, to the replication subscribers. Although Transactional Replication is unidirectional from the publisher to the subscribers through the distributor, in a realistic scenario it is unlikely to use two different servers as publisher and subscriber. Using a separate server as the distributor can help to reduce the load on the publisher. The Transactional Replication mechanism has been certified to work with the publisher and the distributor on one server, and the subscriber on another server.
DB Schema Objects for replication

The entire invdb database, including all the tables, stored procedure, view and functions will be replicated. Some temporary tables which are used for internal processing will not be replicated; these tables are automatically excluded by SQL Server during configuration since those tables do not have a Primary Key. Schemas such as Core, Patch Management, Device Management, Software Usage, Software License Compliance will be replicated.
359
Replication configuration
Replication configuration is supported only through the UI because many schemas such as patch, software usage, and SLC exist, and the customer does not need all the schemas. So providing replication scripts will not help if the customer has only a few schemas.
Replication configuration for fresh schema and upgraded schema

Supported SQL Server
The SQL Server 2005 SP4 patch should be available for the publisher, distributor and subscriber database servers. BMC certifies SQL Server 2005 SP4 and 2008 SP3 database servers.
Prerequisites To ensure the following pre-requisites for replication configuration: 1 Install Schema Manager 8.2.02 in both Publisher and Subscriber database. 2 Identify the SQL server 2005 SP4 or 2008 SP3 installed machine for publisher,
distributor and subscriber.
3 Verify the version of the Service Pack patch using the following query:
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
4 Install the schema in publisher and subscriber databases, and confirm that both db
servers can be connected to from the BMC BladeLogic Client Automation applications. If you want to configure a separate database for Distributor, then follow the steps to configure the distributor database. After configuring the distributor database, you must link the Publisher database and then perform the steps configuring replication publisher configuration to configure the Publisher and Subscriber databases.
Upgrading Schema in a replicated environment

We support SQL Server Replication from 8.2.00 version. Perform the following steps to upgrade the BBCA supported SQL Server Replicated environment to 8.2.02.
360
To upgrade schema in a replicated environment: 1 Delete the existing replication configuration. This step deletes the subscription
also.
2 Right click and delete Replication -> Local Publication -> invdb82-8201
(Publication Name).
3 Use SQL Studio to delete the invdb from the subscriber database. 4 Upgrade all the required modules in the Publisher database to 8.2.02 using the
Schema Manager.
5 Install the fresh schema 8.2.02 in subscriber database and confirm that both the
database servers can connect from BBCA applications.
6 Follow the steps in To perform replication publisher database configuration: on

page 362
To perform replication distributor database configuration 1 Log on to the distributor database. 2 In the Object Explorer, right-click on Replication and click Configure
Distribution. The Configure Distribution Wizard is displayed.
3 Select <distributor name> will act as its own distributor. SQL Server will create a
distribution database and log option.
4 Click Next.
Configure Distribution Wizard displays the Snapshot Folder page.
5 Click Next. 6 Configure Distribution Wizard displays the Distribution Database page. 7 Click Next.
Configure Distribution Wizard displays the Publishers page.
8 Click Add and select Add SQL Server Publisher.

Configure Distribution Wizard displays the Connect to Server dialog box.
361
9 In the Connect to Server dialog box, specify the log on credentials, click connect. 10 In Configure Distribution Wizard, click Next.
Configure Distribution Wizard displays the Distributor Password page.
11 In the Password text box, type the password. 12 In the Confirm Password text box, type the password. 13 Click Next.
Configure Distribution Wizard displays the Wizard Actions page.
14 Select Configure distribution, and click Next.

Configure Distribution Wizard displays the Complete the Wizard page which shows a summary of the options selected.
15 Click Finish.
Configure Distribution Wizard displays the Configuring... page.
16 After the distributor configuration is completed, click Close.

The distribution configuration is configured and linked to the Publisher database.
To perform replication publisher database configuration: 1 Log on to publisher database -> Replication -> Local Publications. 2 Right-click -> New Publication - > "invdb" (select the db) -> Click Next.->
Transactional Publication Articles -> Object to Publish.
3 Select Tables, Stored Procedures, Views and User Defined Functions. 4 Set Tables object properties. 5 Set the following two properties values for table objects and set the other
properties to the default value. Copy Permission: True Action if name is in use: Drop existing Object and create a new one
362
After setting the common properties for all the table objects, you must set the properties for machine_power_state, patch_lookup, patch, and os_patch table object.
6 Right click on machine_power_state, patch_lookup, patch, and os_patch table, and

select Set Properties of This Table Article.
7 Set the following two properties values for machine_power_state, patch_lookup,

patch, and os_patch table object and set the other properties to the default value. Action if name is in use: Keep existing object unchanged Copy Permission: True
8 Set the Stored Procedure Objects. 9 Set the following property value for stored procedure, view and user defined
functions objects and the other properties must be the default value. Action if name is in use: Keep existing object unchanged
10 Click next on Article issues. 11 Click next on Filter table rows. 12 In the Snapshot Agent window select the Create a snapshot immediately and
keep the snapshot available to initialize subscriptions check box.
13 In the Agent Security window, select Security settings and select the Using the
following SQL Server Login setting.
14 In the Wizard Action window, select the Create the Publication check box. 15 In the Complete the Wizard window type the Publication Name (for example:
publish-invdb-34), and click the Finish button for creating the publication.
16 After successful publication, right-click the published database to verify that the
snapshot has been successfully created: Local Publications -> publish-invdb-34 -> View Snapshot Agent Status The snapshot creation takes some time for the published db objects; wait until the Status tab displays successful snapshot creation.
363
To perform replication subscriber configuration: 1 Right-click the published database. For example, publish-invdb-34 -> New
Subscriptions ->Click Next in New Subscription-> Click Next after Publication.
2 In the Distribution Agent Location window select the first option. 3 In the Subscriber window add a subscriber using the Add Subscriber button for
SQL server by connecting to the database using sa user, and select invdb.
4 In the Distribution Agent Security window, select Security settings and select the
Using the following SQL Server Login setting.
5 In Synchronization schedule set Agent Schedule to Run continuously. 6 In Initialize Subscriptions, select the Initialize check box and set Initialize When
to Immediately.
7 In Wizard Actions select the Create the subscription(s) check box. 8 Click the Finish button on the last page to complete the subscription configuration. 9 Verify the configuration status by checking the status in the Replication Monitor.
In the CMS, after the SQL Server replication setup has been configured, you must change the Reporting Connection to point to the subscriber database after the replication configuration and Initial synchronization are completed.
To perform final configurations in the application: 1 Perform the following configuration change before checking the replication data.
CMS -> Data Source -> Database
s
Inventory connection must point to the Publisher database. Reporting connection must point to the subscriber database.
NOTE
If the cms is configured with replication environment,after upgrade inventory and user_view connection would point to same database.
In the CMS, after the SQL Server replication setup has been configured, you must change the Reporting Connection to point to the subscriber database after the replication configuration and Initial synchronization are completed.
364
Minimum requirements specification for Replication Setup

Following editions of SQL Server are supported for Replication in this release:
s
SQL Server 2005 SP4 Service pack and above SQL Server 2008 SP3 Service Pack and above SQL Server 2012
365
366
Appendix
Migrating to more recent versions of the database type

D
This appendix describes how to migrate your data from older versions of the supported database types. Migrating from Microsoft SQL Server 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 Migrating from Oracle 9i to Oracle 10g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Migrating from Microsoft SQL Server 2000

Beginning with version 7.5.00, BMC BladeLogic Client Automation dropped support for SQL Server 2000. Before you upgrade your current schema modules to version 8.2.02, BMC Software recommends that you migrate your data to the new database type. Although the BMC BladeLogic Client Automation product supports upgrades from version 7.1.00 and later, you still can use Schema Manager to update the schema modules from version 7.0.
To migrate data from SQL Server 2000 1 Back up the SQL Server 2000 database. 2 On the SQL Server 2005 or 2008 database, create all user logins, including any
custom logins.
3 Restore the database to the SQL Server 2005 or 2008 database.
Appendix D
367
Migrating from Oracle 9i to Oracle 10g
4 Using Figure 1 as a guide, create the sp_change_users_login script for all users,
including all custom users. Figure 1 sp_change_users_login script
use invdb go sp_changedbowner 'sa' go sp_change_users_login 'Update_One', 'inventory','inventory' go sp_change_users_login 'Update_One', 'user_view','user_view' go sp_change_users_login 'Update_One', 'dbtree','dbtree' go ......................execute sp_change_users_login for all custom logins go sp_change_users_login 'Report' go
5 Run the sp_change_users_login script. 6 Run DBCC UPDATEUSAGE.

After migrating to the new database, some of the rows, used pages, reserved pages, leaf pages, and data page counts for each partition in table and indexes can become incorrect. The DBCC statement corrects any of these problems that might have occurred.

1. Upgrade Schema Manager, as described in Upgrading Schema Manager module on page 256. 2. Upgrade the schema modules, as described in the online Help and in Using scripts to update the Inventory database schema on page 341. You can update the database schema modules from version 8.0 or later to version 8.2.02.

In addition to describing how to migrate to Oracle 10g, the following procedures describe how to create the scripts that you will need to run during the migration process.
368
To create the necessary migration scripts 1 Using a text editor, create the prepare_for_import.sql script, as shown in Figure 2.
Figure 2 prepare_for_import.sql script
drop user inventory cascade; drop user dbtree cascade; drop user user_view cascade; drop role inv_view; drop role dbtree_role; create user inventory identified by inventory default tablespace inv_data temporary tablespace temp QUOTA unlimited ON inv_data QUOTA unlimited ON inv_index QUOTA unlimited ON inv_data_2 QUOTA unlimited ON inv_index_2 QUOTA unlimited ON log_data QUOTA unlimited ON log_index QUOTA unlimited ON dbtree_data QUOTA unlimited ON dbtree_index QUOTA unlimited ON dm_dbtree_data QUOTA unlimited ON dm_dbtree_index; create user dbtree identified by dbtree default tablespace dbtree_data temporary tablespace temp QUOTA unlimited ON dbtree_data QUOTA unlimited ON dbtree_index; create user user_view identified by user_view default tablespace dbtree_data temporary tablespace temp; create role dbtree_role; create role inv_view; grant grant grant grant grant create session to inv_view; create session to dbtree_role; inv_view to user_view; dbtree_role to inventory; dbtree_role to user_view;
If you use Patch Manager, add the following line to the prepare_for_import.sql script, after the statement that begins with create user inventory.
QUOTA 8000M ON patch_data QUOTA 12000M ON patch_index;
2 Using a text editor, create the gather_status.sql script, as shown in Figure 3.

Figure 3 gather_status.sql script
/* Compute statistics after importing the inventory database */ execute dbms_stats.gather_schema_stats( OWNNAME => 'INVENTORY', CASCADE => true, estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'for all indexed columns size auto');
Appendix D
369
To migrate the database from Oracle 9i to Oracle 10g 1 On the Oracle 9i production database, run the following command, replacing the
password, dump file name, and log file name.
exp system/password file=c:\CustomerData\exported_db.dmp buffer=1024000 owner=INVENTORY,DBTREE,USER_VIEW log=ExportCustomerDB.log
This command creates a database dump file and a log file of the transaction.
2 To create the required synonyms, tablespaces, and so forth, on the new Oracle 10g
database, install the version of the database schema that is running on your Oracle 9i database. For example, if you exported data from 7.1.01 database, install the 7.1.01 schema on the Oracle 10g database.
3 On the new Oracle 10g database, start SQL*Plus and type the following command
to run the prepare_for_import.sql script: sqlplus system/marimba@orclservice @prepare_for_import.sql This script drops all objects that will be created with Import command in next step.
4 To import the database dump file into the new Oracle 10g database, type the
following command, using the database dump file and log file names that you used in step 1:
imp system/marimba@orclservice file=C:\CustomerData\exported_db.dmp buffer=1024000 fromuser=inventory,dbtree,user_view touser=inventory,dbtree,user_view feedback=1000000 log=ImportCustomerDB.txt
5 On the new Oracle 10g database, in SQL*Plus, type the following command to run
the gather_stats.sql script.
sqlplus system/marimba@orclservice @gather_stats.sql
This script gathers statistics about the new database. Gathering statistics is a time consuming task.
370

1. Upgrade Schema Manager, as described in Upgrading Schema Manager module on page 256. 2. Upgrade the schema modules, as described in the online Help and in Using scripts to update the Inventory database schema on page 341. You can update the database schema modules to version 8.2.02.
Appendix D
371
372
Third-party product terms

The following terms apply to third-party products that are included with or in a BMC Software product as described in the BMC Software, Inc., License Agreement that is applicable to the BMC Software product.
Apache Software License, Version 2.0

This product includes the Apache software product found at http://apache.org , and the Apache software product is distributed to us pursuant to the following terms and conditions: Copyright (c) 2000-2004 The Apache Software Foundation. All rights reserved. TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, nonexclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.
BSD License
Copyright (c) 2009, Yahoo! Inc. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Common Public License Version 1.0

SOME OF THE ACCOMPANYING PROGRAMS ARE PROVIDED UNDER THE TERMS OF THIS COMMON PUBLIC LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT. [List each third party software that is included in this release] 1. DEFINITIONS "Contribution" means: a) in the case of the initial Contributor, the initial code and documentation distributed under this Agreement, and b) in the case of each subsequent Contributor: i) changes to the Program, and ii) additions to the Program; where such changes and/or additions to the Program originate from and are distributed by that particular Contributor. A Contribution 'originates' from a Contributor if it was added to the Program by such Contributor itself or anyone acting on such Contributor's behalf. Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program. "Contributor" means any person or entity that distributes the Program. "Licensed Patents " mean patent claims licensable by a Contributor which are necessarily infringed by the use or sale of its Contribution alone or when combined with the Program. "Program" means the Contributions distributed in accordance with this Agreement. "Recipient" means anyone who receives the Program under this Agreement, including all Contributors. 2. GRANT OF RIGHTS a) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense the Contribution of such Contributor, if any, and such derivative works, in source code and object code form. b) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free patent license under Licensed Patents to make, use, sell, offer to sell, import and otherwise transfer the Contribution of such Contributor, if any, in source code and object code form. This patent license shall apply to the combination of the Contribution and the Program if, at the time the Contribution is added by the Contributor, such addition of the Contribution causes such combination to be covered by the Licensed Patents. The patent license shall not apply to any other combinations which include the Contribution. No hardware per se is licensed hereunder. c) Recipient understands that although each Contributor grants the licenses to its Contributions set forth herein, no assurances are provided by any
Contributor that the Program does not infringe the patent or other intellectual property rights of any other entity. Each Contributor disclaims any liability to Recipient for claims brought by any other entity based on infringement of intellectual property rights or otherwise. As a condition to exercising the rights and licenses granted hereunder, each Recipient hereby assumes sole responsibility to secure any other intellectual property rights needed, if any. For example, if a third party patent license is required to allow Recipient to distribute the Program, it is Recipient's responsibility to acquire that license before distributing the Program. d) Each Contributor represents that to its knowledge it has sufficient copyright rights in its Contribution, if any, to grant the copyright license set forth in this Agreement. 3. REQUIREMENTS A Contributor may choose to distribute the Program in object code form under its own license agreement, provided that: a) it complies with the terms and conditions of this Agreement; and b) its license agreement: i) effectively disclaims on behalf of all Contributors all warranties and conditions, express and implied, including warranties or conditions of title and noninfringement, and implied warranties or conditions of merchantability and fitness for a particular purpose; ii) effectively excludes on behalf of all Contributors all liability for damages, including direct, indirect, special, incidental and consequential damages, such as lost profits; iii) states that any provisions which differ from this Agreement are offered by that Contributor alone and not by any other party; and iv) states that source code for the Program is available from such Contributor, and informs licensees how to obtain it in a reasonable manner on or through a medium customarily used for software exchange. When the Program is made available in source code form: a) it must be made available under this Agreement; and b) a copy of this Agreement must be included with each copy of the Program. Contributors may not remove or alter any copyright notices contained within the Program. Each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution. 4. COMMERCIAL DISTRIBUTION Commercial distributors of software may accept certain responsibilities with respect to end users, business partners and the like. While this license is intended to facilitate the commercial use of the Program, the Contributor who includes the Program in a commercial product offering should do so in a manner which does not create potential liability for other Contributors. Therefore, if a Contributor includes the Program in a commercial product offering, such Contributor ("Commercial Contributor") hereby agrees to defend and indemnify every other Contributor ("Indemnified Contributor") against any losses, damages and costs (collectively "Losses") arising from claims, lawsuits and other legal actions brought by a third party against the Indemnified Contributor to the extent caused by the acts or omissions of such Commercial Contributor in connection with its distribution of the Program in a commercial product offering. The obligations in this section do not apply to any claims or Losses relating to any actual or alleged intellectual property infringement. In order to qualify, an Indemnified Contributor must: a) promptly notify the Commercial Contributor in writing of such claim, and b) allow the Commercial Contributor to control, and cooperate with the Commercial Contributor in, the defense and any related settlement negotiations. The Indemnified Contributor may participate in any such claim at its own expense. For example, a Contributor might include the Program in a commercial product offering, Product X. That Contributor is then a Commercial Contributor. If that Commercial Contributor then makes performance claims, or offers warranties related to Product X, those performance claims and warranties are such Commercial Contributor's responsibility alone. Under this section, the Commercial Contributor would have to defend claims against the other Contributors related to those performance claims and warranties, and if a court requires any other Contributor to pay any damages as a result, the Commercial Contributor must pay those damages. 5. NO WARRANTY EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is solely responsible for determining the appropriateness of using and distributing the Program and assumes all risks associated with its exercise of rights under this Agreement, including but not limited to the risks and costs of program errors, compliance with applicable laws, damage to or loss of data, programs or equipment, and unavailability or interruption of operations. 6. DISCLAIMER OF LIABILITY EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 7. GENERAL If any provision of this Agreement is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this Agreement, and without further action by the parties hereto, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable. If Recipient institutes patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to such Recipient under this Agreement shall terminate as of the date such litigation is filed. In addition, if Recipient institutes patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Program itself (excluding combinations of the Program with other software or hardware) infringes such Recipient's patent(s), then such Recipient's rights granted under Section 2(b) shall terminate as of the date such litigation is filed. All Recipient's rights under this Agreement shall terminate if it fails to comply with any of the material terms or conditions of this Agreement and does not cure such failure in a reasonable period of time after becoming aware of such noncompliance. If all Recipient's rights under this Agreement terminate, Recipient agrees to cease use and distribution of the Program as soon as reasonably practicable. However, Recipient's obligations under this Agreement and
any licenses granted by Recipient relating to the Program shall continue and survive. Everyone is permitted to copy and distribute copies of this Agreement, but in order to avoid inconsistency the Agreement is copyrighted and may only be modified in the following manner. The Agreement Steward reserves the right to publish new versions (including revisions) of this Agreement from time to time. No one other than the Agreement Steward has the right to modify this Agreement. IBM is the initial Agreement Steward. IBM may assign the responsibility to serve as the Agreement Steward to a suitable separate entity. Each new version of the Agreement will be given a distinguishing version number. The Program (including Contributions) may always be distributed subject to the version of the Agreement under which it was received. In addition, after a new version of the Agreement is published, Contributor may elect to distribute the Program (including its Contributions) under the new version. Except as expressly stated in Sections 2(a) and 2(b) above, Recipient receives no rights or licenses to the intellectual property of any Contributor under this Agreement, whether expressly, by implication, estoppel or otherwise. All rights in the Program not expressly granted under this Agreement are reserved. This Agreement is governed by the laws of the State of New York and the intellectual property laws of the United States of America. No party to this Agreement will bring a legal action under this Agreement more than one year after the cause of action arose. Each party waives its rights to a jury trial in any resulting litigation.
GNU LESSER GENERAL PUBLIC LICENSE (LGPL v2.1) ++

Various media for this product contains Cewolf - Chart TagLib v.1.0 ("Library") and JFreeChart, which is licensed under the terms of the GNU Lesser General Public License, Version 2.1 ("LGPL"). Copies of the LGPL and the source code of the Library are provided on a separate distribution disk for this product. NO WARRANTY BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. The terms and conditions of the BMC Software agreement applicable to this product do not apply to the Library to the extent that any such term or condition imposes any further restriction on the exercise of any right with respect to the Library granted under the GPL. Certain object code of BMC software has been linked with the Library (the "Linked Software"). Although the terms of the LGPL are ambiguous and copyright law is uncertain with respect to application of the LGPL to Software, BMC is producing and distributing the Software in compliance with the LGPL to the extent the LGPL may apply. Accordingly, solely to the extent required by terms of the LGPL, the licensee of Software may modify the Software for the licensee's own use and reverse engineer the Software for debugging the permitted modifications.
IBM Public License Version 1.0

THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS IBM PUBLIC LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT. 1. DEFINITIONS "Contribution" means: in the case of International Business Machines Corporation ("IBM"), the Original Program, and in the case of each Contributor, changes to the Program, and additions to the Program; where such changes and/or additions to the Program originate from and are distributed by that particular Contributor. A Contribution 'originates' from a Contributor if it was added to the Program by such Contributor itself or anyone acting on such Contributor's behalf. Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program. "Contributor" means IBM and any other entity that distributes the Program. "Licensed Patents " mean patent claims licensable by a Contributor which are necessarily infringed by the use or sale of its Contribution alone or when combined with the Program. "Original Program" means the original version of the software accompanying this Agreement as released by IBM, including source code, object code and documentation, if any. "Program" means the Original Program and Contributions. "Recipient" means anyone who receives the Program under this Agreement, including all Contributors. 2. GRANT OF RIGHTS Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense the Contribution of such Contributor, if any, and such derivative works, in source code and object code form. Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free patent license under Licensed Patents to make, use, sell, offer to sell, import and otherwise transfer the Contribution of such Contributor, if any, in source code and object code form. This patent license shall apply to the combination of the Contribution and the Program if, at the time the Contribution is added by the Contributor, such addition of the Contribution causes such combination to be covered by the Licensed Patents. The patent license shall not apply to any other combinations which include the Contribution. No hardware per se is licensed hereunder. Recipient understands that although each Contributor grants the licenses to its Contributions set forth herein, no assurances are provided by any Contributor that the Program does not infringe the patent or other intellectual property rights of any other entity. Each Contributor disclaims any liability to Recipient for claims brought by any other entity based on infringement of intellectual property rights or otherwise. As a condition to exercising the rights and licenses granted hereunder, each Recipient hereby assumes sole responsibility to secure any other intellectual property rights needed, if any. For example, if a third party patent license is required to allow Recipient to distribute the Program, it is Recipient's responsibility to acquire that license before distributing the Program. Each Contributor represents that to its knowledge it has sufficient copyright rights in its Contribution, if any, to grant the copyright license set forth in this
Agreement. 3. REQUIREMENTS A Contributor may choose to distribute the Program in object code form under its own license agreement, provided that: it complies with the terms and conditions of this Agreement; and its license agreement: effectively disclaims on behalf of all Contributors all warranties and conditions, express and implied, including warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability and fitness for a particular purpose; effectively excludes on behalf of all Contributors all liability for damages, including direct, indirect, special, incidental and consequential damages, such as lost profits; states that any provisions which differ from this Agreement are offered by that Contributor alone and not by any other party; and states that source code for the Program is available from such Contributor, and informs licensees how to obtain it in a reasonable manner on or through a medium customarily used for software exchange. When the Program is made available in source code form: it must be made available under this Agreement; and a copy of this Agreement must be included with each copy of the Program. Each Contributor must include the following in a conspicuous location in the Program: Copyright (C) 1996, 1999 International Business Machines Corporation and others. All Rights Reserved. In addition, each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution. 4. COMMERCIAL DISTRIBUTION Commercial distributors of software may accept certain responsibilities with respect to end users, business partners and the like. While this license is intended to facilitate the commercial use of the Program, the Contributor who includes the Program in a commercial product offering should do so in a manner which does not create potential liability for other Contributors. Therefore, if a Contributor includes the Program in a commercial product offering, such Contributor ("Commercial Contributor") hereby agrees to defend and indemnify every other Contributor ("Indemnified Contributor") against any losses, damages and costs (collectively "Losses") arising from claims, lawsuits and other legal actions brought by a third party against the Indemnified Contributor to the extent caused by the acts or omissions of such Commercial Contributor in connection with its distribution of the Program in a commercial product offering. The obligations in this section do not apply to any claims or Losses relating to any actual or alleged intellectual property infringement. In order to qualify, an Indemnified Contributor must: a) promptly notify the Commercial Contributor in writing of such claim, and b) allow the Commercial Contributor to control, and cooperate with the Commercial Contributor in, the defense and any related settlement negotiations. The Indemnified Contributor may participate in any such claim at its own expense. For example, a Contributor might include the Program in a commercial product offering, Product X. That Contributor is then a Commercial Contributor. If that Commercial Contributor then makes performance claims, or offers warranties related to Product X, those performance claims and warranties are such Commercial Contributor's responsibility alone. Under this section, the Commercial Contributor would have to defend claims against the other Contributors related to those performance claims and warranties, and if a court requires any other Contributor to pay any damages as a result, the Commercial Contributor must pay those damages. 5. NO WARRANTY EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is solely responsible for determining the appropriateness of using and distributing the Program and assumes all risks associated with its exercise of rights under this Agreement, including but not limited to the risks and costs of program errors, compliance with applicable laws, damage to or loss of data, programs or equipment, and unavailability or interruption of operations. 6. DISCLAIMER OF LIABILITY EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 7. GENERAL If any provision of this Agreement is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this Agreement, and without further action by the parties hereto, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable. If Recipient institutes patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to such Recipient under this Agreement shall terminate as of the date such litigation is filed. In addition, if Recipient institutes patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Program itself (excluding combinations of the Program with other software or hardware) infringes such Recipient's patent(s), then such Recipient's rights granted under Section 2(b) shall terminate as of the date such litigation is filed. All Recipient's rights under this Agreement shall terminate if it fails to comply with any of the material terms or conditions of this Agreement and does not cure such failure in a reasonable period of time after becoming aware of such noncompliance. If all Recipient's rights under this Agreement terminate, Recipient agrees to cease use and distribution of the Program as soon as reasonably practicable. However, Recipient's obligations under this Agreement and any licenses granted by Recipient relating to the Program shall continue and survive. IBM may publish new versions (including revisions) of this Agreement from time to time. Each new version of the Agreement will be given a distinguishing version number. The Program (including Contributions) may always be distributed subject to the version of the Agreement under which it was received. In addition, after a new version of the Agreement is published, Contributor may elect to distribute the Program (including its Contributions) under the new version. No one other than IBM has the right to modify this Agreement. Except as expressly stated in Sections 2(a) and 2(b) above, Recipient receives no rights or licenses to the intellectual property of any Contributor under this Agreement, whether expressly, by implication, estoppel or otherwise. All rights in the Program not expressly granted under this Agreement are reserved. This Agreement is governed by the laws of the State of New York and the intellectual property laws of the United States of America. No party to this Agreement will bring a legal action under this Agreement more than one year after the cause of action arose. Each party waives its rights to a jury trial in any resulting litigation.
MICROSOFT CAPICOM SOFTWARE DEVELOPMENT KIT

These license terms are an agreement between Microsoft Corporation (or based on where you live, one of its affiliates) and you. Please read them. They apply to the software named above, which includes the media on which you received it, if any. The terms also apply to any Microsoft "updates,
"supplements, "Internet-based services, and "support services for this software, unless other terms accompany those items. If so, those terms apply. BY USING THE SOFTWARE, YOU ACCEPT THESE TERMS. IF YOU DO NOT ACCEPT THEM, DO NOT USE THE SOFTWARE. If you comply with these license terms, you have the rights below. 1. INSTALLATION AND USE RIGHTS. You may install and use any number of copies of the software on your devices to design, develop and test your programs. 2. ADDITIONAL LICENSING REQUIREMENTS AND/OR USE RIGHTS.
a. Media Elements and Templates. You may copy and use images, clip art, animations, sounds, music, shapes, video clips and templates provided with the software and identified for such use in documents and projects that you create. You may distribute those documents and projects non-commercially. If you wish to use these media elements or templates for any other purpose, go to www.microsoft.com/permission to learn whether that use is allowed. b. i. Distributable Code. The software contains code that you are permitted to distribute in programs you develop if you comply with the terms below. Right to Use and Distribute. The code and text files listed below are "Distributable Code." "REDIST.TXT Files. You may copy and distribute the object code form of code listed in REDIST.TXT files. "Sample Code. You may modify, copy, and distribute the source and object code form of code marked as "sample." "OTHER-DIST.TXT Files. You may copy and distribute the object code form of code listed in OTHER-DIST.TXT files. "Third Party Distribution. You may permit distributors of your programs to copy and distribute the Distributable Code as part of those programs. ii. Distribution Requirements. For any Distributable Code you distribute, you must "add significant primary functionality to it in your programs; "require distributors and external end users to agree to terms that protect it at least as much as this agreement; "display your valid copyright notice on your programs; and "indemnify, defend, and hold harmless Microsoft from any claims, including attorneys' fees, related to the distribution or use of your programs. iii. Distribution Restrictions. You may not "alter any copyright, trademark or patent notice in the Distributable Code; "use Microsoft's trademarks in your programs' names or in a way that suggests your programs come from or are endorsed by Microsoft; "distribute Distributable Code, other than code listed in OTHER-DIST.TXT files, to run on a platform other than the Windows platform; "include Distributable Code in malicious, deceptive or unlawful programs; or "modify or distribute the source code of any Distributable Code so that any part of it becomes subject to an Excluded License. An Excluded License is one that requires, as a condition of use, modification or distribution, that "the code be disclosed or distributed in source code form; or "others have the right to modify it. 3. SCOPE OF LICENSE. The software is licensed, not sold. This agreement only gives you some rights to use the software. Microsoft reserves all other rights. Unless applicable law gives you more rights despite this limitation, you may use the software only as expressly permitted in this agreement. In doing so, you must comply with any technical limitations in the software that only allow you to use it in certain ways. You may not "work around any technical limitations in the software; "reverse engineer, decompile or disassemble the software, except and only to the extent that applicable law expressly permits, despite this limitation; "make more copies of the software than specified in this agreement or allowed by applicable law, despite this limitation; "publish the software for others to copy; "rent, lease or lend the software; or "use the software for commercial software hosting services. 4. BACKUP COPY. You may make one backup copy of the software. You may use it only to reinstall the software.
5. DOCUMENTATION. Any person that has valid access to your computer or internal network may copy and use the documentation for your internal, reference purposes. 6. TRANSFER TO A THIRD PARTY. The first user of the software may transfer it and this agreement directly to a third party. Before the transfer, that party must agree that this agreement applies to the transfer and use of the software. The first user must uninstall the software before transferring it separately from the device. The first user may not retain any copies. 7. EXPORT RESTRICTIONS. The software is subject to United States export laws and regulations. You must comply with all domestic and international export laws and regulations that apply to the software. These laws include restrictions on destinations, end users and end use. For additional information, see www.microsoft.com/exporting. 8. SUPPORT SERVICES. Because this software is "as is," we may not provide support services for it.
9. ENTIRE AGREEMENT. This agreement, and the terms for supplements, updates, Internet-based services and support services that you use, are the entire agreement for the software and support services. 10. APPLICABLE LAW. a. United States. If you acquired the software in the United States, Washington state law governs the interpretation of this agreement and applies to claims for breach of it, regardless of conflict of laws principles. The laws of the state where you live govern all other claims, including claims under state consumer protection laws, unfair competition laws, and in tort. b. Outside the United States. If you acquired the software in any other country, the laws of that country apply.
11. LEGAL EFFECT. This agreement describes certain legal rights. You may have other rights under the laws of your country. You may also have rights with respect to the party from whom you acquired the software. This agreement does not change your rights under the laws of your country if the laws of your country do not permit it to do so. 12. DISCLAIMER OF WARRANTY. THE SOFTWARE IS LICENSED "AS-IS." YOU BEAR THE RISK OF USING IT. MICROSOFT GIVES NO EXPRESS WARRANTIES, GUARANTEES OR CONDITIONS. YOU MAY HAVE ADDITIONAL CONSUMER RIGHTS UNDER YOUR LOCAL LAWS WHICH THIS AGREEMENT CANNOT CHANGE. TO THE EXTENT PERMITTED UNDER YOUR LOCAL LAWS, MICROSOFT EXCLUDES THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. 13. LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. YOU CAN RECOVER FROM MICROSOFT AND ITS SUPPLIERS ONLY DIRECT DAMAGES UP TO U.S. $5.00. YOU CANNOT RECOVER ANY OTHER DAMAGES, INCLUDING CONSEQUENTIAL, LOST PROFITS, SPECIAL, INDIRECT OR INCIDENTAL DAMAGES. This limitation applies to "anything related to the software, services, content (including code) on third party Internet sites, or third party programs; and "claims for breach of contract, breach of warranty, guarantee or condition, strict liability, negligence, or other tort to the extent permitted by applicable law. It also applies even if Microsoft knew or should have known about the possibility of the damages. The above limitation or exclusion may not apply to you because your country may not allow the exclusion or limitation of incidental, consequential or other damages. Please note: As this software is distributed in Quebec, Canada, some of the clauses in this agreement are provided below in French. Remarque : Ce logiciel tant distribu au Qubec, Canada, certaines des clauses dans ce contrat sont fournies ci-dessous en franais. EXONRATION DE GARANTIE. Le logiciel vis par une licence est offert " tel quel ". Toute utilisation de ce logiciel est votre seule risque et pril. Microsoft n'accorde aucune autre garantie expresse. Vous pouvez bnficier de droits additionnels en vertu du droit local sur la protection des consommateurs, que ce contrat ne peut modifier. La ou elles sont permises par le droit locale, les garanties implicites de qualit marchande, d'adquation un usage particulier et d'absence de contrefaon sont exclues. LIMITATION DES DOMMAGES-INTRTS ET EXCLUSION DE RESPONSABILIT POUR LES DOMMAGES. Vous pouvez obtenir de Microsoft et de ses fournisseurs une indemnisation en cas de dommages directs uniquement hauteur de 5,00 $ US. Vous ne pouvez prtendre aucune indemnisation pour les autres dommages, y compris les dommages spciaux, indirects ou accessoires et pertes de bnfices. Cette limitation concerne: "tout ce qui est reli au logiciel, aux services ou au contenu (y compris le code) figurant sur des sites Internet tiers ou dans des programmes tiers; et "les rclamations au titre de violation de contrat ou de garantie, ou au titre de responsabilit stricte, de ngligence ou d'une autre faute dans la limite autorise par la loi en vigueur. Elle s'applique galement, mme si Microsoft connaissait ou devrait connatre l'ventualit d'un tel dommage. Si votre pays n'autorise pas l'exclusion ou la limitation de responsabilit pour les dommages indirects, accessoires ou de quelque nature que ce soit, il se peut que la limitation ou l'exclusion ci-dessus ne s'appliquera pas votre gard. EFFET JURIDIQUE. Le prsent contrat dcrit certains droits juridiques. Vous pourriez avoir d'autres droits prvus par les lois de votre pays. Le prsent contrat ne modifie pas les droits que vous confrent les lois de votre pays si celles-ci ne le permettent pas.
Daniel Stenberg COPYRIGHT AND PERMISSION NOTICE

Copyright (c) 1996 - 2009, Daniel Stenberg, daniel@haxx.se. All rights reserved. Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder.
The OpenSymphony (and Quartz) Software License

All source code, binaries, documentation, and other files in the distribution of Quartz are subject to the following copyright and license agreement, unless otherwise documented: Copyright 2004-2005 OpenSymphony Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Prototype License
(c) 2005-2007 Sam Stephenson Prototype is freely distributable under the terms of an MIT-style license. For details, see the Prototype web site: http://prototype.conio.net/ Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
SLF4J License
SLF4J source code and binaries are distributed under the following license. Copyright (c) 2004-2008 QOS.ch All rights reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. These terms are identical to those of the MIT License, also called the X License or the X11 License, which is a simple, permissive non-copyleft free software license. It is deemed compatible with virtually all types of licenses, commercial or otherwise. In particular, the Free Software Foundation has declared it compatible with GNU GPL. It is also known to be approved by the Apache Software Foundation as compatible with Apache Software License.
Sun Microsystems, Inc. Binary Code License Agreement

1. LICENSE TO USE. Sun grants you a non-exclusive and non-transferable license for the internal use only of the accompanying software and documentation and any error corrections provided by Sun (collectively "Software"), by the number of users and the class of computer hardware for which the corresponding fee has been paid. 2. RESTRICTIONS. Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software. Licensee acknowledges that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun Microsystems, Inc. disclaims any express or implied warranty of fitness for such uses. No right, title or interest in or to any trademark, service mark, logo or trade name of Sun or its licensors is granted under this Agreement. 3. LIMITED WARRANTY. Sun warrants to you that for a period of ninety (90) days from the date of purchase, as evidenced by a copy of the receipt, the media on which Software is furnished (if any) will be free of defects in materials and workmanship under normal use. Except for the foregoing, Software is provided "AS IS". Your exclusive remedy and Sun's entire liability under this limited warranty will be at Sun's option to replace Software media or refund the fee paid for Software. 4. DISCLAIMER OF WARRANTY. UNLESS SPECIFIED IN THIS AGREEMENT, ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT THESE DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. 5. LIMITATION OF LIABILITY. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. In no event will Sun's liability to you, whether in contract, tort (including negligence), or otherwise, exceed the amount paid by you for Software under this Agreement. The foregoing limitations will apply even if the above stated warranty fails of its essential purpose. 6. Termination. This Agreement is effective until terminated. You may terminate this Agreement at any time by destroying all copies of Software. This Agreement will terminate immediately without notice from Sun if you fail to comply with any provision of this Agreement. Upon Termination, you must destroy all copies of Software. 7. Export Regulations. All Software and technical data delivered under this Agreement are subject to US export control laws and may be subject to export or import regulations in other countries. You agree to comply strictly with all such laws and regulations and acknowledge that you have the responsibility to obtain such licenses to export, re-export, or import as may be required after delivery to you. 8. U.S. Government Restricted Rights. If Software is being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), then the Government's rights in Software and accompanying documentation will be only as set forth in this Agreement; this is in accordance with 48 CFR 227.7201 through 227.7202-4 (for Department of Defense (DOD) acquisitions) and with 48 CFR 2.101 and 12.212 (for non-DOD acquisitions). 9. Governing Law. Any action related to this Agreement will be governed by California law and controlling U.S. federal law. No choice of law rules of any jurisdiction will apply. 10. Severability. If any provision of this Agreement is held to be unenforceable, this Agreement will remain in effect with the provision omitted, unless omission would frustrate the intent of the parties, in which case this Agreement will immediately terminate. 11. Integration. This Agreement is the entire agreement between you and Sun relating to its subject matter. It supersedes all prior or contemporaneous oral
or written communications, proposals, representations and warranties and prevails over any conflicting or additional terms of any quote, order, acknowledgment, or other communication between the parties relating to its subject matter during the term of this Agreement. No modification of this Agreement will be binding, unless in writing and signed by an authorized representative of each party. JAVAHELPTM VERSION 1.1.3 SUPPLEMENTAL LICENSE TERMS These supplemental license terms ("Supplemental Terms") add to or modify the terms of the Binary Code License Agreement (collectively, the "Agreement"). Capitalized terms not defined in these Supplemental Terms shall have the same meanings ascribed to them in the Agreement. These Supplemental Terms shall supersede any inconsistent or conflicting terms in the Agreement, or in any license contained within the Software. 1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (JavaTM Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software complete and unmodified for the sole purpose of designing, developing and testing your Java applets and applications intended to run on the Java platform ("Programs"). 2. License to Distribute Redistributables. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to Section 3 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute those files specifically identified as redistributable in the Software "README" file ("Redistributables") provided that: (i) you distribute the Redistributables complete and unmodified (unless otherwise specified in the applicable README file), and only bundled as part of your Programs, (ii) you do not distribute additional software intended to supersede any component(s) of the Redistributables, (iii) you do not remove or alter any proprietary legends or notices contained in or on the Redistributables, (iv) you only distribute the Redistributables pursuant to a license agreement that protects Sun's interests consistent with the terms contained in the Agreement, and (v) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. 3. Java Technology Restrictions. You may not modify the Java Platform Interface ("JPI", identified as classes contained within the "java" package or any subpackages of the "java" package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI. In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers. You may not create, or authorize your licensees to create, additional classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun" or similar convention as specified by Sun in any naming convention designation. 4. Java Runtime Availability. Refer to the appropriate version of the Java Runtime Environment binary code license (currently located at http://www.java.sun.com/jdk/index.html) for the availability of runtime code which may be distributed with Java applets and applications. 5. Trademarks and Logos. You acknowledge and agree as between you and Sun that Sun owns the SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET trademarks and all SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET-related trademarks, service marks, logos and other brand designations ("Sun Marks"), and you agree to comply with the Sun Trademark and Logo Usage Requirements currently located at http://www.sun.com/policies/trademarks. Any use you make of the Sun Marks inures to Sun's benefit. 6. Source Code. Software may contain source code that is provided solely for reference purposes pursuant to the terms of this Agreement. Source code may not be redistributed unless expressly provided for in this Agreement. 7. Termination for Infringement. Either party may terminate this Agreement immediately should any Software become, or in either party's opinion be likely to become, the subject of a claim of infringement of any intellectual property right. For inquiries please contact: Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California 94303 (LFI# 114197/Form ID# 011801) JAVAHELPTM VERSION 1.1.3 SUPPLEMENTAL LICENSE TERMS These supplemental license terms ("Supplemental Terms") add to or modify the terms of the Binary Code License Agreement (collectively, the "Agreement"). Capitalized terms not defined in these Supplemental Terms shall have the same meanings ascribed to them in the Agreement. These Supplemental Terms shall supersede any inconsistent or conflicting terms in the Agreement, or in any license contained within the Software. 1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (JavaTM Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software complete and unmodified for the sole purpose of designing, developing and testing your Java applets and applications intended to run on the Java platform ("Programs"). 2. License to Distribute Redistributables. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to Section 3 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute those files specifically identified as redistributable in the Software "README" file ("Redistributables") provided that: (i) you distribute the Redistributables complete and unmodified (unless otherwise specified in the applicable README file), and only bundled as part of your Programs, (ii) you do not distribute additional software intended to supersede any component(s) of the Redistributables, (iii) you do not remove or alter any proprietary legends or notices contained in or on the Redistributables, (iv) you only distribute the Redistributables pursuant to a license agreement that protects Sun's interests consistent with the terms contained in the Agreement, and (v) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. 3. Java Technology Restrictions. You may not modify the Java Platform Interface ("JPI", identified as classes contained within the "java" package or any subpackages of the "java" package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI. In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers. You may not create, or authorize your licensees to create, additional classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun" or similar convention as specified by Sun in any naming convention designation. 4. Java Runtime Availability. Refer to the appropriate version of the Java Runtime Environment binary code license (currently located at http://www.java.sun.com/jdk/index.html) for the availability of runtime code which may be distributed with Java applets and applications. 5. Trademarks and Logos. You acknowledge and agree as between you and Sun that Sun owns the SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET trademarks and all SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET-related trademarks, service marks, logos and other brand designations ("Sun Marks"), and you agree to comply with the Sun Trademark and Logo Usage Requirements currently located at http://www.sun.com/policies/trademarks. Any use
you make of the Sun Marks inures to Sun's benefit. 6. Source Code. Software may contain source code that is provided solely for reference purposes pursuant to the terms of this Agreement. Source code may not be redistributed unless expressly provided for in this Agreement. 7. Termination for Infringement. Either party may terminate this Agreement immediately should any Software become, or in either party's opinion be likely to become, the subject of a claim of infringement of any intellectual property right. For inquiries please contact: Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California 94303 (LFI# 114197/Form ID# 011801)
zlib.h
interface of the 'zlib' general purpose compression library, version 1.2.3, July 18th, 2005 Copyright (C) 1995-2005 Jean-loup Gailly and Mark Adler This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. Jean-loup Gailly jloup@gzip.org Mark Adler madler@alumni.caltech.edu
Notes
*439159* *439159* *439159* *439159*

*439159*
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index
A
accounts (database users) dbtree 102 inventory 102 user_view 101 ACL base DN option 134 Active Directory base DN 127, 132 bind DN 127 Computer Configuration Group Policy 59 configuring for machines not in the same domain 121 firewall exceptions 58 installation and setup 134 prerequisites 120 using with UNIX machines 122 Active Directory Application Mode. See ADAM. ADAM base DN 127 bind DN 127 prerequisites 122 adding a new module channel 87 adding custom objects 264 adding patch source channels 287 administrator role 218 AIX machines installing product 79 UNIX X11 libraries 63 AIX Patch Source installing 288, 290 -anonymize 330 Application Packager, compatibility with Deployment Manager 305 archiving channels 229
C
CAR files, creating 177 Centralized collections mode option 134 Certificate Manager, installing SSL certificate with 283 certificate, SSL 282 channel archive files. See CAR files. Channel Copier accessing 297 creating CAR files 177 -channelFilename command-line option 92 channels adding a new module 87, 92 archiving 229 queries for verifying upgrades 315 updating from an earlier release 230 -channels command-line option 92 checklists for installation console and master transmitter 68 Patch Management 279 checklists for upgrading CMS console 253 Deployment Manager 306 Infrastructure Administration 256 Inventory plug-in 268 Logging plug-in 268 master transmitter 236 mirrors 241 Patch Management 294, 295 Policy Management 274 proxies 248 repeaters 244 Report Center 268 Schema Manager 256 transmitter preparation 234 CMS channel, upgrading 253 CMS console checklist for upgrade 253 Deployment Manager and 309 installation worksheets 68 installing on Red Hat Enterprise Linux 78 installing on Solaris 78 installing on Windows 75 keeping original configuration settings 253 listener port 61
B
back up requirements for an upgrade console configuration settings 253 databases 219 tuner workspaces 219 workspaces 218 Base DN option 132 BMC CM console. See CMS console. BMC Software, contacting 2 business objectives, examples 26
Index
385
logging in 87 upgrading 253 upgrading the console tuner 251 user roles for 218 Windows XP and 61 CMS tuner, troubleshooting a failed deployment 188 Collections base DN option 133 Collections folder 270 collections, generating and running and LDIF script for 135 command line scripts installing database 100, 114 upgrading database schema 334 compatibility, Deployment Manager issues 305 configuring FDCC Reporting module 150 Logging plug-in 272 patch repository 141, 289 Patch Service 145 Patch Service plug-in 291 Red Hat Enterprise Linux Patch Source channel 143 Red Hat Enterprise Linux satellite server 292 Security Policy Manager 153 Windows Patch Source channel 142 console server description 20 installation worksheet 68 load on 30 requirements 28 console. See CMS console. Content Replicator autoinstallation of 180 automatic installation by Patch Management 294 compatibility with Deployment Manager 305 upgrading 308 Content Replicator Service 315 copying channels, staging transmitter 86 Core database schema, upgrading 261 create_database.sql file for SQL Server database 341 creating database tables 102 creating installers 176 Custom install option 108, 116 custom keywords, defined 199 custom objects, adding 264 Custom option to install Inventory database 105 custom tables, preparing for upgrade 221 customer support 3 customizing reboot and snooze options 292 insertion rate 44 load on 31 Patch Management and 55 platforms 54 port numbers 103, 115 preparing to install 334 restoration 221 scripts, downloading 334 setting parameters (Oracle) 324 database configuration Oracle database 336 SQL Server 338 database schema backing up 219 installing 105 manually installing 333 manually reinstalling 333 preparing for upgrade 221 scripts for manual updates 341 upgrading 256 upgrading from command-line 334 database table, controlling size 45 dbtree schema data file for Inventory database 107 dbtree_data tablespace (Oracle) 107 dbtree_index tablespace (Oracle) 107 dbtree_role database role 102 dbtreedatagroup filegroup (SQL Server) 107 dbtreeindexgroup filegroup (SQL Server) 107 index file for Inventory database 107 debugging commands 317 turning off 320 turning on 319 using log messages 320 when to use 317 define_variable_values.sql script file (Oracle) 336, 337, 341 deleting installer deployments 185 tuners 192 deploying products using a Ghost image 329 deployment examples basic proxy strategy 40, 41 mirror at customer site 42 reverse proxy outside of a firewall 41 round-robin redirection strategy 39 deployment installer 185 Deployment Manager backing up root directory for 218 checklist for upgrading 306 Command Line channel 308 compatibility issues 305 listener port 61 manually upgrading endpoints 316 port number 160 ports 60 status port 61
D
database centralized logging messages and 55 creating tables 102 determining environment requirements 34 disk space requirements 54
386
upgrading 306 verifying upgrade 310 Deployment Manager endpoints, creating profile 175 Deployment Service 315 determining platforms and hardware for environment 33 directory service configuration 130 connecting and configuring 126 installing the schema 130 LDAP schema 258 load on 30 requirements for 28 schema options 132 UPN format for the bind DN 128 disk space requirements database 54 database upgrade 222 Patch Management upgrade 226 distribution server for testing, determining requirements 33 downloading files product installation files 71 schema installation scripts 334 schema update scripts 346 failed tuner installation 190 out-of-resource 64 Evaluation profile type 166
F
FDCC Reporting module configuring 150 described 150 file sharing, enabling 58 firewalls exceptions 58 ports 32, 60 flags, debugging 319 fully qualified distinguished names (FQDN), using for policy groups 204
G
generating script inserts 203 getdbmetadata procedure, invalid status after installation 105, 108 Ghost image, using to deploy products 329 group upgrading mirrors as 241 upgrading repeaters as 244 group accounts 110
E
Easy install option for Inventory database 102 editing Reboot window options 292 Snooze window options 292 enabling the Logging plug-in 272 endpoints creating a Deployment Manager profile 175 creating Patch Information channel on during installation 293 database configuration example 34 deploying Patch Service to during installation 293 described 21 determining requirements 33 manually upgrading 316 upgrading 312 using Ghost image and 330 -Xms and -Xmx JVM argument 167 environment requirements analyzing business goals 25 database system 34 distribution server for testing 33 endpoints 33 mirrors 33 packaging machine 33, 34 proxies 33 repeaters 33 error messages configuring Oracle database 337 during database configuration 104, 108, 116
H
hardware requirements 33 help, online 212 Hidden entries option 133 history.log files 318 HPjconfig 65 HP-UX machines configuring kernels 64 installing the product 79 UNIX X11 libraries 64 HP-UX Patch Source channel installing 288, 290
I
icons, reboot and snooze 292 image (Ghost), using to deploy products 329 INFRASERVICE/CHANNEL debugging flag 319 Infrastructure Administration checklist for upgrade 256 upgrading 256 infrastructure of product described 22 determining platforms and hardware for environment 33
Index
387
Infrastructure Service troubleshooting 317 upgrading on endpoints 314 Infrastructure Status Monitor default admin password 115 default user password 115 installing database schema 114 profile to monitor 172 init.ora file, changing the sessions parameter value 257 Install collections option 135, 136 installer deployments adding a debug flag to the CMS tuner 188 creating 182 credentials for starting a deployment 185 described 165 determining if you have a successful deployment 187 monitoring a running deployment 186 overview 164 paths on target machines 182 starting, stopping, deleting 185 stopping a deployment 186 timeout periods 182 troubleshooting 188 installers creating 176 directory locations 176 platform dependencies 177 platform-specific templates 176 stub installer 178 installing AIX Patch Source 288 database schema, Custom option 105 database schema, manual process 333 HP-UX Patch Source 288 Patch Management 278 Patch Manager channels 286 Patch Service channel 287 Patch Source channels 290 patch sources 141 Red Hat Enterprise Linux Patch Source 287 Solaris Patch Source 287 SSL certificate for Satellite server 282 Windows Patch Source 287 inv_data tablespace (Oracle) 106 inv_index tablespace (Oracle) 106 inv_view database role 101 invdatagroup filegroup (SQL Server) 106 Inventory database connecting to 103 RAID disk setup 325 Inventory database and schema data and index files 106 database roles and users 101 index file 106 installation guidelines 100, 114 installing using Custom option 105 installing using Manual option 333 inv_view role 101 inventory data file 106 log file 106 overview of installation process 98 preparing to upgrade 215 reinstalling using Manual option 333 inventory plug-in configuring 109 described 98 enabling 268 load on 31 invindexgroup filegroup (SQL Server) 106
J
Java ports 60 Run-time Environment, upgrading 66 unblocking java.exe 59 JIT compiler 65 JRE. See Java. Just-In-Time. See JIT compiler. JVM arguments transmitters 171
K
kernels, HP-UX 64
L
LDAP See also directory services. query collections base DN option 133 schema 258 LDIF scripts generating 130 running 131 using to create collections containers 135 Linux. See Red Hat Enterprise Linux. local customizations 218 log collection 43 log entry volume 44 log files about database disk space 55 log messages for debugging 320 log_data tablespace (Oracle) 106 log_index tablespace (Oracle) 106 logging data file for inventory database 106 logging in to CMS console 87 logging index file for inventory database 106 logging plug-in configuring 109 described 98 enabling 268 upgrading components 268
388
Logging Service 98, 314 loggingdatagroup filegroup (SQL Server) 106 loggingindexgroup filegroup (SQL Server) 106 upgrading endpoints 312 using instead of mirrors 28 using instead of proxies 29
M
Machine import base DN option 133 Managed Node profile type 165 Manual install Schema Manager option 333 Manual reinstall Schema Manager option 333 manually updating database schema considerations for using 333 downloading a single script 342 downloading update scripts 346 update considerations for installation scripts 341 manually upgrading endpoints 316 map.txt file 294 marimba.logs.enabled tuner property 176 marimba.logs.max.queue tuner property 176 marimba.tuner.logs.applyFilters tuner property 171, 174 marimba.tuner.logs.centralizedlogging tuner property 171, 174 master distribution server, described 20 master transmitter checklist for upgrading 236 installation worksheets 68 installing on Red Hat Enterprise Linux 76 installing on Solaris 76 installing on Windows 73 upgrading 235 verifying settings 85 Master Transmitter profile type 165 master/mirror farm, required number 27, 28 mastlog table 45 memory requirements for tuner updates 311 MESH. See multi-endpoint synchronized host. Microsoft Active Directory Application Mode. See ADAM. Microsoft Active Directory. See Active Directory. minituner.exe, unblocking java.exe 59 Mirror Transmitter profile type 166 mirror transmitter, creating a profile for 170 mirrors advantages for using 37 at customer site, deployment strategy 42 checklist for upgrading 241 description 20 determining requirements 33 disadvantages for using 37 upgrading 240 modifications to database schema, unsupported changes to scripts 342 multi-endpoint synchronized host advantages and disadvantages 38 basic strategy for tuners 41 benefits on endpoints 28 enabling in a profile 168
N
Note for Active Directory option 132
O
online help 212 operator role 218 Oracle database changing passwords for database users 336 configuration following manual installation of schema 336 dbtree_data tablespace 107 dbtree_index tablespace 107 define_variable_values.sql script file 336, 337 errors during database configuration 337 inv_data tablespace 106 inv_index tablespace 106 log_data tablespace 106 log_index tablespace 106 monitoring the update status 354 RAID disks 326 setting parameters 324 supported modifications to upgrade scripts 341 tuning 324 OS provisioning tool definition of 198 types of 198 osql.exe file for SQL Server database 338 out-of-resource errors 64
P
packaging machine, determining requirements 33, 34 parameters, setting for Oracle databases 324 passwords changing for database users (Oracle) 336 changing for database users (SQL Server) 339 changing for database users with Schema Manager 108, 116 DBA system administrator 115 Infrastructure Status Monitor 115 loading and applying profiles 170 Patch Information channel verifying creation during installation 293 verifying creation during upgrade 290 Patch Management checklist for installing 279 checklist for upgrading 294, 295 database disk space for 55 disk space requirements for 141
Index
389
installing channel 286 outline of installation process 139 overview of installing 278 overview of upgrading 279, 280 preparing for upgrade 226 system requirements of machines 284 upgrading 294 verifying Patch Information channel 290 Patch Manager 139 patch repository configuring 141, 289 initial creation time for Solaris 285 rebuilding 299 updating time during publishing 285 Patch Service configuring 145 configuring plug-in 291 deploying to endpoints during installation 293 described 140 installing 287 interacting with Scanner Service during installation 293 setting timeouts in 292 update schedule for 292 updating the endpoints to 301 upgrading 300 verifying the upgrade 302 Patch Service plug-in, described 140 Patch Source channels described 140 installing 141 peer-to-peer. See multi-endpoint synchronized host. Perform Action button 136 permissions, subscribe and publish for profiles 170 plug-ins configuring for Patch Service 291 enabling Logging 272 policy groups described 199 using fully qualified distinguished names (FQDN) 204 using relative distinguished names (RDN) 204 Policy Management checklist for upgrading 274 overview of installation process 118 overview of upgrade process 273 prerequisites 119 upgrading 273 Policy Manager and policy management-related components 118 port for 61 upgrading 274 upgrading mirrors with 241 upgrading repeaters with 244 verifying upgrade 275 Policy Service 314 Policy Service plug-in, load on 29 ports administration 60 BMC CM server host 61 CMS console listener 61 databases 103, 115 Deployment Manager 160 Deployment Manager listener 61 Deployment Manager status 61 Java 60 open 32 proxy listener 61 transmitter listener 61 tuner network detection 58 prefs.txt file 319 prerequisites Active Directory 120 ADAM 122 channel archive 229 machines hosting Patch Management 284 Patch Management 226 proxy 234 Red Hat Enterprise Linux 281 Report Center 225 Sun Java System Directory Server 122 test environment 217 transmitter 234 tuners 311 workspaces 218 -preview command-line option 317 primary administrator role 218 -print command-line option 318 printers, enabling sharing 58 product support 3 profile types 165 profiles creating and editing 165 creating for a Deployment Manager endpoint 175 creating for a proxy 173 loading 170 supplying credentials for loading and applying 170 use in deployment 164 proxies advantages for using 38, 39 backing up workspaces 218 checklist for upgrading 248 creating a proxy profile 173 description 21 determining requirements 33 disadvantages for using 38, 39 listener port 61 required number 29 strategy for deployment 40, 41 upgrading 247 Windows XP and 61 Proxy profile type 166 publish credentials for applying profiles 170
390
Q
Queries folder 270 queries for verifying channel upgrades 315 Query Library installing 105 verifying the upgrade 270 queue size, controlling on transmitter 45
reverse proxy strategy for deployment 41 roles, database dbtree_role 102 inv_view 101 inventory 102 roles, user 218 round-robin redirection strategy for deployment 39 runchannel 159
R
RAID disks for Inventory 325 recommendations for Oracle database 326 RAM required for tuner updates 311 RDN, using for policy groups 204 Reboot window 292 Red Hat Enterprise Linux machines installing product 76 installing Satellite 281 installing SSL certificate 282 UNIX X11 libraries 66 Red Hat Enterprise Linux Patch Source channel configuring 143 installing 287, 290 prerequisites 281 setting satellite server configuration 292 Refresh button, usage 186 reinstalling schema, manual process 333 relative distinguished names (RDN) for policy groups 204 remote deployment 93 Repeater Transmitter profile type 166 repeater transmitter, creating a profile 170 repeaters advantages for using 36 checklist for upgrading 244 description 20 determining requirements 33 disadvantage of using 36 requirements 28 upgrading 243 replication common capabilities 36 description 35 Report Center checklist for upgrading 268 database types and 54 Deployment Manager and 309 described 98 overview of upgrade process 267 port for 61 preparing for upgrade 225 queries for verifying channel upgrades 315 upgrading 268 Report Center and inventory-related components 98 Require entries in the directory service option 133 requirements for environment 33
S
Satellite server installing SSL certificate for 282 prerequisites 281 setting configuration for Red Hat Enterprise Linux 292 saving settings original settings during console update 253 Report Center configuration 225 Scanner Service interacting with Patch Service during installation 293 upgrading 314 schedule, update Patch Service 292 Schema base SN options 132 schema installation directory services 130 Infrastructure Status Monitor schema 114 manual option 333 Software Usage schema 105 Schema Manager changing passwords with 108, 116 checklist for upgrade 256 upgrading 256 schema update determining update option 333 downloading a single script for manual update 342 downloading scripts for manual update 346 monitoring schema update progress 354 preparing for the upgrade 221 script inserts definition of 200 generating 203 using on different platforms 205 scripts downloading schema installation scripts 334 generating LDIF scripts 130 running LDIF scripts 131 using to create collections containers 135 Security Policy Manager configuring 153 described 150 sessions parameter in init.ora 257 Set Root Directory link 162 set_datafile_values.sql file for SQL Server database 341 set_indexfile_values.sql file for SQL Server database 341 sharing, enabling for printers and files 58
Index
391
simulation and Red Hat Enterprise Linux 281 single-script option to download schema update script 342 Snooze window 292 software requirements 33 Software Usage folder 270 software usage, installing database schema for 105 Solaris machines installing product 76 UNIX X11 libraries 66 Solaris Patch Source channel installing 287, 290 repository creation time 285 upgrading 296 Source users from a transmitter option 133 SQL Server database changing passwords for database users 339 configuration 55, 338 create_database.sql file for updates 341 dbtreedatagroup filegroup 107 dbtreeindexgroup filegroup 107 invdatagroup filegroup 106 invindexgroup filegroup 106 loggingdatagroup filegroup 106 loggingindexgroup filegroup 106 memory allocation 56 memory allocation requirement 56 osql.exe file 338 set_datafile_values.sql file for updates 341 set_indexfile_values.sql file for updates 341 supported script modifications for schema updates 341 SSL certificate for satellite server configuring 292 creating certificate 281 installing certificate 282 SSL connections for repeaters and mirrors 43 staging transmitter, copying channels 86 standard administrator role 218 starting installer deployments 185 stopping installer deployments 185 stub installer 178 subscribe credentials for loading profiles 170 Subscription base DN option 133 Subscription config base DN option 133 Subscription. See Policy Management, Policy Manager, Policy Service. summary of upgrade process 216 Sun Java System Directory Server base DN 127, 132 bind DN 128 prerequisites 122 Virtual List View (VLV) 136 support, customer 3 system administrator credentials 104, 115 system architecture description 23 diagram 22 system requirements for updating tuners 311
T
tables, creating database 102 tables, custom preparing for upgrade 221 technical support 3 test environment 217 timeout periods for installer deployments 182 timeouts, setting in Patch Service 292 Transmitter Administrator, creating CAR files 177 Transmitter Verifier 7.1.1c 234 transmitters backing up workspaces 218 checklist for preparation 234 copying channels from staging transmitter 86 listener port 61 order of upgrades 234 preparing for upgrade 220 troubleshooting out-of-resource errors 64 -Xms and -Xmx JVM argument 171, 174, 175 transmitters, master See also master transmitters. checklist for upgrading 236 described 20 upgrading 235 transmitters, mirror checklist for upgrading 241 upgrading 240 transmitters, proxy checklist for upgrading 248 upgrading 247 transmitters, repeater checklist for upgrading 244 upgrading 243 troubleshooting domain name and network setup 281 finding Patch Information channel 290 Infrastructure Service 317 manually upgrading endpoints 316 out-of-resource errors 64 running Update tuner action 283 shortening database schema upgrade time 261 tuners 66 turning off debugging 320 turning on debugging 319 updating console version number 269 updating tuner version number 237 using history.log files 318 using Update tuner or Tuner Administrator 237 when to use debugging 317 Tuner Administrator settings, adding a debug flag 189 tuners administration port 60, 61 backing up workspaces 219
392
deploying installers to remote machines 58 described 21 installation problems 190 JIT compiler and 65 network detection port 58 removing from Solaris and UNIX 194 removing from UNIX machines 193 removing from Windows machines 193 system requirements for updating 311 troubleshooting 66, 190 unblocking minituner.exe 59 uninstalling 192 -txRepPassword command-line option 92 -txRepUserName command-line option 92 TxVerify 7.1.0 234 Logging Service 314 Patch Management 279, 280, 294 Patch Service 300 Policy Manager 274 Policy Service 314 Report Center 268 Scanner Service 314 Schema Manager 256 Solaris Patch Source 296 transmitter channel 238 Windows Patch Source 296 Windows Vista 313 uploading a text file 85 UPN (user principal name) format 128 URLs for starting Deployment Manager GUI 160 user accounts 110, 218 user names for loading and applying profiles 170 user principal name (UPN) format 128 user roles 218 user_view default password 101 users, database changing passwords (Oracle) 336 changing passwords (SQL Server) 339 changing passwords using Schema Manager 108, 116
U
uninstalling tuners 192 UNIX machines removing tuners 193 using with Active Directory 122 UNIX X11 libraries AIX requirements 63 HP-UX requirements 64 Linux requirements 65, 66 Solaris requirements 66 unsupported database modifications 342 Up2Date agent 281 update schedule for Patch Service 292 Update tuner action, troubleshooting 283 updating database schema determining which option to use 333 directory services LDAP schema 258 from command-line 334 using multiple scripts 346 using single script 342 upgrade process manually upgrading endpoints 316 queries for verifying upgrades 315 summary 216 transmitter order 234 upgrading channels 230 CMS console 253 CMS console tuner 251 Content Replicator 308 Content Replicator Service 315 Deployment Manager 306 Deployment Manager Command Line channel 308 Deployment Service 315 endpoints 312 endpoints to Patch Service 301 Infrastructure Administration 256 Infrastructure Service 314 logging plug-ins 268
V
verifying master transmitter settings 85 Virtual List View (VLV) for Sun Java System Directory Server 136
W
Windows machines installing the console and master transmitter 73 removing tuners 193 Windows Patch Source channel configuring 142 installing 287, 290 upgrading 296 Windows Vista 313 Windows XP CMS console and 61 firewalls and 58, 60 workspaces, backing up 218
X
-Xint Java launch argument 176 -Xms and -Xmx JVM argument endpoints 167 transmitters 171, 174, 175 XP. See Windows XP.
Index
393
394

BBCA - Installation Guide

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

BBCA - Installation Guide

Încărcat de

Drepturi de autor:

Formate disponibile

BMC BladeLogic Client Automation Installation 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

BMC BladeLogic Client Automation Installation Guide

About the product architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Installation terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Overview of installation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Chapter 5 Before you install 53

BMC BladeLogic Client Automation Installation Guide

Overview of Patch Management components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

BMC BladeLogic Client Automation Installation Guide

Verifying that BMC BladeLogic Client Automation is set up correctly 211

Using Report Center to run a report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Using Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Whats next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Chapter 16 Preparing for the upgrade 215

BMC BladeLogic Client Automation Installation Guide

262 264 264 264 265 266 267

Disk space requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

BMC BladeLogic Client Automation Installation Guide

BMC BladeLogic Client Automation Installation Guide

BMC BladeLogic Client Automation Installation Guide

Planning your installation

Part 1 Planning your installation

BMC BladeLogic Client Automation Installation Guide

BMC BladeLogic Client Automation infrastructure

BMC BladeLogic Client Automation components

BMC BladeLogic Client Automation infrastructure

Master distribution server (transmitter)

BMC BladeLogic Client Automation Installation Guide

How the components fit together

BMC BladeLogic Client Automation infrastructure

How the components fit together

Recommended system architecture for standard environments

Load Balancer 4 6 4 Mirror (off-site)

BMC BladeLogic Client Automation Installation Guide

How the components fit together

4 At scheduled times, channels are replicated to the repeaters at branch offices.

BMC BladeLogic Client Automation infrastructure

How the components fit together

5 The endpoints download new channels and update current channels:

9 Report Center runs scheduled queries to create collections in a directory service.

BMC BladeLogic Client Automation Installation Guide

Designing your BMC BladeLogic Client Automation environment

Determining the requirements for the infrastructure setup

Identifying business objectives

Designing your BMC BladeLogic Client Automation environment

Adding infrastructure components to your architectural diagram

Adding infrastructure components to your architectural diagram

Machine count and location requirements

BMC BladeLogic Client Automation Installation Guide

Adding infrastructure components to your architectural diagram

Database 256 Kbps

2000 desktops and laptops

100 server endpoints

40 desktops and laptops

T1 line 256 kbps

Replicated directory services

500 desktops and laptops

Replicated directory services

700 desktops and laptops

90 desktops and laptops

Requirements for the master/mirror farm

Designing your BMC BladeLogic Client Automation environment