After migrating to a new SMP server, the snapshot and snapdata files are not updated on Package Servers.

Products

• IT Management Suite

Issue/Introduction

You have noticed that for some old packages, clients fail to download the package, as the signature is invalid.
You have migrated your package servers to a new SMP server.

If you delete this affected package on the affected Package Server, it would re-download the package with correct data and clients will have no issues further.

Environment

ITMS 8.1, 8.5, 8.6

Cause

When Package Server (PS) checks with Symantec Management Platform (SMP) for package verification/integrity - it's validating the Hash and version and they all match. Thus it would set the package as Ready and valid.

When the client is requesting a package - it would receive a signature from SMP - and when validating the signature - they would not match.

Looks like in the customer situation this is what is happening: the package server has downloaded the package from their previous SMP server, stored the legacy SMP server key for validation. After that, it was reassigned to the new NSMP server, but since the package has not changed, it validates it with the stored key and does not download anything.

 

Resolution

Changes have been made with our ITMS 8.6 RU2 release to handle.

Before ITMS 8.6 RU2:

this was the behavior regarding package signatures and the integrity check:

When the package server downloads the package from the SMP server, it stores (in the agent's secure storage (c:\programdata\symantec\symantec agent\LDB folder)) the public key it receives from the SMP server to validate the snapshot. Later when snapshot validation is requested, this key is used to validate it. Thus if the package server will download the package from some other SMP Server (Child package server download from Parent SMP server), the package service will be able to validate the package snapshot. And if nothing in the package has changed, then integrity check will not download anything and check the integrity based on locally available data, including the key for snapshot validation.

Post ITMS 8.6 RU2:

We'd implement the code changes to invalidate the snapshot.xml (to automatically trigger redownload) if/when a package server is re-assigned to the new SMP server. 

The Source Key will be reset when the scheduled package update is triggered, or when user action "Check Integrity" is initiated on a package. This will force the package to become invalid and be queued for download. The download will re-download the snapshot with the new key from the new SMP server and check existing binaries according to the new snapshot.