Software Delivery job fails with error that package has been tampered with.
book
Article ID: 49972
calendar_today
Updated On:
Products
CA Automation Suite for Data Centers - Configuration AutomationCA Client Automation - Asset ManagementCA Client Automation - IT Client ManagerCA Client AutomationCA Client Automation - Remote ControlCA Client Automation - Asset IntelligenceCA Client Automation - Desktop Migration ManagerCA Client Automation - Patch ManagerCA 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:
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>
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.