Global Configuration parameter list

Global configuration parameters provide basic information that is automatically supplied as the default during catalog creation and update as well as during Patching and Remediation Job creation. The following sections describe the configuration parameters and how to configure these parameters:

To configure global patch configuration parameters
Parameters on the All Operating Systems tab
Platform-specific parameters
Common parameters in the platforms
Options on the yum.conf tab for Red Hat Enterprise Linux, Oracle Enterprise Linux, Generic RPM Linux, and SUSE Linux Enterprise servers
Parameters on the Shavlik URL Configuration tab
Where to go from here

To have basic information automatically supplied during catalog creation and update as well as Patching and Remediation Job creation, configure global patch configuration parameters.

To configure global patch configuration parameters

From the Configuration menu, select Patch Global Configuration.
The Patch Global Configuration dialog box is displayed.
Update the parameters as necessary.
The parameters are divided into the following tabs:
- All Operating Systems — Configuration parameters options for a proxy server
- Platform-specific tabs – For each platform (such as the Windows tab and the Solaris tab) – Parameters that apply only to that specific platform type
- Shavlik URL Configuration — Configuration for connecting to Shavlik for downloading Microsoft Windows patch related metadata
  The Shavlik metadata download occurs during Live Browse operations of the hotfixes node in a Server Object, or during a Catalog Update Job run for an online Windows Patch Catalog. For Offline Windows Patch Catalogs, the metadata files must be added as Depot Files, as noted in the Patch-catalog-Windows-Catalog page.

Parameters on the All Operating Systems tab

Platform-specific parameters

You must configure the parameters for every platform that you want to patch using TrueSight Server Automation.

Parameters for Red Hat Linux (Red Hat tab)
Parameters for Solaris (Solaris tab)
Parameters for Windows (Windows tab)
Parameters for SuSE (SuSE Linux tab)
Parameters for AIX (AIX tab)
Parameters for Amazon Linux, CentOS, and OL ULN (Generic RPM Linux tab)
Parameters for Oracle Linux (Oracle Linux - Public Repo tab)

Parameters for Red Hat Linux (Red Hat tab)

Parameter	Description
SSL CA Cert File (for targets with 32-bit, 64-bit, Z series (s390x), ppc64le, and P series (ppc64) architectures)	The location of the CA certificate file (redhat-uep.pem) that is copied from the Red Hat subscription management service, see Step 3: Obtain the required certificates. .
SSL Client Cert File (for targets with 32-bit, 64-bit, Z series (s390x), ppc64le, and P series (ppc64) architectures)	The location of the subscription certificate file (client-cert.pem) that is downloaded from the Red Hat subscription management service, see Step 3: Obtain the required certificates.
SSL Client Key File (for targets with 32-bit, 64-bit, Z series (s390x), ppc64le, and P series (ppc64) architectures)	The location of the system ID file (client-key.pem) that is downloaded from the Red Hat subscription management service, see Step 3: Obtain the required certificates.
Red Hat Channel Filters List File	(Red Hat Linux only) Use this XML file to customize the Red Hat child channel filter list that is displayed while creating the online catalog. You can add modify this file to add additional Red Hat child channel filters in the list. Note: If you modify a URL for an existing channel, the URL is not updated for the catalog that already uses this channel. To use the new URL, delete the filter (channel) from the catalog and add the same channel again. Upload the updated XML file so that the Application Server can use it. Do the following: Click . Select the updated XML file that is located on the target server. Click Apply and OK.
Red Hat ISO URLs File (CDN repo)	(Red Hat Linux only) By default, TrueSight Server Automation supports update-level patching for RHEL 6 and 7 with the CDN download option. You can customize the Red Hat ISO URLs XML file to extend update-level patching support for RHEL 5 targets.
Yum Process Priority (nice value)	(Red Hat Linux only) Set the priority of a process. The default value is 0. You can set the value within a range -20 to 19. These range limits denote: -20: Process has high priority and gets more resources, thus slowing down other processes. 19: Process has lower priority and runs slowly itself, but has less impact on the speed of other running processes.

