Unexpected Deletion of Software Delivery Packages from custom location
search cancel

Unexpected Deletion of Software Delivery Packages from custom location

book

Article ID: 413372

calendar_today

Updated On:

Products

IT Management Suite

Issue/Introduction

You may experience unexpected file(s) deletion of Software Delivery (SWD) packages shortly after they have been downloaded by the Symantec Management Agent (SMA). This issue is observed when multiple SWD packages are configured to download to the same custom location, such as C:\temp, leading to conflicts during the package cleanup process.

This seems to be intermittent: seeing package showing as successfully delivered but they aren't going through correctly. The package files appear, and then disappear immediately at the end.

The only clue noticed when the package files are deleted is the following agent log entries are present at that time:

Cleanup expired packages started: deleteAsynchCompletion = false, TreatFailedMdpAsActive = false
-----------------------------------------------------------------------------------------------------
Date: 9/9/2025 8:17:33 AM, Tick Count: 642497392 (7.10:28:17.3920000), Size: 334 B
Process: AeXNSAgent.exe (4252), Thread ID: 968, Module: smfagent.dll
Priority: 4, Source: CleanupExpiredPackages

Deleting inactive package '{DEB4A922-999E-422F-B40E-DF69A416C567}

-----------------------------------------------------------------------------------------------------
Date: 9/10/2025 1:48:48 PM, Tick Count: 748769204 (8.15:59:29.2040000), Size: 307 B
Process: AeXNSAgent.exe (4252), Thread ID: 968, Module: smfagent.dll
Priority: 4, Source: CleanupExpiredPackages

In this example, package GUID "DEB4A922-999E-422F-B40E-DF69A416C567" is from a package that doesn't longer exists on the SMP Server. However, it is not the actual Package GUID for the affected package that gets its files deleted.

Environment

ITMS 8.7.x, 8.8

Cause

This recurring package cleanup is a result of an inconsistent state between the package's actual content on the client machine and the internal package management logic on the agent. The core issue arises when a package's designated custom folder still contains some content (even a small amount) after the initial cleanup.

The current product behavior is the limited support for 'sharing' or re-using custom package folders between different packages, or using a pre-existing, non-empty folder as the custom package folder. When these scenarios occur in ITMS 8.8 and earlier, the agent's internal logic continuously finds residual files and interprets this as a partially managed, un-deleted package, triggering repeated cleanup attempts until a full policy update occurs.

This issue primarily affects environments using Symantec Management Agent (SMA) for software delivery, particularly when custom download locations are configured for packages.

The underlying cause is a complex interaction between the agent's package management logic and product limitations regarding custom package folders.
The package cleanup behavior is rooted in two key factors:

  • Product Limitation: The ITMS Software Management solution does not support the following configurations:

    • Sharing a custom package folder between two or more distinct software packages.

    • Defining a pre-existing folder that already contains content as the custom package folder.

The unexpected deletion of SWD packages is not a defect but rather a result of misconfiguration in how packages are managed and deployed. The following factors contribute to this issue:

  • Conflicting Download Locations: When multiple SWD packages, especially those with overlapping content (e.g., common folder names like "Repository" or "Build"), are configured to download to the same custom location (e.g., C:\temp), conflicts arise. The Package Cleanup process may incorrectly identify active package contents as inactive, leading to their deletion.
  • Package Cleanup Process: The Package Cleanup process is designed to remove inactive or expired packages. However, when packages share a common download directory, the cleanup process may delete files belonging to an active package if another package, also residing in the same directory, is deemed inactive or expired.
  • Lack of Unique Subfolders: If packages are constructed without unique subfolders for their contents within a custom download location, files from different packages can become intermingled. This increases the likelihood of deletion conflicts, extra hash re-validation, constant re-downloading, and the use of incorrect files during package execution.
  • "Old" Package References: In some cases, "old" packages without associated policies or tasks can still have entries in the database and occupy space in shared custom download locations, contributing to cleanup ambiguities. For example, package {DEB4A922-999E-422F-B40E-DF69A416C567} was found to exist in C:\temp without active policies, conflicting with {52B55336-8646-40BE-A944-1FF37117D5C3}.
  • Agent Log Entries: Agent logs show "Deleting inactive package" entries for packages flagged as no longer needed or requested by client machines, even if their contents overlap with active packages in shared directories.

Resolution

The Broadcom Development team is currently reviewing a possible issue concerning the unexpected deletion of software delivery packages. The aim is to address the deletion behavior, specifically with "Deleting inactive package" for "gone/orphan" packages, to prevent the unintended removal of overlapping files.

 

To resolve and prevent the unexpected deletion of Software Delivery packages, follow these recommendations:

  1. Use Unique Custom Download Locations:
    • Recommendation: Strongly advise using unique subfolders for each Software Delivery package. Instead of C:\Temp, use a path like C:\Temp\Software1\ or C:\Temp\Package1\.
    • Configuration: When configuring packages in Global Managed Delivered Package (MDP) Settings (Settings -> Software > Managed Delivery Settings > Download tab) and for Package Delivery and Quick Delivery tasks, ensure that custom target folders are different for each package.



  2. Isolate Packages in Use:
    • If a specific package is actively in use by an NS admin, isolate it by specifying another custom download location that is not shared with other packages.
  3. Review and Update Policies/Tasks for Conflicting Packages:
    • Identify policies/tasks encapsulating packages like {DEB4A922-999E-422F-B40E-DF69A416C567} that currently specify a conflicting custom target folder. Update these policies to ensure the custom target folder is DIFFERENT from other packages.
    • For packages that are "old" or no longer have associated policies/tasks on the client side but still reference a shared C:\temp destination, consider removing any remaining database entries if they are truly orphaned.

Temporary Workaround (if immediate resolution is needed):

  • On the client machine, delete the software delivery folder (C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\Software Delivery) and restarts the Symantec Management Agent service, until the recommended unique folder configurations are fully implemented.

 

Powered by Wolken Software