How does BSA work?

This topic provides an overview of BMC Server Automation, its components, and who uses it. The topic includes the following sections:

What can I do with the product?

This product is a server automation tool. As an organization's server estate increases, administrators often find themselves struggling to:

  • Push out new configurations to servers
  • Deploy new servers in a consistent fashion
  • Track changes to server configurations

To help you deal with these challenging issues, the product offers the following core capabilities:

Capabilityenables you to

Perform bare-metal provisioning, VM provisioning, and full service stack provisioning, including additional configuration items to customize the deployment.

Configuration managementDeploy and track changes to server configuration across the entire estate.
Patching Push vendor updates to server OSs in a stable and consistent fashion.
Compliance Analyze an organization's overall level of compliance with internal, regulatory, and security standards.

How do I use the product?

There are various ways to interact with BMC Server Automation:


The GUI for BMC Server Automation, also known as the console, is the main interaction point for provisioning servers and automating their management. The console can connect to one or more Application Servers (also known as appservers). With the console, users can create jobs that can:

  • Automate provisioning across many different environments
  • Keep compliance under control
  • Roll out software patches
  • Automatically enforce a desired configuration state across your environment

The BladeLogic Portal is a web-based user interface targeted at end users who do not need the ability to create content for jobs. Portal users are typically operators who execute common server configuration management activities, such as patching, compliance, and software deployment.


BLCLI is the command-line interface for BMC Server Automation. It is a set of utilities that let you perform most of the tasks from a command line.

Network ShellNetwork Shell (NSH) is a network scripting language that enables cross-platform access through a command line interface. From a central workstation, you can manage servers directly with NSH, or you can first authenticate a connection via the appserver.

BMC Server Automation has two APIs: a web services API and a REST API. The SOAP API has a full range of BMC Server Automation capabilities, but uses a complicated interface. The REST API is more user-friendly, but has limited functionality.

Both APIs offer a way to make calls to the application server from the command line. This capability provides a way to further automate a BMC Server Automation implementation, and also allows for integration with other products, such as BMC Cloud Lifecycle Management. For information about the two APIs, see Working with Web Services.

What are the different components of the product?

An operational BMC Server Automationsystem has a three-tier architecture that consists of client, server, and middle tiers. The following table gives an overview of each of the architectural pieces that comprise BMC Server Automation.

ComponentWhat is it, and what does it do?
Application Server (appserver)

The appserver is the primary component in the middle tier of BMC Server Automation's three-tiered architecture.  

  • What does the appserver do?  

    The appserver provides secure, scalable software for controlling communication between BMC Server Automationcomponents—primarily the BMC Server Automationclients (described above) and RSCD agents on managed servers. Many of the appserver's actions are based on user-defined jobs that perform a variety of tasks. The appserver also provides the instructions needed to provision servers.
  • Where does the appserver run?

    Typically, the appserver runs on a dedicated machine in a central location. While only one appserver is necessary, larger installations typically configure multiple appservers. One or more may be dedicated for running jobs to improve performance and provide failover capabilities. Another may function as the interface to the console and other client applications. A third type of application server can authenticate and manage traffic between Network Shell users and RSCD agents. When a user performs any actions on a managed server, the appserver relays those instructions to the appropriate agents. If necessary, the appserver also communicates with other middle tier components—the database, file server, and PXE server (used for provisioning).
  • What components does the appserver control?

    The appserver communicates with RSCD agents and initiates all communication to perform ad hoc and scheduled tasks. Not only does the appserver manage communication between clients and remote servers, it also controls interaction with the database, file server, and PXE server.
RSCD agent

