Important

   

Starting version 8.9.03, BMC Server Automation is renamed to TrueSight Server Automation. This space contains information about BMC Server Automation 8.9.02 and previous versions. For TrueSight Server Automation 8.9.03 and later releases, see TrueSight Server Automation 8.9.

Choosing commit and undo options

Commit and Undo Options let you customize the behavior of a Deploy Job during its Commit phase and during the undo of a deployment.

To choose commit options

  1. Check Auto rollback to leave the destination host unchanged should the Commit phase fail.
    When you check this option and the Commit phase fails for any reason, the Deploy Job is automatically rolled back, leaving the destination host unchanged. If you do not check this option and the Commit phase fails, the deployment aborts and does not roll back any transactions that are part of the deployment.

    Note

    Using the BLPackage editor, you can customize the behavior of a deployment so individual commands in the deployment can fail but the overall deployment continues (see Adding an external command to a BLPackage).

  2. Check Allow rollback to leave rollback files on the target server so they can potentially be used later to undo a deployment. In some situations, the rollback files left on the target server can be large.

    Warning


    Rollback files reside under agentInstallDirectory/Transactions.

    For UNIX, by default this location is:
    /opt/bmc/BladeLogic/NSH/Transactions

    For Microsoft Windows, the default the location is:
    C:\Program Files\BMC Software\BladeLogic\RSCD\Transactions

    BMC Server Automation provides a mechanism for storing rollback information in an alternate location. For details, see Configuring the location of the transactions directory.

  3. Check Preserve staging area on failure if you want to keep the data copied to a staging area for the BLPackage even though this Deploy Job fails.
    By default a Deploy Job deletes the staging directory on a target server when a failure occurs during any phase of the job. Preserving a staging area can potentially leave large files on a target directory after a job failure.
  4. Check Overwrite read-only files to instruct a server to overwrite read-only files when read-only files are encountered during the Commit phase.

    Note

    This option is only for copying a file onto a target with an existing file that is currently read-only. The option does not affect any asset type other than the file asset and the copying of the entire file. For example, if there is a change to a configuration file and the configuration file asset is used, the override option does not attempt to alter the file state to allow configuration file updating and editing. However, if the entire configuration file was packaged as a file asset, then the file to be copied onto the target and the read-only option are temporarily changed, assuming that the user and role being deployed have appropriate permissions.

  5. If you are deploying to Windows machines, check any of the following options under Windows-only Options:

    Option

    Description

    Ignore presence of "copy on boot" files

    Instructs a server to begin the Commit phase even though a server requires a reboot to copy over existing locked files. Clearing this option means the Commit phase does not begin if locked files requiring a reboot exist.

    Copy locked files (do not treat locked files as error)

    Instructs a server to create "copy on boot" files when locked files are encountered during the Commit phase. These are files that are copied and then overwritten after a reboot. Note that a Deploy Job only creates "copy on boot" versions of read-only files if the Overwrite read-only files option (see above) is checked.
    Clearing this option means the job repeatedly attempts to copy the files being modified. The job attempts to copy the files 25 times, with a two-second wait between each attempt. If files are still not successfully copied, the job generates an error and fails.

    Register COM components

    Commit Phase — Registers COM objects during the Commit phase. When a deployment adds a file with an extension of DLL, EXE, or OCX, the job determines if the file is a COM object. If it is, the deployment registers the new object during the Commit phase.
    Undo Phase — Registers COM objects during the Undo phase. If the Commit phase of a job run removes a file, the file is restored when that job run is undone. If the file has an extension of DLL, EXE, or OCX, the job determines if the file is a COM object. If it is, and this option was selected during the Commit phase of the job run being undone, the file being restored is registered.

    Unregister COM components on delete

    Commit Phase — Unregisters COM objects during the Commit phase. When a deployment removes a file with an extension of DLL, EXE, or OCX, the job determines whether the file is a COM object. If it is, the deployment unregisters the object during the Commit phase.
    Undo Phase — Unregisters COM objects during the Undo phase. If the Commit phase of a job run adds a file, the file is removed when that job run is undone. If the file has an extension of DLL, EXE, or OCX, the job determines whether the file is a COM object. If it is and this option was selected during the Commit phase of the job run being undone, the file being removed is unregistered.

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

Comments