Global Configuration parameter list

Proxy Server Type

Select the type of proxy server used:

• SQUID
• NTLM
• NTLM-V2
• None — Select when you are not using a proxy server

User Name

Enter the user name required to log onto the proxy server. If this is defined, the Internet connection is through the proxy server.

Password

Enter the password associated with the defined user name required to log onto the proxy server.

Domain

Enter the domain name of the proxy server.

Host

Enter the IP Address or Host Name of the proxy server.

Port

Enter the port number used for communication with the proxy server. For a list of all port numbers used by BMC Server Automation, see BMC Server Automation ports.

If a catalog update fails you can use the last successful run of the Patch Catalog update while executing the Patching job.

• Select Yes, if you want to use the last successful catalog run as input to run a Patching job.
• Select No, if you do not want to use the last successful catalog run as input to run a Patching job. The Catalog update job must be run successfully for you to execute the Patching job.

Note: A set of additional checks are applied during a catalog update. If any of these checks fail, you can still analyze and deploy the patches by using the last successful update of the Patch catalog, by selecting Yes. However, if catalog update fails after these checks complete, the catalog or the repository might have been modified. In this case, you cannot use the last successful update of the Patch catalog to deploy the patch.

RHN Username

(Red Hat Linux only) User name for accessing the Red Hat Network

RHN Password

(Red Hat Linux only) Password for accessing the Red Hat Network

Oracle Username

(Solaris only) User name for accessing the Oracle website

Oracle Password

(Solaris only) Password for accessing the Oracle website

Catalog Object Processor Batch Size

The default batch size used for parallel processing during a Catalog Update Job. The number of catalog objects processed by each batch. If no value is entered, the default value is 300.
Note: Setting a lower default value speeds up catalog update but uses more work item threads and consumes more resources on the BMC Server Automation Console; conversely, setting a higher default value slows down catalog update but uses less work item threads and consumes fewer resources. After you set this value, do not change it unless specifically required.

Analysis Server Results Batch Size

The default batch size used for parallel processing during a Patching Job. The number of analysis processes handled by each batch. If no value is entered, the default value is set at 100.
Note: Setting a lower default value speeds up analysis but consumes more resources on the BMC Server Automation Console; conversely, setting a higher default value slows down analysis but consumes less resources. After you set this value, do not change it unless specifically required.

Action on Failure

The action that BMC Server Automation takes if a patch fails to deploy:

• Ignore — Ignore the failure. The Deploy Job continues and the results show the job as succeeding.
• Abort — End the job and start a rollback.
• Continue — Continue despite the failure. The Deploy Job continues and the results show the job as failing.
  Note: On Linux platforms, patches are deployed using the blyum utility. As a result, if you are applying a series of RPMs, and blyum fails to deploy any of the RPMs, it stops at that point. The value set in Action on Failure is ignored.

Ldom option

(Solaris Only) Options to patch independent Solaris logical domains (LDoms) simultaneously. For more information, see Patching Job - Independent Solaris LDoms can be patched simultaneously. The following options are provided:

• None (default value) — This option ignores the LDoms and treats the targets as physical installations of Solaris. Use this option if you want to ignore the LDoms even if LDom packages are installed on your computer.
• Stop Ldoms using ldm stop — This option stops the LDoms using the ldm stop command (however, the guest LDoms are not gracefully shut down).
• Shutdown Ldoms using ldm-names as hostname — This option executes the shutdown command on the guests by using the nexec parameter, and by using ldm-name as the hostname for nexec.

Single User Mode and Reboot Override File

(Solaris Only) The location in the Depot for the file used to override single-user mode and reboot settings for a particular patch.

Solaris Updates List File

(Solaris Only) The location of the file containing released information from Oracle about clusters. Information contained in this file is used to prepopulate the filter selection lists found in the patch catalog wizard.

Windows Filter Configuration File

(Microsoft Windows Only) The location of the file containing released information from Shavlik. Information contained in this file is used to pre-populate the filter selection lists found in the patch catalog wizard.

SuSE Service Packs List File

(SuSE Only) The location of the file containing released information of service packs from Novell. Information contained in this file is used to pre-populate the filter selection lists found in the patch catalog wizard.

Novell Username

Username for accessing SuSE Linux Enterprise 9 URLs.

Novell Password

Password for accessing SuSE Linux Enterprise 9 URLs.

Novell Mirror Username

Username for accessing SuSE Linux Enterprise 10 and SuSE Linux Enterprise 11 mirror URLs.

Novell Mirror Password

Password for accessing SuSE Linux Enterprise 10 and SuSE Linux Enterprise 11 mirror URLs.