The RSCD (Remote System Call Daemon) agent is software that must be installed and running on each remote server that BMC Server Automationaccesses.

  • How does the RSCD agent work?

    The RSCD agent can perform a variety of actions. Using native operating system commands, the agent can perform simpler actions, such as moving, modifying, comparing, or deleting files. The agent can also execute jobs that require it to perform a more complex series of activities. The agent never initiates activity. It only acts when directed to, either by means of jobs running on the appserver or users directly performing actions on the server via Network Shell (NSH) or the BLCLI.
  • How is the RSCD agent different from NSH?  

    NSH is a scripting language that allows users to perform cross-platform actions on servers via a command line interface. When an RSCD agent performs actions on a managed server, it is often executing NSH commands. However, the agent is capable of performing additional activities when the appserver or BLCLI runs jobs.
  • Why would I use a repeater?

    The repeater is a file cache for deployment payloads. During deployments, files are pushed to the repeater and then from the repeater to targets. Using repeaters can limit bandwidth requirements when deploying large payloads to multiple remote systems and reduce the load on the file server on a local network.
  • Why would I use a proxy?  

    SOCKS is an Internet protocol that facilitates the routing of network packets between client-server applications via a proxy server. SOCKS performs at Layer 5 of the OSI model - the Session Layer (an intermediate layer between the presentation layer and the transport layer). If you want to manage remote servers on a different network from your BMC Server Automation system or outside your network's firewall, you can set up your appserver to communicate with those servers through SOCKS proxy servers.

NSH is a cross-platform shell with scripting capability that gives seamless access to remote servers from central management workstations.

  • What does NSH do?  

    NSH is a network scripting language that enables cross-platform access through a command line interface.
  • How would I use it?  

    You would use NSH for for ad hoc administration of one or more servers.
  • How does NSH interact with the appserver?

    You can create and schedule jobs that that run NSH scripts. Optionally, you can define a special type of appserver called an NSH Proxy Server that authenticates and manages NSH traffic.
  • What lives in the BMC Server Automation database?  

    For the most part, the database holds files and file contents. For example, the database can store snapshot data about managed servers. Snapshot data is incremental. Every subsequent run of a snapshot stores only the delta information compared to the previous snapshot. In addition to files and their contents, if the console requires long entries, that information is also stored in the database.
  • What database vendors does BMC Server Automationsupport?

    BMC Server Automationsupports both Oracle and SQL Server databases.
File serverThe file server stores files used for deployment and other large quantities of data unsuited for storage in the database. The appserver controls communication with the file server.

The following diagram shows how the various BMC Server Automationcomponents fit together.

The BMC Server AutomationSecurity Model

The product provides multiple levels of system security, ranging from unrestricted communication between management consoles and remote servers to security models that incorporate the strongest available security mechanisms.

Before you go anywhere on the console, you must authenticate with the appserver. This is done through an Authentication Profile. After that, every time a user logs on to a appserver, they specify an Authenticaiton Profile, which stores basic information about how a user connects to an appserver, such as the authentication mechanism. Users can be authenticated using different security protocols, including LDAP, RSA SecurID, and BMC Server Automation's internal authentication model. Once logged in, a user's rights are determined by a system of role-based access control (RBAC) and ACLs. Privileges can be managed at the appserver level, as well as at the RSCD level using configuration files.

The capabilities you implement depend on your own security requirements and the system components that are communicating. For an explanation of how to implement all possible security capabilities, see Administering security.

An example job in BMC Server Automation

The following is a step-by-step walkthrough describing how different components interact with each other in a sample job.  

Paul is a systems administrator for a gaming company who wants to deploy an updated configuration file to 50 servers. To deploy the file using BMC Server Automation, Paul performs the following steps:

  • Paul logs on to the console and uploads the configuration file to a repository that the appserver manages called the Depot. Paul stores the file as part of a package called a BLPackage, which includes metadata about the file (such as the file's permissions, and so on).
  • Paul uses the console to create a Deploy Job to deploy the file to select servers in the environment. He schedules the Deploy Job to run that night at 2 AM. The appserver creates the scheduled job in the database associated with that package.
  • At 2 AM, the appserver sees that there is a pending job to be executed; the appserver reads the metadata about the job, and connects over the network to the RSCD agent running on each of the 50 target servers.
  • The appserver pushes the configuration file to be deployed, along with the necessary metadata, to the RSCD agent.
  • The agent executes the commands, puts the file in the correct location, and reports the results and status back to the appserver.
  • The appserver sends any appropriate notifications for the job to the console, and stores the aggregated results for each node in the database.
  • The next morning, Paul launches the console and views the results of the job. Seeing that the configuration was successfully deployed to all 50 servers, Paul takes the rest of the day off and goes fishing.

Where to go from here

Take a look at some of the sample walkthroughs to see examples of some common product capabilities in action:

Walkthrough: Audit a single configuration item

Walkthrough: Inventory using Live Browse

Walkthrough: Build a simple BLPackage to distribute content

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