Parameters for Solaris (Solaris tab)

Parameter	Description
Oracle Username	(Solaris only) User name for accessing the Oracle website
Oracle Password	(Solaris only) Password for accessing the Oracle website
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.

Parameters for Windows (Windows tab)

Parameter	Description
Windows Filter Configuration File	(Microsoft Windows Only) The location of the product_categories.xml file, which contains product information and metadata mapping information from Shavlik. Information contained in this file is used to populate the filter selection lists found in the patch catalog wizard. If you want to add a new product to the filter list, you must add a new product_category tag in the product_categories.xml and add a vendor node. You can also add specific information to the optional nodes (family, version, product, include_products, exclude_products). To customize the products in the product_categories.xml file, perform the following steps: Navigate to the Configuration > Patch Global Configuration > Windows tab. In the Windows Filter Configuration File field, download the the product_categories.xml file by clicking the button. Customize the products in the exported product_categories.xml file based on your requirement. For more information about how to customize using product_categories.xml, click the following link: Customizing the product_category.xml file To export patch metadata from the Shavlik to a CSV file, run the offline Patch Downloader utility for Microsoft Windows with the following command: windows_downloader.bat -configFile <DownloadConfigurationXMLFile> -exportIvantiProductCatalog <CSVFile> Using this option, a CSV file (see sample ProductCatalog.csv) containing the Ivanti product information with Product Name, Vendor Name, Patch Key, Version fields is generated. Find your product from the CSV file that you want to add to the filter list (for creating category). Refer to the CSV file generated in step a. Customize the product_categories.xml depending on the products. The following tags are used in the product_categories.xml : product_category - This represents the name you want to display in the filter list. vendor - (Root node) This represents all software vendors which are supported by Shavlik like Microsoft, Firefox, and so on. If you want to add all the products for a specified vendor, ensure that you must mention only the vendor name. For example, to add all products for Notepad++, use the following block: <product_category name="Notepad++"> <vendor name="Notepad++"/> </product_category> family - (optional node) This represents a product line or categorization supported by vendor. Under each vendor tag, there can be one or many family tags. If you want to add all the products for a specified family of a vendor, ensure that you must mention the vendor name and the family name. For example, to add all products for Yahoo Messenger (Family) of Yahoo (Vendor), use the following block: <product_category name="SCCM"> <vendor name="Microsoft"> <family name="SCCM"/> </vendor> </product_category> version - (optional node) This represents a major version or release of a product family. Under each family tag, there can be one or many version tags. If you want to add all the products for a specified version of a family, ensure that you must mention the vendor name, family name, and version name. For example, to add all products for SQL Server 2012, use the following block: <product_category name="SQL Server 2012"> <vendor name="Microsoft"> <family name="SQL Server"> <version name="SQL Server 2012"/> </family> </vendor> </product_category> product - (optional node) This represents a specific product edition or release. Under each version tag, there can be one or more produdct tags. If you want to add a specific product, ensure that you must mention the vendor name, family name, version name, and product name. For example, to add Visio 2007 MUI, use the following block: <product_category name="Microsoft Office Visio 2007 MUI"> <vendor name="Microsoft"> <family name="Office"> <version name="Visio 2007"> <include_products> <product name="Visio 2007 MUI"/> </include_products> </version> </family> </vendor> </product_category> include_products - (optional node) This repesents the list of products to be included in the filter list. This tag needs to be added under version tag. You can use either include_products tag or exclude_products tag. The include_products tag is useful when only a few specific products are intended to be considered under a version. The version might have more than 100 products under it, but you want to consider only a few of them in the product category. However, when you are using this tag, then any new sub-product that is released by the vendor for the specified version is not considered for catalogs. For example, to add Microsoft Office Web Apps Application Server Components 2013 x64, use the following block: <product_category name="Microsoft Office Web Apps 2013"> <vendor name="Microsoft"> <family name="Office"> <version name="Office Server 2013"> <include_products> <product name="Microsoft Office Web Apps Application Server Components 2013 x64"/> </include_products> </version> </family> </vendor> </product_category> exclude_products - (optional node) This repesents the list of products not to be included in the filter list. This tag needs to be added under version tag. You can use either include_products tag or exclude_products tag. The exclude_products tag is useful when only a few specific products are intended to be excluded from a version. For example, a version has 100 products under it, but you want to exclude five products from the product category. Instead of using include_products tag for 95 products, you can use exclude_products for five products. However, when you are using this tag, then any new sub-product (except the ones mentioned as part of the exclude_products tag) that is released by the vendor for the specified version is considered automatically for catalogs. For example, to add all products under Windows Server 2008 R2 except Windows Home Server 2011, use the following block: <product_category name="Microsoft Windows Server 2008"> <vendor name="Microsoft"> <family name="Windows"> <version name="Windows Server 2008" /> <version name="Windows Server 2008 R2"> <exclude_products> <product name="Windows Home Server 2011" /> </exclude_products> </version> </family> </vendor> </product_category> Use the Windows Filter Configuration File field in the Global-Configuration-parameter-list to point to the modified file. If you no longer want to use the customized product_categories.xml file and use the default xml file, click to remove the customized file. Important BMC recommends that you keep a backup of the product_categories.xml file before upgrading. After you upgrade, go to the file server and manually move the product_categories.xml file located at <fileserver location>\patch\GlobalConstants to a folder outside the file server. After moving the file, download the latest file from Patch Global Configuration.
Command Priority	(Microsoft Windows only) One of the commands that TrueSight 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 consumption 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 by using the Command Priority option. This option 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.

