How does the setting "Delete package files if they are unused for..." work?

Products

• IT Management Suite

Issue/Introduction

Recently you had some questions regarding the "Delete package files if they are unused for..." setting and how this process works. The following contains some information around this area.

Resolution

There are a few other KBs (applicable since NS 6 version) that are still applicable including:

• 178503 "How does a Package Server determine when to delete a package?"
• 181052 "What does the “Delete Package files if unused on the Package Server” setting do?"

 

How are packages distributed to a Package Server (PS)?

Each package is automatically distributed to package servers as you define them.  The distribution options are configured on a per-package basis with the following options (or you can select no distribution at all):

A)      Automatically distribute to all Package Servers (default)

B)      Distribute to manually selected Package Servers.

C)      Auto-distribution with manual prestaging.

 

When are packages sent to Package Servers?

Packages are not actually "always" sent to package servers but are only sent when needed.  This saves space on the PS as well as reduces the use of bandwidth.  A package is auto-assigned and then sent to a PS in the following situations:

1)      The package is used by a legacy SWD policy assigned to a client located at the same site where the PS is present.

2)      The package is requested by a client from the same site and no suitable codebases are located for this package.  (This case should cover situations when any task (eg DS) is making Altiris Agent request a package.)

 

After this, the following settings begin to take effect:

The first option (Remove automatic site assignments if they are unused) specifies how long the package is assigned to the Site Server, and it is OFF by default.

The second option (Delete package files if they are unused) specifies how long the physical files for the package remain on the package server's directory structure.  Once no policies are assigned, and no tasks assigned, the clock "begins" for the removal of a package.  Any assignment resets this clock.  After the specified time, the package will be removed from the package server until requested again (scenario #2 above).

In addition to the auto-assign scenarios above, Option 1 can be triggered by any item which has the correct association with a package and is enabled and assigned to resources via a resource target where the assignment is registered in the normal fashion. Specifically, a software delivery task that is assigned to a resource target can trigger option 1 if the timing occurs correctly.

 

Unique Scenarios & Work-arounds:
There are a few situations that may require unique handling of packages that are worth mentioning:

• Some packages you may want to always be available on package servers.  A great example of this is Deployment Solution images, which are very large, and you more than likely would not want to replicate in real-time over even moderately slow links.  Especially not multiple times!  In these scenarios, each package has its own "override" the settings displayed above.  You can set Deployment and "similar" packages to "Never Delete" in the package definition itself.
• Some packages may need to be prestaged long in advance for an unspecified time.  One way to manage this is to build a policy for the package and schedule delivery out to a distant time, maybe a year in the future.  This will ensure replication to the PS happens, and the package is kept for a while.  Then, when you're ready for the actual roll-out, create a new policy, or task.  When you are finally done, cancel the long-term policy, and let it clear off of the package servers.