You're working off an incorrect assumption - that clients only start their job once the MDR has finished.
That is not the case.
The MDR begins to transfer its package at the same rate at which it receives it - so the subnet's clients get it (figuratively speaking) in "real time" when compared to the MDR. The MDR does NOT wait first to have 100% of a package (or file) before beginning to multicast.
What you CAN do is split the job into two, if you want.
job 1 - (say 22:00 pm) - multicast (cache-only) your package to your MDR's.
job 2 - (say 02:00 am) - push/multicast the same package to your subnets. You can use more aggressive timings here.
The MDR's, having already (hopefully) 100% of the package, can begin transmitting/multicasting at a faster rate right away. Though the difference is not that great, really (all you do is improve the time in which the clients get their package - the MDR still needs to wait for the trickle-download).
Hope this answers your question.
LANDesk EMEA Technical Lead.
Have you tried using the "limit remote downloads to one per subnet" option instead of multicast? I know of many customers that have always used multicast and switched to this method because it worked better for them in slow WAN environments. Other than that, the suggestion to do a multipart task (stage, then install) is probably your best bet.
I mention this alternate method, because there is usually a misunderstanding of how a Multicast job to multiple WANS actually works. It is assumed that the files are being Multicast to the MDRs when in fact it is Unicast to the MDR from the source and then multicast on the local subnet.
1. Multicast: phoffmann has some good advice for your multicast job. If you need to use Multicast, the two job idea is great. I woud however have the second task NOT be multicast but be a peer download only, just to guarantee no extra WAN traffic.
2. Other Option: However, my advice would be actually to tell you that multicast may not be the best choice for what you are looking for for the first task either. There is a better option that will allow you to use one task. However you may still need two tasks if you have to prestage the files days in advance.
In a delivery method we have an option called Limit remote downloads to one device at a time.
What happens is only one device download the software. There is another option under Network usage | Download that allows you to configure a Delay between packets, in miliseconds, when download from the source and there is a separate option called Delay between packets, in miliseconds, when download from the peer.
If you set the option to say 50+ miliseconds when downloading from the source, and leave it at 1 when download it from a peer, what will happen is one peer will download from the source super slowly. So a very slow trickle on the wan link. Other devices will then use peer download to get the file from that peer.
This will probably be a better solution for you than Multicast.
3. MC Settings: However, if you choose to use Multicast the Delay between packets, in miliseconds, when download from the source will still work. However the Multicast Packet Timing option would be what you would use to get it to your other devices as fast as possible and it is already pretty much set to be as fast as possible.
4. Prestaging files without using Multicast: Also, the MDR selection can be time consuming and unecessary. You can prestage the files without using Multicast. The easiest way is to deploy a Batch file distribution package where the batch file is blank and the files you want to prestage are "Additional files". So all the files transfer over, the blank batch file runs and does nothing because well, it is blank...and you files are nice and cached and the task didn't have to do any MDR detection which can be time consuming.
I definitely need to predeploy these packages before they get installed.
I'm getting the feel that the Multicast (cache only) delivery method isn't the best solution. Can you use the other delivery method without having to deploy the package? I noticed someone posted using a blank BAT file.
Is this something that is documented by LANDesk somewhere?
I need to push this package to 250 user and it is 400MB in size. There are probably 15 or so subnets.
If I use the "limit downloads to one per subnet" will it download these one at a time or 15 at a time depending on the subnets? I have to be careful because if I download one per subnet with 15 different subnets, I'll saturate that site.
Well, just as Rhyous stated, you would create a batch file distribution package, using a batch file that contains nothing, it's just a blank file. Then, add the files you want to lay down as additional files to that package. When you have done this, you could create a scheduled task using your bandwidth friendly delivery method. The blank batch file and all additional files would be copied down to the client machine. When they are finished copying down, the blank batch file runs, resulting in a 0 exit code and thus a successful status back to the core.
To add to that, you could then setup the single machine per site as a Preferred Package Server, which will allow the clients to copy the files from which ever server you specify for their IP range. With the files at the local site, the clients would get the files from the respective PPS. To create a preferred server, you would create a share structure identical to the share where the package is originally stored. The only thing that gets replaced on the client side of the task is the name of the server.
Of course, if you do this, you could do also do the MC Cache only option to get the package files down to the machine that would be the preferred server.
Can you use the other delivery method without having to deploy the package? I noticed someone posted using a blank BAT file.
Is this something that is documented by LANDesk somewhere?
It was not "Officially documented" but was released as a "Tip and Trick" in a monthly new letter shortly after 8.5 released and was also given as a Tip and Trick in some software distribution training.
It is also the only possible way to pre-stage files without installing the Software through a Management Gateway.
Anyway it is documented now:
Reading this you are talking about a single site that has 15 subnets, That is quite a few subnets. Are there a lot of machines there?
I ask because it sounds like your network architecture is not lending itself to this type of distribution. Neither TMC or Peer Download will prevent 15 copies going down the WAN since it is one copy per multicast broadcast domain (usually subnet). Are these subnet all connected via routers so that TMC traffic will not cross or are they just address ranges on the same physical wire? If they truly are seperate subnets with different broadcast domains then you need to get a preferred package server configured for that site to minimise WAN traffic.
The preferred package server would be your target for a stage 1 pre-deployment so that you are replicating the package either as a task or using a tool like robocopy or httpcopy. Then your TMC distribution task can automatically use the local store as the package source for the TMC subnet representative.
I would recommend the preferred package server for any sites that have this same multi-subnet situation. Others that do not should be fine with normal TMC and peer Download.