BMC BladeLogic Client
Automation Installation Guide
Supporting
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 2005–2012 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
Customer support
You can obtain technical support by using the BMC Software Customer Support website or by contacting Customer Support by telephone or e-mail. To expedite your inquiry, see “Before contacting BMC.”
Support website
You can obtain technical support from BMC 24 hours a day, 7 days a week at http://www.bmc.com/support. From this website, you can
■ read overviews about support services and programs that BMC offers ■ find the most current information about BMC products
■ search a database for issues similar to yours and possible solutions ■ order or download product documentation
■ download products and maintenance ■ report an issue or ask a question
■ subscribe to receive proactive e-mail alerts when new product notices are released
■ find worldwide BMC support center locations and contact information, including e-mail addresses, fax numbers, and telephone numbers
Support by telephone or e-mail
In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or send an e-mail message to [email protected]. (In the subject line, enter SupID:<yourSupportContractID>, such as SupID:12345). Outside the United States and Canada, contact your local support center for assistance.
Before contacting BMC
Have the following information available so that Customer Support can begin working on your issue immediately: ■ product information
— product name
— product version (release number)
— license number and password (trial or permanent) ■ operating system and environment information
— machine type
— operating system type, version, and service pack or other maintenance level such as PUT or PTF — system hardware configuration
— serial numbers
— related software (database, application, and communication) including type, version, and service pack or maintenance level
■ sequence of events leading to the issue ■ commands and options that you used
■ messages received (and the time and date that you received them) — product error messages
Contents
Part 1
Planning your installation
17
Chapter 1 BMC BladeLogic Client Automation infrastructure 19
BMC BladeLogic Client Automation components . . . 19
Console server . . . 20
Master distribution server (transmitter). . . 20
Mirrors. . . 20
Repeaters. . . 20
Proxies . . . 21
Endpoints . . . . 21
How the components fit together . . . 21
Chapter 2 Designing your BMC BladeLogic Client Automation environment 25 Determining the requirements for the infrastructure setup . . . 25
Identifying business objectives . . . 25
Adding infrastructure components to your architectural diagram . . . 26
Determining the infrastructure platforms and hardware . . . 33
Chapter 3 Performance considerations 35 Deciding whether to use repeaters, mirrors, or proxies . . . 35
Common capabilities of replication mechanisms . . . 36
Repeater strategy . . . 36
Mirror strategy . . . 37
Proxy strategy . . . 37
MESH-enabled tuner strategy . . . 38
Deployment scenarios. . . 39
Determining if your system can support the logging feature . . . 43
Issue 1: Determining the database insertion rate . . . 44
Issue 2: Determining the volume of log entries generated . . . 44
Issue 3: Controlling the queue size on the transmitter. . . 45
Issue 4: Controlling the size of the database table . . . 45
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
Part 3
Postinstallation activities
95
Chapter 7 Setting up Inventory Management 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 Overview of Policy Management components . . . 118
Policy Manager . . . 118
Directory service schema . . . 118
Policy Service . . . 118
Policy Service plug-in . . . 118
Integration with a database . . . 119
Overview of the Policy Management installation process. . . 119
Prerequisites for installing Policy Management . . . 119
Preparing the directory service . . . 120
Prerequisites for Active Directory. . . 120
Prerequisites for Sun Java System Directory Server. . . 122
Prerequisites for ADAM / AD LDS . . . 122
Connecting to the directory service. . . 126
Installing the directory service schema. . . 130
Directory service schema options . . . 132
Setting up Active Directory . . . 134
Setting up Sun Java System Directory Server . . . 136
Configuring Policy Manager and the Policy Service plug-in . . . 137
What’s next? . . . 137
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
Creating installer deployments . . . 182
Disabling UAC . . . 182
Installer installation path on targets . . . 182
Installer deployment timeout period . . . 182
Running and monitoring installer deployments . . . 185
Credentials for starting a deployment . . . 185
Monitoring a running deployment . . . 186
Stopping a deployment. . . 186
Determining if you have a successful deployment . . . 187
Troubleshooting failed deployments . . . 188
Failed deployment details . . . 188
Ports used by remote deployer . . . 190
Limitation of remote deployment on Microsoft Windows Server 2008 . . . 190
Remote deployment on UNIX . . . 190
Stub installer failures . . . 191
Understanding mrbapsexec errors for Windows . . . 191
Uninstalling tuners . . . 192
Part 4
Upgrade
195
Chapter 14 Integrating tuner installation with OS provisioning 197 Overview of the tuner integration with OS provisioning . . . 198Tuner installers . . . 198
OS provisioning tools . . . 198
Policy group model . . . 199
Custom keywords . . . 199
Script inserts . . . 200
Identifying the OS provisioning method to use . . . 200
Image-based method. . . 200
Scripted installation method . . . 200
Overview steps for provisioning . . . 201
Prerequisites for provisioning machines . . . 201
Installed and configured the BMC BladeLogic Client Automation system . . . . 201
Created profiles and installers. . . 202
Generating the script insert for provisioning machines. . . 203
Using the script insert . . . 205
HP Ignite-UX . . . 206
IBM Network Install Manager (NIM). . . 206
Red Hat Linux Kickstart . . . 207
Solaris Jumpstart . . . 207
Unattended Windows 2000/XP/2003 . . . 208
Integrating with Policy Management . . . 208
Reboot behavior . . . 209
Chapter 15 Verifying that BMC BladeLogic Client Automation is set up correctly 211 Using Report Center to run a report . . . 211
What’s 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
What’s 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
What’s 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 Custom update option to update the Inventory database schema
modules and query libraries . . . 262
Adding custom objects . . . 264
Updating the Infrastructure Status Monitor schema . . . 264
Using the Easy update option to update the Infrastructure Status Monitor database schema . . . 264
Using the Custom update option to update the Infrastructure Status Monitor database schema . . . 265
What’s next? . . . 266
Chapter 19 Upgrading Report Center 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 Overview of installing or upgrading Patch Management . . . 278
If you are installing Patch Management for the first time. . . 278
If you are upgrading Patch Management . . . 279
Before you install or update Patch Management . . . 280
Prerequisites for the Red Hat Enterprise Linux Patch Source channel . . . 281
Recommendations for machine roles . . . 284
Patch repository update times . . . 285
Installing Patch Management. . . 286
Installing the Patch Management channels . . . 286
Configuring the patch repository and installing the Patch Sources . . . 289
Configuring the Patch Service plug-in . . . 291
Deploying the Patch Service channel to endpoints . . . 293
Upgrading Patch Management . . . 294
Upgrading the Patch Source channels . . . 296
Rebuilding the patch repository . . . 299
Upgrading Patch Service . . . 300
Updating the endpoints to Patch Service 8.2.02 . . . 301
Verifying that the upgrade is in place . . . 302
Verifying the success of the upgrade . . . 302
What’s next? . . . 303
Chapter 22 Upgrading Deployment Manager 305 Compatibility with Application Packager and Content Replicator . . . 305
Upgrading Deployment Manager . . . 306
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
321
Appendix A Database tuning 323 SQL Server database tuning . . . 323Oracle 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
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
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
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
1
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
C h a p t e r
1
1BMC BladeLogic Client Automation
infrastructure
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 . . . 19
Console server . . . 20
Master distribution server (transmitter). . . 20
Mirrors. . . 20
Repeaters. . . 20
Proxies . . . 21
Endpoints . . . . 21
How the components fit together . . . 21
BMC BladeLogic Client Automation
components
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
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 tuner’s 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.
How the components fit together
Figure 1 Recommended system architecture for standard environments
Console Server Directory Service Master Mirror Load Balancer Test/QA Transmitter
Lima Hamburg San Jose Chicago Denver Atlanta
Mirror (off-site)
ProxyProxyRepeater Repeater Repeater Repeater
How the components fit together
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:■ 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.
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.
NOTE
How the components fit together
5
The endpoints download new channels and update current channels:■ 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 theplug-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:■ 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.NOTE
C h a p t e r
2
2Designing your BMC BladeLogic
Client Automation environment
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 . . . 25
Identifying business objectives . . . 25
Adding infrastructure components to your architectural diagram . . . 26
Determining the infrastructure platforms and hardware . . . 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
Adding infrastructure components to your architectural diagram
Your business objectives can include one or more of the following objectives: ■ 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.
Adding infrastructure components to your architectural
diagram
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
Adding infrastructure components to your architectural diagram
Therefore, create a system diagram similar to the one in Figure 1 that shows the following information:
■ 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.
Figure 1 Network diagram example
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)
Branch office B
Adding infrastructure components to your architectural diagram
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 re-implementation) 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.
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.
Adding infrastructure components to your architectural diagram
Requirements for proxies
Consider using a proxy at remote locations under one of the following conditions: ■ 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.
■ 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:
■ How often do updates and new distributions need to be sent to endpoints—daily? 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.
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
Adding infrastructure components to your architectural diagram
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.
■ 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:
■ 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.
Adding infrastructure components to your architectural diagram
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:
■ 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 database’s 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.
Load on the database
To determine if you need to have a database dedicated to your infrastructure, make the following calculations:
■ 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.
NOTE
Adding infrastructure components to your architectural diagram
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:
■ 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.
Determining the infrastructure platforms and hardware
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 Hardware and software requirements (part 1 of 2)
Component
Number of
machines Description
Master/mirror farm Make a list of the machines that you want to use for the master and mirrors.
Test and QA distribution server
Make a list of the machine or machines that you want to use for hosting channels during testing and QA.
Repeaters Make a list of the machines that you want to use for repeaters.
Proxies If you plan to use proxies, make a list of machines that will host proxies. Console server Does the machine that you want to use for hosting the CMS console
satisfy the system requirements?
Endpoints 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.
Determining the infrastructure platforms and hardware
Packaging machine for creating content packages (for Deployment Manager)
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. 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:
■ 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.
Table 1 Hardware and software requirements (part 2 of 2)
Component
Number of
C h a p t e r
3
3Performance 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 . . . 35
Common capabilities of replication mechanisms . . . 36
Repeater strategy . . . 36
Mirror strategy . . . 37
Proxy strategy . . . 37
MESH-enabled tuner strategy . . . 38
Deployment scenarios. . . 39
Determining if your system can support the logging feature . . . 43
Issue 1: Determining the database insertion rate . . . 44
Issue 2: Determining the volume of log entries generated . . . 44
Issue 3: Controlling the queue size on the transmitter. . . 45
Issue 4: Controlling the size of the database table . . . 45
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.
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.
■ 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 location—the 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 Advantages and disadvantages to using repeaters
Advantages Disadvantages
■ 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 entire redirection process is completely transparent to endpoints. That is, if you add or remove repeaters, you do not need to change any settings on the endpoints.
Mirror strategy
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.
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.
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.
Table 2 Advantages and disadvantages to using mirrors
Advantages Disadvantages
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.
MESH-enabled tuner strategy
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.
Table 3 Advantages and disadvantages to using proxies
Advantages Disadvantages
■ 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.
Deployment scenarios
Deployment scenarios
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.
Table 4 Advantages and disadvantages to using MESH-enabled tuners
Advantages Disadvantages
■ 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.
Deployment scenarios
Figure 1 Round robin redirection strategy
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 Repeater (or Mirror + Redirector) Repeater (or Mirror + Redirector) Endpoints (Tuners) Repeater (or Mirror + Redirector)
One or More Proxies (in Tokyo)
Deployment scenarios
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
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.
Remote office 1
Transmitter (home office)
Remote office 2
Deployment scenarios
Figure 4 Reverse proxy outside a firewall
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. One or More Reverse Proxies
Determining if your system can support the logging feature
Figure 5 Mirror at one of your customer sites
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.
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
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.
Master in London Tokyo Repeater (or Mirror + Redirector) Tokyo mirror
Tokyo Endpoints (Tuners)
Issue 1: Determining the database insertion rate
are sent to the Logging plug-in simultaneously, then some files are placed in the transmitter’s 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 dual-processors, 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:
■ 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.
■ 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.
WARNING
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:
■ 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
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
2
Part
Part 2
Installation
This part presents the following chapters: Chapter 4
Installation overview . . . 49
Chapter 5
Before you install . . . 53
Chapter 6
C h a p t e r
4
4Installation 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:
■ 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.
Installation terminology
Installation terminology
This section describes terminology used in the BMC BladeLogic Client Automation installation process.
■ Download. Downloading the installation program from the BMC Electronic Product Distribution (EPD) website to your machine.
■ 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.
■ 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.
