Page tree

Skip to end of metadata
Go to start of metadata

<[^>]+?>","")"/>

<[^>]+?>","")" class="contextID">

The Add Software panel lets you choose the software items you want to package. You can specify multiple software items, if necessary. For detailed instructions on using this panel, see Adding software.

When specifying a software package to add, you can choose how the software package is stored until deployment. You can copy all the contents of the software package to the file server, or you can specify a network location for the source files. A Deploy Job can copy the software package directly from the network location to a staging directory on the target, or the target can mount/map the source location and execute the software from there. When a software package includes support files, you can even mix storage approaches — for example, storing the package in the Depot but using agent mounting to deploy extremely large CAB files from a network location. Using a network location gives you the option of maintaining only one copy of a source file. Network locations also let you avoid copying a software package to a staging area on the target server, thus reducing the disk space used on the target.

Warning

If you package files for a large network-based deployment, consider the capabilities of your network and the server being mounted or mapped. When you deploy a package to a large number of target servers, the agents on those servers must mount or map the host where source files are located.

The Add Software panel establishes the install and uninstall command for a software package. A default install and uninstall command is provided automatically for each software package you select. You may need to modify these commands. If you are adding custom software, you typically need to provide install and uninstall commands.

The Add Software panel also lets you identify the location of support files needed for an installation, such as a response file.

All software, when being installed or uninstalled, generates a return code that BMC Server Automation processes. BMC Server Automation treats all nonzero return codes as errors except the Windows return code of 3010, which indicates the job was a success but a reboot is necessary. Using the BLCLI, you can define an override list of return codes that indicate errors, warnings, successes, or successes that require a reboot. (For more information, see the BLCLI Help.) BMC Server Automation matches the software's return code against the override list using this matching order:

  • Error
  • Warning
  • Success that requires a reboot
  • Success

Any return code that does not match the override list uses the default logic — that is, all nonzero return codes are treated as errors (except 3010 for Windows).