Creating a Deploy Job

You can create a Software Deploy Job, which deploys Microsoft Windows or UNIX software packages to one or more target servers or components. You can also create a BLPackage Deploy Job, which deploys a BLPackage to one or more target servers or components. Both are referred to as Deploy Jobs.

To create a Deploy Job, see the following sections:

Before you begin

Before you can deploy a BLPackage, you must store the package in the Depot. For information about bundling the assets of a BLPackage and storing it in the Depot, see Adding a BLPackage to the Depot. You should also review the caveats applicable to BLPackage deployments.

Caveats for deploying BLPackages

To deploy a BLPackage, BMC recommends that you have administrator privileges on the remote server to which you are deploying. To accomplish this, there are two approaches:
- For Windows target servers, you can use an automation principal to set up Windows user mapping. This mechanism allows you to map a role to a local or domain user on a target server who has administrator privileges. For more information about Windows user mapping, see Creating automation principals.
- For UNIX target servers and Windows servers where you do not want to use automation principals, you must map your machine or user name to a local user on the remote server. That local user should have administrator privileges. You must also perform this type of mapping on repeaters when you are copying files to them for indirect deployments, even if you are ultimately deploying files to Windows target servers using Windows user mapping. For more information about configuration files and mapping users, see Setting up configuration files.
When deploying to an agent that is running an earlier release of BMC Server Automation, the Deploy Job can complete successfully even though the agent may not recognize the server objects being deployed. This typically happens when a new server object (such as a new UNIX object) is introduced after the agent's most recent software update. If you attempt to deploy a package that includes a server object not already installed on a target server, the system skips the unknown server object and the job can still complete successfully.
When a BLPackage is based on an audit of Windows local user information, you cannot deploy values for the last logon date and last password change date.
When you are deploying a BLPackage, a Deploy Job cannot accommodate any user interaction (other than canceling the job). Any deployment that requires user input fails.
When a BLPackage includes a resource pool that contains virtual machines, you cannot deploy that package to another host server that is hosting virtual machines. Also, be aware that if a BLPackage changes the number of virtual processors on a running virtual machine, the system may become unstable.
When deploying a BLPackage to a server using SELinux, the server must be configured to allow deployment commands. When you install an RSCD agent on Linux machines, the installation program gives you the option of setting up the appropriate SELinux configuration. If you did not choose this configuration during installation, deployment of BLPackages fails. See Installing only the RSCD agent (Linux and UNIX) for details on the specific commands needed to enable asset deployment.
Limitations exist when deploying BLPackages based on Windows security settings.
When you deploy or browse local Windows security settings, many factors influence the behavior of BMC Server Automation, including the target server's operating system, the server's workgroup or stand-alone status, the presence of a domain, domain-level settings, and the refresh rate for those settings. These factors are important because the system relies on an underlying Windows utility called secedit to deploy and browse local security settings.
When a BLPackage is deployed, all security settings are applied at once. If the secedit utility returns a failure during the deployment, the Deploy Job is marked as a failure. The Deploy Job cannot provide any information about the cause of the failure because secedit does not provide that information. If secedit returns a success, the Deploy Job is marked a success. If a security setting does not apply to a target's operating system, however, inconsistent behavior may occur. For example, if you create a BLPackage containing security settings for a Windows 2003 machine, and you create the BLPackage on a Windows 2000 machine, deploying that BLPackage to a Windows 2000 machine appears to succeed. In fact, no change actually occurs on that server. On the other hand, if you create the same package on a Windows 2003 machine and deploy it to a Windows 2000 machine, the deployment fails. Error messages do not explain the cause of the failure.
If you use a Deploy Job to change security settings in the Security Options category (a subcategory of Local Policies), changes are made to the registry. If you browse the changes you have made to security settings, those changes may not display immediately.
If a security setting is defined at the domain level, the next refresh overwrites its corresponding local setting.

Before you can deploy a software package you must store the package in the Depot. For information about adding Windows patches and service packs to the Depot, see Adding a hotfix to the Depot. For information about adding all other types of software packages to the Depot, see Adding software to the Depot.

Ensure that you have the appropriate authorizations from the DeployJob.* family of authorizations. Note that the BLPackage properties listed in the Deploy Job - Package panel are controlled by the DeployJob.Modify authorization, while the Deploy Job properties listed in the Deploy Job - Properties panel are controlled by the DeployJob.ModifyProperties authorization.

For a Software Deploy Job, you must also grant the BLPackage.Create authorization to the Deploy Job. (This is due to a known issue.)

To create a BLPackage Deploy Job

To create a BLPackage Deploy Job, take one of the following actions:
- Open the Depot folder and navigate to the BLPackage you want to deploy. Right-click the package and select Deploy from the pop-up menu. The New Deploy Job wizard opens.
- Open the Jobs folder and navigate to a job folder. Right-click the job folder and select New > BLPackage Deploy Job from the pop-up menu. The New Deploy Job wizard opens.
- Using the Component Templates, Components, or Servers folder, select one or more components. Right-click and select Deploy as Target from the pop-up menu. Launching a Deploy Job in this way lets you deploy a BLPackage that uses the selected components as targets for the deployment.
Provide information for the BLPackage Deploy Job as described in the following sections:
After completing the last step of the wizard, click Finish.
After running a BLPackage Deploy Job, you can use the job results to retry, undo, or reset an entire BLPackage Job or phases of the job on specific servers. For more information, see Deploy Job results.

To create a Software Deploy Job

To deploy software, BMC recommends that you have administrator privileges on the remote server to which you are deploying. To accomplish this, there are two approaches:

For Windows target servers, you can use an automation principal to set up Windows user mapping. This mechanism allows you to map a role to a local or domain user on a target server who has administrator privileges. For more information about Windows user mapping, see Creating automation principals.
For UNIX target servers and Windows servers on which you do not want to use automation principals, you must map your machine or user name to a local user on the remote server. That local user should have administrator privileges. You must also perform this type of mapping on repeaters when you are copying files to them for indirect deployments, even if you are ultimately deploying files to Windows target servers using Windows user mapping. For more information about configuration files and mapping users, see BMC technical documentation at Setting up configuration files.

To create a Software Deploy Job, take one of the following actions:
- Open the Depot folder and navigate to the software package you want to deploy. Right-click the package and select Deploy from the pop-up menu. The New Deploy Job wizard opens.
- Open the Jobs folder and navigate to a job folder. Right-click the job folder and select New > Software Deploy Job from the pop-up menu. The New Deploy Job wizard opens.
- Using the Servers folder, right-click a server and select Browse from the pop-up menu. In the content editor, expand the Live node for the selected server, and navigate to the software that you want to deploy. Right-click the software and select Deploy from the pop-up menu. The New Deploy Job wizard opens. If software must first be added to the Depot, the Select Matching Software dialog box opens.
If the Select Matching Software window is displayed, match each software executable listed in the window to software stored in the Depot. If necessary, you can add software packages to the Depot with this process. For more information, see Matching software with depot items.
Provide information for the Deploy Job, as described in the following sections:
After completing the last step of the wizard, click Finish.
To monitor the results of a Deploy Job, see Deploy Job results. Using those results you can retry, undo, or reset an entire Deploy Job or phases of the job on specific servers.

Creating a Deploy Job

Before you begin

To create a BLPackage Deploy Job

To create a Software Deploy Job

Comments