This space contains documentation for TrueSight Server Automation 8.9.03 and the later service packs for 8.9. For earlier releases, see BMC Server Automation 8.9.

Implementation process for patch management

This topic describes the workflows for installing and configuring all of the TrueSight Server Automation components for patch management, and the workflow for setting up and executing related patching jobs.

The sections below describe the tasks involved in each workflow, and provide references to further details in TrueSight Server Automation technical documentation.

Overview of patch management

Most security breaches are due to known and unpatched vulnerabilities. As a result, there is real pressure to manage patching as efficiently and effectively as possible. 

With TrueSight Server Automation, the patch administrator analyzes individual servers to determine which patches must be acquired and installed to comply with organizational standards. TrueSight Server Automation automates the process of building and maintaining a patch repository, analyzing target servers, and, if necessary, packaging and deploying patches. At the end of the process, BMC Decision Support for Server Automation or TrueSight Smart Reporting for Server Automation reports are available to show compliance.

The following table describes some key elements of the TrueSight Server Automation patch management solution.

Patch metadata

All patch vendors publish some kind of information that basically says that a given patch is needed based on operating system, application version, or existing patches. 

We call this information the patching metadata, because it tells us information about the patch: specifically where the patch applies. In TrueSight Server Automation, this metadata is stored in the patch catalog

Patch catalog

A patch catalog provides a place to store metadata about patchesPatch catalogs store vendor patch metadata, and are the source of information used for analysis, downloading patch payloads, and deployment. 

Patch catalogs can be designed for specific needs. For example, a patch catalog can used for a particular operating system, such as Microsoft Windows 2008 or 2012. With well designed patch catalogs, it is easier to select the patches that should be used when evaluating the patch configuration of a particular server.

Patching Job

You run a Patching Job to identify missing patches on your servers. A Patching Job uses the information contained in the patch catalog to analyze one or more target servers for patch compliance. 

There are three jobs that run within a Patching Job, each representing different parts of the overall patch process:

  • Analysis — The Patch Analysis Job analyzes the configuration of target servers and determines the required patches.
  • Remediation — The Patch Remediation Job downloads the payload from the vendor sites to the Patch Repository, packages the payload as a BLPackage, and creates a Deploy Job to apply the patches.
  • Deploy — The Deploy Job created during remediation is then run to deliver the required patches to targets requiring remediation. 

You can choose to run only the analysis part of a Patching Job, and then run remediation later, or you can run remediation immediately after the analysis.  

Standard Patching

Standard patching refers to applying critical or important vendor patches. The standard patching process normally involves either reusable or purpose-built Patch Smart Groups. A typical patching process includes:

  • Surveying large groups of servers, using a standard policy, for reporting and assessment purposes. This is done by setting up and executing a Patch Analysis Job. The results of the job should give you a good idea of the amount of work required to patch the environment (do many servers require more than 10-15 patches?), and the amount of time estimated. You don't typically generate the remediation packages with this job.
  • Setting up smaller patching remediation jobs, usually aligned by specific criteria, such as maintenance window, business unit, change control/request or server owner groups, or some combination of those. These patching jobs will generate remediation packages, and those remediation jobs will need to execute all within a particular maintenance window, or when a particular change is approved to run, and so on, depending on the criteria.
  • Once staged and executed, the patching job will usually be re-run, for one of the following reasons:
      • Reporting purposes
      • To either certify that the group of servers no longer need patches
      • To do a second-pass deployment for any “still missing” patches or patches that did not deploy the first time.

Some companies perform this cycle twice, with the third Patching Job performing the verification/reporting, as it is sometimes difficult to achieve 99% compliance with one remediation pass. A typical full patch management lifecycle is 15-30 days for the full production environment, with another 15 days up front for pre-production.

Emergency patching

Also known as zero day or critical patching, emergency patching refers to either one specific patch, or a list of similar patches. The process is actually a lot like standard patching, but the change controls tend to be broader, and more servers tend to get remediated within the same job (or by using fewer jobs than the standard patch process).

Since this patch list is highly focused, testing overhead tends to be smaller, and the windows into which the patches are deployed tend to be much narrower. A typical window for emergency patching could be 10 days for the entire environment.

Patch Compliance dashboards are critical for emergency patching, and since these usually still need to run in some kind of seven day maintenance windows, the capability to quickly understand deployment success rates and patch compliance across specific groups or populations is very important.

Deployment success rates and patch compliance for emergency patching are mostly measured using job results, and also with trailing reports in BMC Decision Support for Server Automation or TrueSight Smart Reporting for Server Automation.

Patch management consists of the following tasks:

  1. Preparatory tasks
    1. Defining role-based permissions
    2. Configuring Global Configuration parameters

  2. (Offline mode only) Building an offline patch repository
    1. Downloading patch downloader utilities from BMC
    2. Preparing XML configuration files for downloading patch content
    3. Downloading patches to the offline patch repository
  3. Patching tasks
    1. Creating and updating a patch catalog
    2. Creating and running a Patching Job and a Remediation Job

