What you can do, is to "pre-stage" so to speak, the package - that's most often done with a multicast job (this is the sort of scenario that the "multicast only" delivery method is for). This will get the files down to the clients (or at least the vast majority of them), and you can then - separately - run the actual install job.
As for your other question - yes - LANDesk has byte-level checkpoint restart technology. So if you yank out the network cable, and then plug it back in (and the job gets picked up again / the policy runs again), we will continue downloading the files where they left off (as the quick answer) - this option is on by default, you don't need to do anything for it .
"Run from source" is a special case in that it actually executes the installer (or whatever it is) from the network path, no copying takes place.
Hope this helps.
- Paul Hoffmann
LANDesk EMEA Technical Lead
I just tried a Policy Supported Push using Multicast and I think this is what I was looking for. At least my test worked as expected.
The staging you mention using the multicast only delivery...This must require a second scheduled task to run the actual install much like Stage and Repair from within Security and Patch Manager. What part of the install task tells the client to install from its cached copy? Or is checking for a cached copy done by default for any package install? Can the install task then be any delivery method since the package has already been delivered? Even Run from Source?
This happens automatically.
Here's how LANDesk's software distribution agent operates (unless you use "run from source" - that's the only exception) :
Step 0 - download the list of files/hashes that the client will need for the software package.
Step 1 - check "do I have (some/all of) these files in my local cache?"
If all the files are present, the install begins.
If some of the files are present, the missing files will be downloaded (using the below prioritisations).
Step 2 - Check "does any other client in my local network have these files in their cache" -- this is peer download in action.
If everything can be gotten from local clients, the files are copied down, and
Step 3 - If no client in the subnet has the files / if files are still missing, we'll go to the "package source" to get the files from there.
Once all the files are on the client, the install starts.
So you see, LANDesk's client will - (nearly) always - check first of all his local cache for the files being present, this does not require additional UI options - if you've pre-staged the files through multicasting, you'll have this sorted for you .
NOTE - this is a somewhat simplified approach, as I didn't include logic for preferred package servers / bandwidth aware download, it's just to put down the principles of software distribution somewhat more plainly in sight, I hope .
ADDENDUM - it should be noted that this applies to "any" method of starting the software. So this "check local cache" option will work with policies just as well as "push" type tasks. The method in which you get to tell the client "go forth and do this" doesn't matter (i.e. push vs pull).
- Paiul Hoffmann
LANDesk EMEA Technical Lead
Message was edited by: Paul Hoffmann
Thanks for the info and clarification. This will get me on my way.