Software Signature Discovery is Failing due to a Corrupt Signature XML File when using the Content Utility to Import Software Signatures from another DSM Manager.

Products

• CA Automation Suite for Data Centers - Configuration Automation
• CA Client Automation - Asset Management
• CA Client Automation - IT Client Manager
• CA Client Automation
• CA Client Automation - Remote Control
• CA Client Automation - Asset Intelligence
• CA Client Automation - Desktop Migration Manager
• CA Client Automation - Patch Manager

Issue/Introduction

In an environment where the ContentUtility.exe is used to propagate software signatures from one DSM Manager to another, it's possible, if the ContentUtility.exe is not invoked correctly, to cause corruption in the ca_software_signature table on the import MDB.

Here is an example where corruption is observed in the MDB, denoted by the '&%n&%' characters seen in some records:

<Please see attached file for image>

Generically, you can run this SELECT statement to check for any affected records:

select * from ca_software_signature where signature_data like '%>&%%n&%%<%'

The presence of these characters in the ca_software_signature table will result in a corrupt/malformed signature XML file for software discovery. You can verify this by invoking the amswsigscan.exe process manually, in debug mode:

<Please see attached file for image>

Environment

Client Automation (ITCM) -- any versions.

Cause

When Intellisig software discovery was added to the product in the ITCM r12.5 SP1 FP1 release, this introduced some changes in ContentUtility.exe for handling Intellisig content. If the ContentUtility.exe process is not used carefully, it could result in the corruption described above.

ContentUtility.exe can be invoked to export/import specific types of software content data based two configurations:

1. The content_utility.xml file is used to configure the export and/or import operations.
2. A series of command line switches are passed to the ContentUtility.exe process to configure the export and/or import operations.

The special characters are introduced in the export operation of the Content Utility when the following line is set in the XML file:

<intellisig_detail>yes</intellisig_detail>

Or when the ContentUtility.exe is passed the following switch when invoked via CLI:

/INTELLISIGDETAIL YES

It is 100% expected to observe the special characters, '&%n&%', in the 'ca_software_signature' flat file generated by the ContentUtility export operation! Again, these characters will be written to the flat file when the intellisig detail option is specified.

In order to avoid corrupting your ca_software_signature table, the import operation MUST have a matching intellisig detail option set! Corruption is introduced in the following scenarios:

• When using the content_utility.xml file, specifying "<intellisig_detail>yes</intellisig_detail>"for the export operation, but specifying the opposite for the import operation, "<intellisig_detail>no</intellisig_detail>".
• When invoking ContentUtility.exe via CLI, specifying "/INTELLISIGDETAIL YES" for the export operation, but forgetting to specify " /INTELLISIGDETAIL YES" during the import operation. By default "/INTELLISIGDETAIL NO" is assumed by the ContentUtility.exe process if the switch is not explicitly specified.
• When using the content_utility.xml file, specifying "<intellisig_detail>yes</intellisig_detail>", but invoking the import operation via CLI, and not specifying the "/INTELLISIGDETAIL YES" switch.

In some scenarios, the export and import operations may not occur during the same execution of the ContentUtility.exe process. For example, one execution performs the export operation, and some other execution performs the import operation later. Careful consideration must be taken around the intellisig detail option to ensure ca_software_signature is not corrupted on import.

Resolution

If the ca_software_signature table has become corrupted, use the following process to fix it:

1. On the MDB that is corrupted, run the following in SQL to purge the ca_software_signature table:
   truncate table ca_software_signature;
2. Invoke the ContentUtility.exe correctly, as described in the section above. Ensure the intellisig detail option is set properly, so the special characters will be handled on import.
3. After the import is successful in recreating the ca_software_signature table, each scalability server must be validated by the engine to generate a new signature ZML file.
4. After an SS is updated with the latest signature ZML file, each AM agent execution thereafter will download the latest signature ZML, expand it to a signature XML, and report a healthy software signature scan using the new XML file.