Parameter

Description

Windows Filter Configuration File

(Microsoft Windows Only) The location of the product_categories.xml file, which contains product information and metadata mapping information from Shavlik. Information contained in this file is used to populate the filter selection lists found in the patch catalog wizard.

If you want to add a new product to the filter list, you must add a new product_category tag in the product_categories.xml and add a vendor node. You can also add specific information to the optional nodes (family, version, product, include_products, exclude_products).

To customize the products in the product_categories.xml file, perform the following steps:

Navigate to the Configuration > Patch Global Configuration > Windows tab.
In the Windows Filter Configuration File field, download the the product_categories.xml file by clicking the button.
Customize the products in the exported product_categories.xml file based on your requirement. For more information about how to customize using product_categories.xml, click the following link:
Customizing the product_category.xml file
1. To export patch metadata from the Shavlik to a CSV file, run the offline Patch Downloader utility for Microsoft Windows with the following command:
  
  windows_downloader.bat -configFile <DownloadConfigurationXMLFile> -exportIvantiProductCatalog <CSVFile>
  
  Using this option, a CSV file (see sample ProductCatalog.csv) containing the Ivanti product information with Product Name, Vendor Name, Patch Key, Version fields is generated.
2. Find your product from the CSV file that you want to add to the filter list (for creating category). Refer to the CSV file generated in step a.
3. Customize the product_categories.xml depending on the products. The following tags are used in the product_categories.xml :
1. product_category - This represents the name you want to display in the filter list.
  vendor - (Root node) This represents all software vendors which are supported by Shavlik like Microsoft, Firefox, and so on. If you want to add all the products for a specified vendor, ensure that you must mention only the vendor name. For example, to add all products for Notepad++, use the following block:
  <product_category name="Notepad++">
     <vendor name="Notepad++"/>
  </product_category>
  family - (optional node) This represents a product line or categorization supported by vendor. Under each vendor tag, there can be one or many family tags. If you want to add all the products for a specified family of a vendor, ensure that you must mention the vendor name and the family name. For example, to add all products for Yahoo Messenger (Family) of Yahoo (Vendor), use the following block:
  
  <product_category name="SCCM">
     <vendor name="Microsoft">
         <family name="SCCM"/>
     </vendor>
  </product_category>
  version - (optional node) This represents a major version or release of a product family. Under each family tag, there can be one or many version tags. If you want to add all the products for a specified version of a family, ensure that you must mention the vendor name, family name, and version name. For example, to add all products for SQL Server 2012, use the following block:
  <product_category name="SQL Server 2012">
     <vendor name="Microsoft">
         <family name="SQL Server">
             <version name="SQL Server 2012"/>
         </family>
     </vendor>
  </product_category>
  product - (optional node) This represents a specific product edition or release. Under each version tag, there can be one or more produdct tags. If you want to add a specific product, ensure that you must mention the vendor name, family name, version name, and product name. For example, to add Visio 2007 MUI, use the following block:
  <product_category name="Microsoft Office Visio 2007 MUI">
     <vendor name="Microsoft">
         <family name="Office">
             <version name="Visio 2007">
                 <include_products>
                     <product name="Visio 2007 MUI"/>
                 </include_products>
             </version>
         </family>
     </vendor>
  </product_category>
  include_products - (optional node) This repesents the list of products to be included in the filter list. This tag needs to be added under version tag. You can use either include_products tag or exclude_products tag. The include_products tag is useful when only a few specific products are intended to be considered under a version. The version might have more than 100 products under it, but you want to consider only a few of them in the product category. However, when you are using this tag, then any new sub-product that is released by the vendor for the specified version is not considered for catalogs.
  For example, to add Microsoft Office Web Apps Application Server Components 2013 x64, use the following block:
  <product_category name="Microsoft Office Web Apps 2013">
     <vendor name="Microsoft">
         <family name="Office">
             <version name="Office Server 2013">
                 <include_products>
                     <product name="Microsoft Office Web Apps Application Server Components 2013 x64"/>
                 </include_products>
             </version>
         </family>
     </vendor>
  </product_category>
  exclude_products - (optional node) This repesents the list of products not to be included in the filter list. This tag needs to be added under version tag. You can use either include_products tag or exclude_products tag. The exclude_products tag is useful when only a few specific products are intended to be excluded from a version. For example, a version has 100 products under it, but you want to exclude five products from the product category. Instead of using include_products tag for 95 products, you can use exclude_products for five products. However, when you are using this tag, then any new sub-product (except the ones mentioned as part of the exclude_products tag) that is released by the vendor for the specified version is considered automatically for catalogs.
  For example, to add all products under Windows Server 2008 R2 except Windows Home Server 2011, use the following block:
  <product_category name="Microsoft Windows Server 2008">
     <vendor name="Microsoft">
         <family name="Windows">
             <version name="Windows Server 2008" />
             <version name="Windows Server 2008 R2">
                 <exclude_products>
                     <product name="Windows Home Server 2011" />
                 </exclude_products>
             </version>
         </family>
     </vendor>
  </product_category>