HTTP/HTTPS/FTP Connection Retry

(Windows, Solaris, Red Hat Linux, SuSE, and AIX) The number of attempts made before reporting failure if BMC Server Automation fails to connect to a vendor site.

HTTP/HTTPS/FTP Connection Timeout

(Windows, Solaris, Red Hat Linux, SuSE, and AIX) The length of time, in milliseconds, that BMC Server Automation waits before making another attempt to connect to the vendor site.

AIX Updates List File

(AIX Only) The location of the file containing released information from IBM about available Technology Levels and Service Packs. Information contained in this file is used to prepopulate the Technology Level and Service Pack filter selection lists found in the patch catalog wizard.

Analysis Option

(AIX Only) Select one of the following:

• Stop Analysis if any applied fileset found — Select to stop analysis if any fileset is found in the applied state on a target server. Analysis ends on that server but continues on all other target servers included in the Patching Job if the servers do not have filesets in the applied state. This option can also be set for an individual Patching Job.
• Continue Analysis if any applied fileset found — Analysis continues even if a fileset in the applied state is found on the target server.

Precommit Option

(AIX Only) Select one of the following actions:

• Commit All Applied — Changes the state of all currently installed filesets from Applied to Commit.
• None — The state of all currently installed filesets in the Applied state does not change.

Deploy Option

(AIX Only) Select one of the following actions:

• Apply and Commit — During deployment, all filesets for the target server are installed in the Commit state.
• Apply Only — During deployment, all filesets for the target server are installed in the Apply state.

Patch deploy success return codes

The Deploy Job sends commands to the OS which in turn sends responses back to BMC Server Automation indicating that the commands succeeded. In most cases, standard commands are used but occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as success return codes.

Patch deploy failure return codes

The Deploy Job sends commands to the OS which in turn sends responses back to BMC Server Automation indicating that the commands failed. In most cases, standard commands are used. However, occasionally the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as failure return codes.

Patch deploy warning return codes

The Deploy Job sends commands to the OS which in turn sends warnings back to BMC Server Automation. In most cases, standard warnings are used; occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as warning return codes.

Patch deploy reboot return codes

The Deploy Job sends commands to the OS which in turn sends back a request for reboot to BMC Server Automation. In most cases, standard commands are used; occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as reboot return codes.

Patch undeploy success return codes

(Microsoft Windows and Oracle Solaris only) During rollback of a patch, the OS returns an exit code if the action was successful. In most cases, standard commands are used; occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as undeploy success return codes.

Patch undeploy failure return codes

(Microsoft Windows and Oracle Solaris only) During rollback of a patch, the OS returns an exit code if the action failed. In most cases, standard commands are used; occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as undeploy failure return codes.

Patch undeploy warning return codes

(Microsoft Windows and Oracle Solaris only) During rollback of a patch, the OS may return a warning. In most cases, standard commands are used; occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as undeploy warning return codes.

Patch undeploy reboot return codes

(Microsoft Windows and Oracle Solaris only) During rollback of a patch, the OS may send back a request for reboot to BMC Server Automation. In most cases, standard commands are used; occasionally, the OS uses a return code not known to BMC Server Automation. Unknown codes entered in this field are defined to BMC Server Automation as reboot return codes

Command Priority

(Microsoft Windows only) One of the commands that BMC Server Automation runs on target servers during Patching Jobs consumes a large amount of CPU power. On servers that only have a single CPU this can give the appearance of a system hang. It may also have an effect on other processes that are running on the target server.

If you are patching single-CPU Windows servers, you can lower the priority for this command using the Command Priority option. This causes this specific command to run at a lower priority, slowing down this process, and allowing other processes to proceed normally.

Possible values are:

• Normal
• Below Normal
  
  Default value is Normal.
  Note: Changing this option affects all Windows Patching Jobs.

Shavlik URL Configuration Type

(Read-only) The name of the configuration file downloaded from the Shavlik Technologies website.

URI (http URL/NSH path)

URL of the Shavlik Technologies website where the PD5.cab (or PD5.xml) or HFNetChk7b.cab (or HFNetChk7b.xml) configuration file can be downloaded or the NSH location of the file on your servers. You can change this to any URL that has valid copies of these files.

Download

Select this to begin downloading from the Shavlik Technologies website using the URL you provided in the URI box. The configuration files are stored on the file server in the templates directory.

Description

Enter a description for the URL/NSH patch you entered in the URI box.

Check for updates

Select this to overwrite the PDF5.cab or HFNetChk7b.cab file downloaded previously. If you click Download, it overwrites any previous copies of the file.