It sounds like this model you have is simply to reduce calls to the service desk if something goes wrong with the installation. There is nothing specific you have listed that would mean LANDESK needs to have multiple tasks.
I think it would be worthwhile as suggested to do a download only job that does multicast and also if the machiens fail will use unicast to download to the cache. If you have the bandwidth controls so that only one device per subnet can download from source and also set decent throttling, then as suggested you could do a much larger job to cache in advance.
In theory this job could deploy the software to everyone with no more load than if you had multiple tasks.
A couple of possible scenarios to consider either way:
1 - If you do one large distribution/cache only job, if your subnets are not in a hub and spoke model then you could have multiple downloads across WAN links happening at the same time from the master source. This can be offset by a mixture of bandwidth throttling and perhaps preferred servers
2 - In your existing model, any overlapping of distribution tasks that do multicast can cause systems to drop out of the job because the multicast jobs clash. This 'might' have led somebody to create this model. In short, only have one major multicast job running at any one time to avoid clashes.
It definitely lends itself to an architecture and best-practice discussion for what best suits your environment and the types of activities you do.
The idea of caching and then controlling deployments site by site might be a good one if you want to manage calls to the service desk.
Mark McGinn
MarXtar Ltd/MarXtar Corporation
LANDesk Expert Solution Provider
Update - New v2.3 Adds Process Monitoring & Historical Analysis for Concurrency and Device Based
Update - New v2.3 Now with Automated Subnet Rep Selection and Optional Maintenance of LANDESK Reps
The One-Stop Shop for LANDesk Enhancements
- Wake-On-WAN - Distributed Wake-On-LAN, Scheduled Power Down, and SWDist Sequencing