Use the Windows Filter Configuration File field in the Global-Configuration-parameter-list to point to the modified file.
If you no longer want to use the customized product_categories.xml file and use the default xml file, click to remove the customized file.

Important

BMC recommends that you keep a backup of the product_categories.xml file before upgrading. After you upgrade, go to the file server and manually move the product_categories.xml file located at <fileserver location>\patch\GlobalConstants to a folder outside the file server. After moving the file, download the latest file from Patch Global Configuration.

Command Priority

(Microsoft Windows only) One of the commands that TrueSight 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 consumption 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 by using the Command Priority option. This option 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.

Parameters for SuSE (SuSE Linux tab)

Parameter	Description
SuSE Service Packs List File	(SuSE Only) The location of the file containing released information of service packs from the vendor. Information contained in this file is used to prepopulate the filter selection lists found in the patch catalog wizard. If you want to add a new channel to the filter list, you must add a new suse-channels tag in the default filter file template downloaded from Patch Global Configuration. To customize the channels in the channel_categories.xml file, perform the following steps: Navigate to the Configuration > Patch Global Configuration > SuSE Linux tab. In the SuSE Service Packs List File field, click the button. Enter a name for the file to be downloaded, for example, channel_categories.xml. Important We recommend that you back up the channel_categories.xml file before upgrading. After you upgrade, go to the file server and manually move the channel_categories.xml file located at <fileserver location>\patch\GlobalConstants to a folder outside the file server. After moving the file, download the latest file from Patch Global Configuration. Customize the channels in the exported channel_categories.xml file based on your requirement. For more information about how to customize using channel_categories.xml, click the following link: Customizing the channel_categories.xml file To get available channels from SUSE, run the offline Patch Downloader utility with the following command: sh suse_downloader.sh -listChannels A list will be displayed with OS, Arch, Name, Target details. Find the details that you want to add to the filter list (for creating category). Refer to the list displayed in step 1. Customize the channel_categories.xml using the following tags: suse-channels - (Root node) This is parent node in which each OS specific filter will be added. suse-channel - This contains all the details about filters, like name, OS, architecture, service packs with level and repo name. Add a new channel tag for each arch. Specify repo type and sort order for each arch: <suse-channels> <suse-channel repo-type=”SMT” sort-order=”7”> channel-name - This represents the name you want to display in the filter list. channel-os - This represents the OS type. channel-arch - This represents the architecture for the given OS: <suse-channels> <suse-channel repo-type=”SMT” sort-order=”7”> <channel-name>Suse Enterprise Linux 11 x86</channel-name> <channel-os>SLES11</channel-os> <channel-os>x86</channel-os> <ServicePacks> ServicePacks - This represents child nodes for the service pack and related information. ServicePack - This represents SP level and repo names. SP-level - This represents the service pack levels e.g. Base, SP1, SP2, etc. repo-name - This represents the repo names applicable for the given OS, architecture and SP: <ServicePacks> <ServicePack> <SP-level>Base</SP-level> <repo-name>SLES11-Updates<repo-name> <repo-name>SLES11-Pool<repo-name> <repo-name>SLES11-Extras<repo-name> </ServicePack> <ServicePack> <SP-level>SP1</SP-level> <repo-name>SLES11-SP1-Pool<repo-name> <repo-name>SLES11-SP1-Updates<repo-name> <repo-name>SLES11-Extras<repo-name> </ServicePack> Use the SuSE Service Packs List File field in the Global-Configuration-parameter-list to point to the modified file. If you no longer want to use the customized channel_categories.xml file and use the default xml file, click to remove the customized file. Note: The format of the SuSE service packs list file is changed in TrueSight Server Automation 8.9. If you have previously customized the SuSE service packs list file and are upgrading from a version prior to TrueSight Server Automation 8.9, you must manually update the changes to the new format.

