If a file is modified on a Package Server (in the Package Delivery folder, where the packages are cached), for example it is infected by a virus or later cleaned by the anti-virus, the executable file may not change in size but differ only on the file timestamp (last modified date).
This is known to be true for infected files that were cleaned by Trend Micro antivirus. This process of removing the antivirus however, also causes the executable to become invalid.
However when the Package Server verifies the local cache against the snapshot it looks at the file name, file size and last modified date. If only the last modified date (timestamp) has changed the file will not be downloaded again, as shown here:
Transcript: Some downloaded files have timestamps that do not match the snapshot. The timestamps on these files will be changed to match the snapshot, to prevent excessive network activity.
In the case of files modified and corrupted by a virus and anti-virus clean up, this means we will not replace the local (invalid) file with the valid version available on the server and that we'll remove all means of detecting the incorrect files for a manual clean up later on.
This means that to recover from invalid executable files in Package Server the customer would have to either get a list of failed executables (waiting for software update tasks or software delivery tasks to fail and report status to the NS) or clean all executable files on the Package Delivery folder.
The affected file is "AeXPackageDelivery.dll" which resides under the "%programfiles%\Common Files\Altiris" folder. As the path indicates this file is shared and used equally by the Altiris Agent (Software Delivery agent in effect) and Package Server Agent.
The behaviour encountered can appear to be incorrect on Package Servers but it was implemented to resolve problems when the file timestamp was changes by intermediate servers (modified by IIS or during package download via UNC on the package servers).
A solution has been found by enginerring to accomodate both behaviour:
- To avoid continous redownload of files by clients because of modified timestamps on the package server
- To ensure the files with a modified timestamps are downloaded afresh on the package server.
It is currently under tests in production environment and awaiting final validation.
Notification Server 6.0.6073 (SP3) with R11 (TECH41280).
Logged in Etrack (Symantec) database