These tasks are described in more detail in Checklist for setting up and enabling patch management.


BMC recommends that you set up a small test group of servers and run the patch process on the group. Then, expand the process to all servers in the organization.

Back to top

What environments are supported?

Supported platforms for storing the patch repositories of patch catalogs

Patch catalogSupported platforms for storing patch repositories

Windows or Unix


Any AIX server

Note: If you are downloading patches using the SUMA option, ensure that you have the SUMA utility installed on your repository server.

Red Hat Enterprise Linux (RHEL) using the CDN interface

Red Hat Enterprise Linux 6, 7, or 8

SuSE Linux 12

SuSE Linux with SMT installed.

Note:To patch SuSE 12 targets, ensure that the SuSE patch repository server is configured with the Subscription Management Tool (SMT).

The following table lists the versions that are installed with SMT out-of-the-box, as well as the versions on which SMT must be manually installed.

Repository server versionSMT installation

SuSE 11 SP3
SuSE 11 SP4

SuSE 12

Note: SuSE recommends upgrading SuSE 12 to SuSE 12 SP1 to avoid dependency issues.

Not configured with SMT out of the box. You must manually install and configure SMT (version 11 SP3) on the repository server before you create a SuSE patch catalog.
SuSE 12 SP1 or later (recommended)SMT is shipped out-of-the-box with the operating system.

Warning: BMC strongly recommends using Zypper when creating a patching job for a patch catalog that was created using the Subscription Management Tool (SMT). For more information, see Zypper patching tool.

SuSE Linux 11SuSE Linux with createrepo and python-urlgrabber installed.
Oracle Enterprise LinuxAny supported RPM-based Linux with createrepo and python-urlgrabber installed

Windows or Unix

Note: If you are using Solaris 11 patches, you can only use a Solaris 11 server for storing the patch repository.

DebianWindows or Unix
Cent OSAny supported RPM-based Linux with createrepo and python-urlgrabber installed
Fujitsu SolarisWindows or Linux

An HP-UX patch repository must reside either directly on the HP-UX (SWA) Server or in a directory that the SWA Server considers to be a local share.

Note that if you are using an offline downloader, you can run the offline downloader on any Windows or Linux machine, but the HP-UX patch repository must still reside on the HP-UX (SWA) Server.

Back to top

Checklist for setting up and enabling patch management

The following table provides a checklist for performing all of the tasks required to set up the provisioning system and provision servers. Each step in the table also includes a link to more information.

 StepDescriptionMore information

Set up roles and permissions



To create or update a catalog, you must be assigned a role that includes the necessary permissions. You can assign permissions to one role or divide them between several roles.

Although this process is not essential for patch management, BMC always recommends that you grant users the minimum set of permissions needed to perform actions. If you do not set up a patching administrator with a limited set of permissions, a superuser such as the BLAdmins role must perform patch management. Grant the minimum set of permissions to the patching administrator, as well as grant the minimum level of access to any servers where you will be setting up patching infrastructure.

Walkthrough: Restricting permissions for a patching administrator

Minimum permissions for patching

2Configure global patch configuration parameter

Global Configuration parameters provide basic information used during patch catalog creation and updating, as well as for Patch and Remediation Jobs. The following parameter groups are available:

  • All Operating Systems — Configuration parameter options for a proxy server.
  • Platform-specific groups for each platform (such as Windows and Solaris) — Parameters that apply only to that specific platform type
  • Shavlik URL Configuration — Configuration for connecting to Shavlik Technologies to download patch-related metadata for patching Windows software.

Global Configuration parameter list


Choose offline mode or online mode


There are two patch management modes:

  • Online mode — Patches are downloaded directly from the appropriate product site. Online mode indicates the TrueSight Server Automation application server has direct internet access and downloads the patch metadata and payloads from the Shavlik networks (for Microsoft systems) or the OS vendor web sites.  
  • Offline mode — Patches are pre-downloaded to a local repository and patches are applied from the repository. Offline mode is useful when, for whatever reason, the TrueSight Server Automation application server doesn't have internet access. Use Offline mode if you work in an air-gapped environment. In Offline mode, you use the BMC offline Patch Downloader utility to download metadata and payload information to a server with Internet access. After downloading, you can transfer the metadata and payload information (using removable storage) to the patch repository within the air-gapped environment.

The Patch Downloader utilities run scripts that use XML configuration files (samples are provided with the product) containing required information such as the repository location, as well as filters used during downloading from the vendor website.

5Create a patch repository for offline mode

In an offline environment, Internet access is not available to any of the servers in the environment. In this case, you work in Offline Mode using the Patch Downloader utility to download metadata and payload information to a server with Internet access. After downloading, you transfer metadata and payload information, using removable storage, to the patch repository within the air-gapped environment.