Parameter

Description

SuSE Service Packs List File

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

If you want to add a new channel to the filter list, you must add a new suse-channels tag in the default filter file template downloaded from Patch Global Configuration.

To customize the channels in the channel_categories.xml file, perform the following steps:

Navigate to the Configuration > Patch Global Configuration > SuSE Linux tab.
In the SuSE Service Packs List File field, click the button. Enter a name for the file to be downloaded, for example, channel_categories.xml.
Important
We recommend that you back up the channel_categories.xml file before upgrading. After you upgrade, go to the file server and manually move the channel_categories.xml file located at <fileserver location>\patch\GlobalConstants to a folder outside the file server. After moving the file, download the latest file from Patch Global Configuration.
Customize the channels in the exported channel_categories.xml file based on your requirement. For more information about how to customize using channel_categories.xml, click the following link:
Customizing the channel_categories.xml file
1. To get available channels from SUSE, run the offline Patch Downloader utility with the following command:
  
  sh suse_downloader.sh -listChannels
  
  A list will be displayed with OS, Arch, Name, Target details.
2. Find the details that you want to add to the filter list (for creating category). Refer to the list displayed in step 1.
3. Customize the channel_categories.xml using the following tags:
1. suse-channels - (Root node) This is parent node in which each OS specific filter will be added.
  suse-channel - This contains all the details about filters, like name, OS, architecture, service packs with level and repo name. Add a new channel tag for each arch. Specify repo type and sort order for each arch:
  <suse-channels>
  <suse-channel repo-type=”SMT” sort-order=”7”>
