Package Server packages repeatedly re-download from an alternate location after reaching Ready because package files are being deleted externally

Products

IT Management Suite

Issue/Introduction

Package Server-hosted packages may repeatedly move between Ready, Download Pending, and Retrying Download even though the downloads complete successfully. In some cases, the package appears Ready in the console while the expected files are missing from the physical package location. HTTP is the primary source location provided for these packages.

This behavior is commonly seen when packages are stored in an alternate Package Server (PS) location and a third-party script or process deletes package files outside normal Package Server cleanup logic.

Environment

ITMS 8.7.x, 8.8.x

Some other elements:

Package Server
Packages configured with "Use alternate download location on Package Server"
Alternate path stored on a local path or an existing share such as \\%COMPUTERNAME%\Share\...
Environments where custom scripts or third-party tools also access the same physical package path

Cause

This issue is not necessarily a package download failure. In the reviewed issue, Package Server successfully downloaded the package content, but kept re-downloading the packages.

In this particular scenario, a customer-created script was deleting the physical package files from the Package Server’s alternate package location after the package had downloaded successfully. This caused Package Server to repeatedly download the same package again.

Related product behavior to understand:

Package cleanup on a Package Server starts only after the package is unassigned or deleted from the NS database, which updates PackageStatus.xml to Deleted.
Alternate-location packages still rely on snapshots and metadata under the default Altiris Agent path.
If permissions to the alternate share/path are incorrect, packages may also fail to download properly.

Visual Reference — Full Process Flow

Architecture diagram of the ITMS package distribution pipeline

This diagram reflects the process described in the main Use Case: package metadata originates on the SMP Server (NS Server), Package Servers receive package definitions and snapshots, content downloads in blocks over HTTP, content may be stored in an alternate local/UNC-backed location, and package state is tracked by PackageStatus metadata.

Resolution

The following is provided as suggestions on what to look for and verify.

Main control points in the pipeline

Control point	What the example case shows	Product behavior tied to it
Snapshot / package metadata	Re-downloads happen when package is considered changed	Package versioning and snapshot handling are core Package Server behaviors; also package snapshot handling for alternate locations.
Download method	Package blocks are downloaded over HTTP	The case logs show block-level HTTP retrieval.
Alternate location	Customer used `\\%COMPUTERNAME%\Share\...` mapped to a physical path	Broadcom documents that a non-default Package Server location can be a local path or an existing shared folder and that Package Server does not create the share for you.
Ready / Deleted tracking	“Ready” state could exist while physical files were missing	Cleanup state is tracked through PackageStatus.xml and evaluated during refresh.
Cleanup logic	Customer tested deletion of package files from alternate location	Ccleanup starts after package deletion or unassignment, then PackageStatus.xml is marked `Deleted`, and cleanup occurs on refresh after the configured period.

Step 1: Confirm whether the package is actually re-downloading or failing to finish

Review Package Server package history and logs to confirm whether the package reaches 100% and becomes Ready before returning to Download Pending. In the reviewed case, the package completed, then later re-entered the download cycle.

Recommended evidence

Package Server UI history
Package Delivery logs
PackageStatus.xml
snapshot.xml

Step 2: Verify whether the physical files exist at the alternate package path

Compare the package path recorded in snapshot.xml with the physical file system on the Package Server.

Expected

Files listed in the package snapshot exist on disk.

Actual in the reviewed case

Package was shown as Ready, but the folder referenced in the snapshot did not exist on disk.

Screenshot of Package Server UI showing Ready state and a matching file system view showing missing files

Step 3: Check for external file deletion or modification

Investigate any scheduled task, PowerShell script, GSS job, antivirus action, or custom automation that can delete or modify files under the alternate package location.

Important
Package Server cleanup is through PackageStatus.xml and refresh logic. If a third-party process deletes files directly, that bypasses normal Package Server state tracking and can create repeated re-download behavior.

Step 4: Collect multiple snapshot versions of the same package

If the cause is not yet confirmed, collect the same package’s snapshot.xml from at least two different times covering one re-download cycle.

Check for:

Snapshot version increases
File hash changes
Package path changes

This was the recommended engineering method in the reviewed case to distinguish real package change from external file removal.

Step 5: Validate the alternate location and permissions

For packages using an alternate location such as \\%COMPUTERNAME%\Share\..., confirm:

The folder exists
The path is shared when UNC is expected
The Altiris Agent / Package Server account has read, write, and modify rights

If the share does not exist or is not usable, the package may not download correctly, and KB Package Server is unable to download packages from NS shows a real example where insufficient rights to the alternate share/path blocked package download.

Step 6: Review package deletion settings

On the Package Server settings (under SMP Console > Settings > Notification Server > Site Server Settings > Site Server Settings > Package Service), review:

Delete package files if they are unused for
Any registry customizations affecting cleanup interval

Package cleanup begins after the package is removed from configuration and PackageStatus.xml is updated to Deleted; cleanup is then evaluated during Package Server refresh.

Step 7: Do not remove internal Package Server metadata files manually

Do not manually delete:

Package Delivery metadata folders
Package Server Agent\Package Status metadata folders
package snapshot metadata

These metadata locations are part of Package Server’s cleanup and state tracking behavior. We use PackageStatus.xml as part of the deletion workflow.

Diagnostic locations

Item	Path / source	Why it matters
Package status metadata	`C:\Program Files\Altiris\Altiris Agent\Package Server Agent\Package Status`	Contains `PackageStatus.xml`, including deleted-state tracking documented by Broadcom.
Package snapshot metadata	Default Altiris Agent install path	Broadcom states alternate-location package snapshots remain under the default Altiris Agent location.
Alternate package content	Customer-defined share or local folder	Confirms whether files actually exist on disk.
Package delivery logs	Package Server / Altiris Agent logs	Shows whether the package is progressing normally, retrying individual blocks, or restarting later.