From the BMC EPD site, download the appropriate utilities for building your offline repository. The utilities are platform-specific. You must know which platform you plan to use to download your patches.

Use the utilities that you downloaded from the BMC EPD site to prepare the XML configuration files for downloading the patch content. To download the patch content, use the utilities and the XML configuration files that you prepared.

Setting up the Offline Patch Downloader utility

Downloading and extracting patch downloader utilities

Creating a patch catalog in offline mode


Create a patch catalog in online mode


For both types of repositories, online and offline, you create a patch catalog using the TrueSight Server Automation Console. Patches are added to the catalog as depot objects according to filters that you define for the catalog.

Creating a patch catalog

Walkthrough: Setting up and managing an online patch catalog for Windows

Walkthrough: Setting up and managing an online patch catalog for Linux

7Stock the catalogTo ensure that you are working with valid patch content, you must run a Catalog Update Job before you run a Patch Job. Updating an existing catalog
8Creating and running a Patching and Remediation Job

A Patching Job has two parts:

  • Analysis — Analyzes the configuration of target servers and determines the required patches.
  • Remediation —
    1. Downloads the payload from the vendor sites to the Patch Repository
    2. Packages the payload as a BLPackage
    3. Creates a Deploy Job to apply the patches  

You can choose to run only the Analysis part of a Patching Job, and then run Remediation later, or you can run Remediation immediately after the Analysis. 

Creating a Patching Job

Walkthrough: Basic Microsoft Windows patch analysis

Walkthrough: Basic Red Hat Linux patch analysis

Walkthrough: Basic patch remediation

Remediating servers

Back to top

Patch management authorization requirements

To perform patch analysis and remediation tasks, you must have the appropriate authorizations assigned to your user role and to the relevant system objects and resources. The following tables list the minimum authorizations required, for both roles and objects. For a list of permissions required for a specific role, such as patch catalog manager, see Minimum permissions for patching.

Minimum permissions for patching

ACLPolicy.*Create ACL policies to grant permissions to other roles that download patch objects.
ACLTemplate.*Create ACL templates to grant permissions to other roles that download patch objects.
AIXPatchSoftware.*AIX only: Create and read patch software.


AIX only: Create and read software.

BatchJob.*Create and execute Batch Jobs that run concatenated Deploy Jobs
BLPackage.*Create remediation packages and read their contents.
CustomSoftware.*Linux and Windows only: Create Linux remediation jobs and read their contents.
DeployJob.*Read and execute jobs that deploy patch packages.
DepotFile.*Optional: Manage offline patch catalog metadata content.
Create the patch catalog in a depot folder or create remediation objects in a depot folder.


Navigate to the patch catalog or remediation objects in a depot group.

Create Patch Analysis jobs and remediation jobs in a folder or navigate to them in a group.
Create Patch Analysis jobs and remediation jobs in a folder or navigate to them in a group.
LinuxSoftware.*Linux only: Create and read software.
PatchCatalog.*Create and manage a patch catalog
PatchDownloadJob.*Manage patch downloads.
PatchGlobalConfig.ModifyOptional: Manage global patch settings.
PatchingJob.ReadRead the jobs used as the basis of remediation.
PatchRemedationJob.*Manage patch remediation jobs.
PatchSmartGroup.*Create smart groups in the patch catalog.
Create a patch repository on a helper server, read the contents of the repository, read contents of target servers, deploy patches to target servers.
ServerGroup.ReadAllow user to browse to the helper server when selecting it and to browse to target servers.
SolarisSoftware.*Solaris only: Create and read software.
WindowsSoftware.*Windows only: Create and read software.
PatchSmartGroup.ReadAllow user to open patch smart groups
PatchSmartGroup.WriteAllow user to add new objects into patch smart groups

Object level permissions for patching

Depot folders


Grant these permissions on the depot folder where you create a patch catalog and to all depot folders that are parents of the patch catalog folder.

Also grant these permissions on the depot folder where you create any remediation packages and to all parent job folders or groups.

Server functioning as a patch repository


Grant these permissions to the server used as a patch repository.
Target serversServer.Deploy
Grant these permissions on target servers.
Target server groupsServerGroup.ReadGrant these permissions on any target server groups that hold the target server.
Job folder containing Patching and remediation jobsJobGroup.Read

Grant these permissions on the job folder where you create a Patching Job and to all parent job folders or groups.

Also grant these permissions on the job folder where you create any remediation jobs and to all parent job folders or groups.

Patching jobs



Grant this permission on any Patching Jobs.

Back to top

Sizing the patch repositories

See the section about Patch Repository Sizing in the TrueSight Server Automation Sizing Guide available from the BMC Communities for the latest sizing and scalability recommendations. 

Where to go from here

Getting started with patch management

Patch management

Was this page helpful? Yes No Submitting... Thank you