1. channel-name - This represents the name you want to display in the filter list.
  channel-os - This represents the OS type.
  channel-arch - This represents the architecture for the given OS:
  <suse-channels>
     <suse-channel repo-type=”SMT” sort-order=”7”>
         <channel-name>Suse Enterprise Linux 11 x86</channel-name>
         <channel-os>SLES11</channel-os>
         <channel-os>x86</channel-os>
             <ServicePacks>
1. ServicePacks - This represents child nodes for the service pack and related information.
  ServicePack - This represents SP level and repo names.
  SP-level - This represents the service pack levels e.g. Base, SP1, SP2, etc.
  repo-name - This represents the repo names applicable for the given OS, architecture and SP:
  <ServicePacks>
     <ServicePack>
         <SP-level>Base</SP-level>
         <repo-name>SLES11-Updates<repo-name>
         <repo-name>SLES11-Pool<repo-name>
         <repo-name>SLES11-Extras<repo-name>
     </ServicePack>
     <ServicePack>
         <SP-level>SP1</SP-level>
         <repo-name>SLES11-SP1-Pool<repo-name>
         <repo-name>SLES11-SP1-Updates<repo-name>
         <repo-name>SLES11-Extras<repo-name>
     </ServicePack>
Use the SuSE Service Packs List File field in the Global-Configuration-parameter-list to point to the modified file.
If you no longer want to use the customized channel_categories.xml file and use the default xml file, click to remove the customized file.

Note: The format of the SuSE service packs list file is changed in TrueSight Server Automation 8.9. If you have previously customized the SuSE service packs list file and are upgrading from a version prior to TrueSight Server Automation 8.9, you must manually update the changes to the new format.

Parameters for AIX (AIX tab)

Parameter	Description
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. To specify the customized or default filter file to be used, do the following: Click and browse to the location on the server where the customized file is available, and click OK. The path of the selected file is displayed. Click to remove the path of the customized file. If you do not specify any customized filter file, the default file is used. Click to export the available filter file (customized or default) to the selected server in the server group. When you upgrade to TrueSight Server Automation 21.02, the existing custom file (if available in the depot) is copied to a temporary location on the File Server, and the existing depot file path is replaced with the new file path on the File Server.
Analysis Option	(AIX Only) Select one of the following choices: 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 — The state of all currently installed filesets is changed 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.

Parameters for Amazon Linux, CentOS, and OL ULN (Generic RPM Linux tab)

Parameter	Description
Generic RPM Linux Channel Filters List File (Available under the Common tab)	Use this XML file to customize the Amazon Linux, CentOS, or Oracle Linux child channel filter list that is displayed while creating an online catalog. You can add or modify this file to add additional Amazon Linux, CentOS, or Oracle Linux child channel filters in the list. Note: If you modify a URL for an existing channel, the URL is not updated for the catalog that already uses this channel. To use the new URL, delete the filter (channel) from the catalog and add the same channel again.
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 TrueSight 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 TrueSight Server Automation Console; conversely, setting a higher default value slows down analysis but consumes fewer resources. After you set this value, do not change it unless specifically required.
Action on Failure	The action that TrueSight 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 by 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.
Yum process priority (nice value)	Set the priority of a process. The default value is 0. You can set the value within range -20 to 19. This range limits denote: -20: Process has high priority and gets more resources, thus slowing down other processes. 19: Process has lower priority and runs slowly by itself, but has less impact on the performance of other running processes.
Patch deploy success return codes	The Deploy Job sends commands to the OS which in turn sends responses back to TrueSight 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 TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight 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 TrueSight 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 TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight 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 TrueSight Server Automation. In most cases, standard warnings are used; occasionally, the OS uses a return code not known to TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight 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 TrueSight Server Automation. In most cases, standard commands are used; occasionally, the OS uses a return code not known to TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight Server Automation as reboot return codes.

Parameters for Oracle Linux (Oracle Linux - Public Repo tab)

