Software Delivery job fails with error that package has been tampered with.

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
• CA Server Automation

Issue/Introduction

Description:

Problem

• Particular package fails consistently with following error:
• "This package has consistency check enabled and has been tampered with at the server. [SDM228429]"
• This happens regardless of the scalability server that the agent receiving the package reports to.
• Restaging the package does not help.
  
  

Environment

• CA Client Automation r12.5
• CA IT Client Manager r12.5, r12.0 SP1, r12.0
• CA Software Delivery r12.5, r12.0 SP1, r12.0
  
  

Cause

• When a package is registered into ITCM, we create a checksum based on the number, names and size of the contained files. When a package is being deployed, the checksum is calculated again and compared with the number calculated during registration. If the two do not match, the "tampered with" error is generated. So it basically means that somebody/something changed the package after registration.
  
  

Solution:

1. If you are sure this is not the case, you could disable this check:
   
   Go to the package properties on the ITCM Explorer and uncheck "Checksum control of package consistency". Click OK. Then deploy the software package again and the error will no longer show up.
   
   

   <Please see attached file for image>

   
   
   
2. If you do not like to disable checksum control, consider the following:
   
   If you have NOS agents, they install directly from the share (rather than first copy the package to the local hard drive) and with a symbolic link/junction point to the actual source (being only a pointer rather than a complete copy of the installation package), the installation procedure could change the source of the package.
   
   You can disable symbolic links to overcome this problem: when a job container is built, the package is copied to the scalability server's activate area which the target connects to. Since the installation process now no longer runs on the actual package, but on a copy of it, there is no chance the procedure is able to modify it in any way.
   
   You can disable the feature from configuration policy:
   
   DSM > Software Delivery > Shared > Software Library access: Use symbolic links -> false (default is true).
   
   

   <Please see attached file for image>

   
   
   The only downside of this is that building the container will take slightly longer as the package will need to be copied over to the activate area rather than just setting a pointer.

Environment

Release: UASIT.99000-12.5-Asset Intelligence
Component: