1 of 1 people found this helpful
Test out a targeted multicast distribution to one of the slower sites. The good thing about the way this works is that the distribution is already throttled so that some data is transferred, then it pauses, then it sends again. So in effect it always makes sure the data keeps flowing. If you have concerns, you can modify the targeted multicast setting of the job and increase the delay between packets to go even slower.
What you will get is just one distribution down the line with the other clients receiving it via the representative. This is how the staging works.
When you go for installation, make sure you have your distribution settings configured to download only from peers so that they don't need to go across the WAN and just get it from the cache of local machines.
I've distributed packages the size of this over 64k lines easily before this way.
Mark Star - MarXtar LANDesk Enhancements
Home of Power State Notifier & Wake-On-WAN for LANDesk
New Updated Power State Notifier Pro!
Thank you for your thoughts. I believe I'm doing what you've advised via an alternate method. And, while my method appears to be a solution, I'm not sure it's the best way to execute.
I've found Vista SP2 in Security and Patch Manager. I right clicked -> repaired -> and selected
- Repair as a scheduled task
- Split into staging task and repair task
- Use Multicast
- Download path only from local peers
So, I've tested deployment via the 'Stage' task using Multicast. While I write this I am pushing SP2 to a site with about 15 computers, and it appears that only one of those computers is downloading the patch from the core, and the other 14 are downloading SP2 from the one that is connected to the core (or from other computers that are connected to the one that's connected to the core). I find that to be extremely awesome.
However, I don't plan on using the 'Repair' task, because I find it's user interaction options to be lacking. The user needs to be able to snooze the task, and it doesn't appear that SPM provides those interactions via the 'Scan and repair settings' (I understand there are some interactions, but not the ability to set settings like 'snooze for 4 hours, and let them snooze a max of 3 times').
So, I've created a batch package that executes the file that SPM puts in the sdmcache folder on the machine, and provides the user with the needed pausing interactions. I'm starting to think I should have just deployed the file via it's own distribution package and forget about the SPM altogether...
Just keep in mind that the files are copied to a folder called sdmcache and by default they will "live" in this folder for only 48 hours, except the client that first grabbed them, it should hold them for 14 days.
After the 48 hours they will be deleted from the cache.
Thanks James - I set those two settings to 60 days. However I think I did myself in by switching the task to a scheduled task - after doing that it seemed to want to redeploy the SP to all clients! Everything that was in the "successful" section got moved back to "active".