Parameter	Description
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 TrueSight 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 TrueSight Server Automation Console; conversely, setting a higher default value slows down analysis but consumes fewer resources. After you set this value, do not change it unless specifically required.
Action on Failure	The action that TrueSight 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 by 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.
Patch deploy success return codes	The Deploy Job sends commands to the OS which in turn sends responses back to TrueSight 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 TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight 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 TrueSight 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 TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight 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 TrueSight Server Automation. In most cases, standard warnings are used; occasionally, the OS uses a return code not known to TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight 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 TrueSight Server Automation. In most cases, standard commands are used; occasionally, the OS uses a return code not known to TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight Server Automation as reboot return codes.

Common parameters in the platforms

Parameter	Description
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 TrueSight 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 TrueSight Server Automation Console; conversely, setting a higher default value slows down analysis but consumes fewer resources. After you set this value, do not change it unless specifically required.
Action on Failure	The action that TrueSight 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 by 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.
HTTP/HTTPS/FTP Connection Retry	(Windows, Solaris, Red Hat Linux, SuSE, and AIX) The number of attempts made before reporting failure if TrueSight 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 TrueSight Server Automation waits before making another attempt to connect to the vendor site.
Patch deploy success return codes	The Deploy Job sends commands to the OS which in turn sends responses back to TrueSight 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 TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight 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 TrueSight 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 TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight 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 TrueSight Server Automation. In most cases, standard warnings are used; occasionally, the OS uses a return code not known to TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight 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 TrueSight Server Automation. In most cases, standard commands are used; occasionally, the OS uses a return code not known to TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight 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 TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight 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 TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight 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 TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight 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 TrueSight Server Automation. In most cases, standard commands are used; occasionally, the OS uses a return code not known to TrueSight Server Automation. Unknown codes entered in this field are defined to TrueSight Server Automation as reboot return codes
Debian Linux Updates List File	(Ubuntu and Debian Only) The location of the file containing information for Version, Base URL, Distribution, Component, and Architecture. Information contained in this file is used to prepopulate the filters in the distributions tree view found in the patch catalog wizard. See Patch-catalog-Ubuntu-Catalog or Patch-catalog-Debian-Catalog for more information about the distributions tree view.

Options on the yum.conf tab for Red Hat Enterprise Linux, Oracle Enterprise Linux, Generic RPM Linux, and SUSE Linux Enterprise servers

On the yum.conf tab, perform either of the following actions:

Select the Use Default check box if you want to use a yum.conf file with default settings provided with TrueSight Server Automation.

Deselect the Use Default check box if you want to use a custom yum.conf file. You can customize the yum.conf file to configure the different patch analysis and deployment parameters. Your desired entries should be added in the text box provided.

Click here to see a sample of a yum.conf file.

Example of a yum.conf file:
[main]
debuglevel=4
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=RedHat-release
tolerant=1
obsoletes=1
plugins=0
gpgcheck=0
bootloader=1

Note

The system default /etc/yum.conf file is not used in either case.

In addition to the options listed in the sample yum.conf above, if you want to avoid the removal of old RPMs during patch analysis when a native yum is used, you can include the installonly_limit option in the yum.conf file. For more information, see the description of this issue in Troubleshooting-Patch-Management-issues.

For more information about all the options that you can include in the yum.conf file, see the yum.conf man page.

You can also customize the yum.conf file when you create a Patching Job. For more information, see Patching-Job-Analysis-Options-for-Red-Hat-Enterprise-Linux-Oracle-Enterprise-Linux-and-SUSE-Linux-Enterprise.

Parameters on the Shavlik URL Configuration tab

The Shavlik URL Configuration tab provides information about the configuration file that is used for downloading patch metadata for Microsoft Windows.

NEW IN 21.02 partner.manifest.xml — URLs to download patch metadata are used from the following properties in this XML file: OEMCATALOGWPD and WINDOWSPATCHDATA

OEMCATALOGWPD — This download path contains the file that is required by the Application Server to decrypt metadata files
WINDOWSPATCHDATA — This download path contains the file that is required for the Windows patch analysis and packaging information

The following table lists the fields that are available for configuring the Shavlik files. To edit the details, select the file and click Edit Patch Configuration File.

Where to go from here

Ensure that you have completed all tasks listed in Preparatory-tasks-for-patch-management.