Download Failed in Baseline

Usage and Config Platform
1

Hi folks,

For the past few weeks I’ve been dealing with very nagging issue

I have a baseline with a lot of components in it ~150.
The baseline is automated to work with site subscription. When a device subscribe to a specific site it triggers the baseline.
The purpose of the baseline is to install packages to newly reimaged systems.

The problem is, when the baseline is running, sometimes i see packages which are failing to download .

It is on random principle, random packages on random devices.
as I mentioned the baseline has a lot of components, and 2 or 3 are failing with Download Failed.

I’ve increased the relay download cache to be 2x the size of the bassline but still no joy.

If i resend the packages as single actions they install properly without any issues.

Within the client logs sometimes i see the following, but not always

At 09:40:23 -0700 -
ActionLogMessage: (action:720421) Action signature verified for Execution
ActionLogMessage: (action:720421) MoveFiles before running action failed
ActionLogMessage: (group:720421,action720435) DownloadJobFailed
ActionLogMessage: (group:720421,action720435) ending sub action

Here’s a quick summary of what we were able to figure out that this is NOT related and caused by the following below :

-The problem is also not related to the communication of the client machines from their parent relays because the targeted machines were able to download the other files for other packages on the same baseline

-The problem is also not caused by the file not being available from the relay download cache because other machines were able to download it but could be related to the file not being available at the moment that the affected machines are downloading it.

Has anyone experienced a similar issue before ?

1 Like
2

The “MoveFiles Failed” usually means the __Download folder is locked and cannot be emptied. The contents of the folder are deleted before copying over the downloads for a new action.

What this usually means is that an earlier action, probably something in the Baseline, either executed with ‘run’ or ‘runhidden’, or otherwise spawned a new child process and did not wait for that process to complete before running the next action.

Because an executable in that directory is still running, the __Download folder can’t be emptied to allow the next action to process it’s downloads.

Look to the tasks in your baseline that ran before the components that give the download failed statuses.

3 Likes