Deploy BMC Patrol and Patrol Agents

Version 3


    The purpose of this document is to describe how to deploy Patrol Agents using BladeLogic.


    BladeLogic includes the facility to deploy software installations to remote systems. There are various ways to handle this (via installable software, via customer software etc) and we have chosen to use BLPackages. This choice was made due to the flexibility that is available over and above any other deployment method.

    Another factor influencing this decision was that not every server would have patrol installed, it could be a Windows or a UNIX system, and the install directory could potentially be different on each machine, at the local administrators' discretion.

    Before You Begin

    This document requires a complete understanding of BLPackages, Server Properties, Component Templates and Jobs. All of these are described in detail in the BladeLogic user Guide.

    Preparing the Agents for Deployment

    The rest of this document will focus on the specific strategies for deploying Patrol agents. It should be noted that the technique is the same for Windows and UNIX, so only Windows will be described here. To see any specific differences, please consult the actual BLPackages on the production servers.

    Setting the Server Property


    Most system objects in BladeLogic have properties associated with them. These properties define a wide range of characteristics. Typically you manage properties using a master list called the Property Dictionary

    The Property Dictionary organizes properties into classes and sub-classes. Each sub-class inherits all properties defined for its parent class. Each parent class inherits the properties defined for the root system object in the Property Dictionary.

    Most built-in classes or sub-classes in the Property Dictionary correspond to a type of system object in BladeLogic. For example, the Server built-in class corresponds to servers in Configuration Manager or Provisioning Manager. The Deploy Job sub-class (whose parent is the Job class) corresponds to Deploy Jobs in Configuration Manager. Every system object in BladeLogic automatically inherits all the properties assigned to its corresponding class or sub-class in the Property Dictionary. For example, if you add a property to the Server class, every server in Configuration Manager automatically inherits that property.

    All system objects in BladeLogic inherit the properties assigned to the root system object in the Property Dictionary. These properties assign basic information that is common to all system objects, such as the role that created the object and its date of creation.

    Throughout BladeLogic the most important use for properties is to create parameters, which are references to properties. For example, when you deploy an Apache server to Windows and UNIX platforms, you can specify a different installation directory for each platform by defining a server property that might be called APACHE_INSTALL_DIR. On Windows servers, this property might have a value of /c/Program Files/Apache. On UNIX-style servers the property might have a value of /usr/local/Apache. In the BLPackage that encapsulates the Apache server, you can insert a parameter that refers to APACHE_INSTALL_DIR. When that BLPackage is deployed to a server, BladeLogic obtains the server's value for APACHE_INSTALL_DIR. Using a parameter in this way, you can deploy the same BLPackage to multiple servers running different operating systems.

    In addition to BLPackages, you can use parameters and properties in component templates, configuration files, and extended objects. Resolving a parameter to a property value happens at different times. For example, in a component template, a parameter might get resolved when you discover a component based on that template. For an extended object, a parameter could be used to identify content when you attempt to run a job based on the extended object. In all cases, however, the parameter serves as a reference to a property. The property value is determined when the parameter is processed.
    Another common use for properties is to assign values to objects so those values can be used elsewhere in BladeLogic. For example, a property can indicate an object's development status (for example, DEV, QA, or PROD). Or, a property can indicate that a server is off line.

    Properties are also used to define smart groups, which are groups of objects that are automatically populated based on criteria in the form of property settings. All workspaces except RBAC Manager let you create smart groups. In Configuration Manager you can perform many actions on server and component groups, so a well designed scheme for assigning properties to servers can enhance productivity. For example, you can create a property, such as OWNER, and then assign different values for that property to different servers. If some servers have OWNER set to QA and others have OWNER set to DEV, then smart groups can automatically separate QA servers into one group and development servers into another.

    BLPackages, component templates, and system packages let you assign local properties that only apply to a particular object. Local properties are primarily used to create multiple instances of an object on a single server. For example, you can use local properties to deploy a BLPackage to multiple locations on the same server.


    In order to provide maximum flexibility with regards to Patrol Agent installations, we need to create a Server Property called PATROL_DIR.


    This could then be set manually by local system administrators using the "Set Server Property" dialogue:


    or could be set through the use of NSH scripting. The end result would be a defined installation directory for every server requiring Patrol:



    In addition to the server property, a Server Group was created into which any server requiring a Patrol Agent could be added in order to simplify subsequent operations, as shown on the right.

    Defining the Component Template


    A component is a collection of configuration settings that encapsulates a business or infrastructure service, application, or security policy. Components can simplify many data centre management tasks because a component provides a higher level of abstraction than the servers and server objects that make up the component. For example, a component can group the files, configuration entries, and registry values needed to support an Apache server, WebLogic, or Oracle. A component can also specify a collection of configuration settings that your organization must implement, such as Centre for Internet Security (CIS) recommendations for a particular operating system.

    To create a component, you must first define a component template, which establishes rules and provides necessary information for the component, and then associate the template with a server. A component template consists of the following:

    • Template parts---Server objects that constitute the component. You can parameterize template parts to accommodate variations between servers, departments, and networks.
    • Signature---A set of conditions that must be satisfied on a server for a component template to be associated with that server. A Component Discovery Job compares a signature to the configurations of designated servers. When the Component Discovery Job finds that a server satisfies a component signature, the job associates the component template with the server and thereby creates a component.
    • Allowed operations---Decisions about what operations can be performed using this component, such as browsing, snapshots, audits, and discovery.
    • Compliance rules---A collection of one or more rules that express corporate policy about some or all of the parts included in a component template. For example, compliance rules can specify security requirements or test for an application's required configuration. If a component does not satisfy a compliance rule, you can specify remediation in the form of a BLPackage that can be deployed to correct the component's configuration.
    • Local properties---A set of properties that are assigned to the component template. Using local properties, you can define multiple instances of a component on the same server.

    Typically an expert user defines a component template and then uses the template to discover components on servers. Once an expert user has discovered the component, less sophisticated users can use that component to browse, snapshot, and audit the service, application, or policy that the component represents, even when those users may not have a deep understanding of the complexity underlying the component. Less sophisticated users can also run Compliance Jobs on components to ensure their integrity and remediate problems by deploying BLPackages specified in the component template definition.

    Using components, users with any level of sophistication can:

    • Deploy custom applications as a single unit of information to multiple servers.
    • Determine component-level compliance to policies rather than compliance at the server object level.
    • Make controlled changes to multiple servers by translating changes in a single component to changes on multiple target machines.
    • Perform baseline analyses by comparing the configuration captured in a component to other servers.

    BladeLogic recommends a standard methodology for using components, as detailed in the BladeLogic User Guide. Following these recommendations may help you implement components efficiently and achieve the greatest benefit from them.



    Patrol Agent installations rely on a control file called install.ctl. This file contains, amongst other things, numerous references to the Patrol install directory. For maximum flexibility, this file should be created with all the path entries blank to be constructed as part of the BladeLogic deployment.


    In order to achieve this, we need to be able to parse the control file. One of the risks when approaching a task such as this is that it's easy to describe multiple configuration files at a global level within BladeLogic, however this can lead to challenges with maintenance as the number of applications grows over time. It is usually better practice to simply create a Component for each software deployment which can then be referenced within the BLPackage.


    Within the Component Template, we have the option of adding 'Local Configuration Objects', such as the control file that we're interested in. (See image on the left).
    In our case, the file that we need to work with can be parsed by using the "name=value" grammar ( and is set up as shown below:


    Once this is all configured, it's simply a matter of running a Component Discovery Job against a sample server and a Component is instantiated that can be used within the BLPackage that we're about to create.

    It should be noted that in most cases, a separate Component will be required at least for Windows and UNIX platforms due to the different method of describing file paths. It will often also be necessary to create a separate component for each UNIX variant that will be deployed to.

    Building the BLPackage


    A BLPackage is an aggregation of many types of server objects that are packaged together so they can be deployed unattended on multiple remote hosts. When you create a BLPackage, you store it in the Depot. For a description of how to create BLPackages, please see the BladeLogic User Guide.

    You can create a BLPackage in the following ways:

    • Bundling files and other server objects that you select from a live host.
    • Bundling files and other server objects that you select from the Depot.
    • Bundling files and other server objects that you select from a snapshot.
    • Bundling files and other server objects contained in a component.
    • Bundling the results of an audit to synchronize a target server with a master configuration.


    BLPackages can consist of either Windows or UNIX-style server objects. A BLPackage cannot mix Windows and UNIX-style server objects.
    For Windows, a BLPackage can include the following:

    • Applications
    • COM+/MTS settings
    • Configuration files
    • Event logs
    • Files and directories
    • Hotfixes
    • Local groups
    • Local users
    • Metabase objects
    • Registry values
    • Security settings (local)
    • Services
    • External commands (that is, commands that can be issued on a command line interface)
    • For UNIX-style systems, a BLPackage can include the following:
    • AIX packages and patches
    • Configuration files
    • Files and directories
    • RPMs
    • ESX server and virtual machine configurations
    • Solaris packages, patches, and patch clusters
    • HP-UX product, patches, and bundles
    • External commands


    After you create a BLPackage, you must sometimes edit the package to insert new values for server objects, including parameterized property values. You can also change the order in which server objects are processed, insert additional commands and server objects, and make many other package- and object-level modifications.
    When you deploy a BLPackage, Configuration Manager can use two basic approaches:

    • Configuration Manager can copy the files included in the package and an XML instruction file to a staging directory on the remote hosts you have specified. (Source files can be copied from the file server or a network location.) If you are using an indirect deployment, the files are copied to a staging directory on a repeater. The installation executes on the target servers from the staging directory.
    • Configuration Manager can copy an XML instruction file to a staging directory on a repeater or the remote hosts you have specified. Those instructions tell the agent on the target server to mount or map a server at a network location that holds the source files for this deployment. From that network location, the source files are deployed directly to the target server.

    For more information on deploying BLPackages, see the BladeLogic User Guide.



    Deploying a Patrol Agent involves simply copying a directory structure (at a high level). However, we also need to add some paths into the control file as well as perform some additional steps, which is why a BLPackage is the best choice in this instance.

    The first thing is to create a structure within the BladeLogic Depot to hold any Patrol Agent assets, as well as to prepare for any future software installations that might be required:


    This will be utilized as our central repository for anything related to the deployment of Patrol Agents.
    Once we've finished, this directory will contain any relevant BLPackages, and a script to set the Server Property.


    Set Server Property Script

    The first step in preparing the BLPackage is to create an NSH script which sets up the Server Property to a default value if nothing has been entered. The script is added to the depot using the configuration shown below:


    Please see the attachments on this page for the actual script.
    The script itself requires a parameter to be configured in order to know which server it's being applied to:


    The BLPackage

    The BLPackage contains 3 key elements in order to deploy a Patrol agent:

    • The Patrol Agent install directory tree
    • The associated Component for modifying the control file
    • A number of 'external commands' that complete the configuration, installation and subsequent cleanup

    This is a screenshot of a completed BLPackage for a Windows installation:


    Note that the Unix BLPackages are typically simpler, as much of the post-install logic is handled in a single, external script (see Appendix B – page ).
    The first section (the Patrol directory tree) is simply imported into the BLPackage, as usual. (For more information, see the BladeLogic User Guide).

    Following this, the Component needs to be added to configure the following parameters:


    (Note that this parameter has no trailing slash)


    (Note that this parameter has a trailing slash)


    (Note that this parameter has no trailing slash)


    (Note that this parameter has no trailing slash)


    (Note that this parameter has no trailing slash)

    It should be particularly noted that all of these parameters are making use of the PATROL_DIR Server Property of the target server.
    With these items configured, it only remains to configure the necessary scripts. The first of these attempts to add the domain user to the local administrators group. Note that if this fails, the deployment will still continue.


    With the user correctly configured, we can proceed to actually run the installation script:

    Again, we don't want any errors from this step to disrupt the deployment, as we need to move on to the next step – cleaning up the installation on the target machine:


    Building the Deploy Job


    When you begin defining a BLPackage Deploy Job, you must choose a basic or advanced approach. (All Software Deploy Jobs use the basic approach.) The basic approach defines the job so it is automatically reset should it fail. This allows you to immediately execute the job again. When defining a basic BLPackage Deploy Job, you cannot use some advanced options for managing the flow and scheduling of the job. Basic Deploy Jobs are recommended if you are including the Deploy Job in a Batch Job. Advanced BLPackage Deploy Jobs provide greater flexibility. They let you schedule phases individually, control the flow of the job by server or phase, and manage the job's state after it executes by retrying or undoing the job


    There are a total of three jobs to be created in order to deploy the BLPackage to a Windows server:

    • Script to configure the Server Property
    • Script to perform the BLPackage deployment
    • Batch Job to run the previous jobs in the correct order against a defined list of targets.

    This is mirrored in the structure of the Jobs workspace:


    NSH Script Job

    The NSH Script Job is used to execute the NSH Script asset that we created earlier.


    When the script asset was created, we identified a parameter of 'Target Server', which needs to be reflected in the Job.


    Deploy Job

    This is the actual job that will perform the deployment of the BLPackage:



    Note that due to the manner in which Patrol Agents are deployed, we don't want to use the standard BladeLogic rollback functionality, so that must be disabled in the job definition:


    Deploying Patrol Agents

    When it comes to deploying the Patrol Agents to the respective servers, this is all handled via the batch job.
    Quite simply, a list of servers (or better still, a Server Group) should be allocated to this batch job and the job executed.
    For further details of executing Batch Jobs, please refer to the BladeLogic User Guide.