First off. I hope you are not pre-staging the files on every machine in your environment. Doing what you are asking would require you to deploy to one machine per subnet to pre-stage. Then when you use a PSP it will check to see if clients in it's subnet have the package, and download it from them.
One thing to note: It is not necesary or recomended to pre-stage the files to every system in the envoronment. One or two per subnet is good.
While you may not always want to pre-stage all files on all systems, we found with Office 2007 it worked well. We wanted upgrade as many systems as we could as fast as we could on a certain day.
We prestaged the files and then on depoyment day we pushed out a "package" that contained the office installer exe, it would download only that file, or really it would skip it as it was already in cache, and then it would fire off the .exe.
We were able to install Office 2007 on over 5000 system in one day.
We found on some of our subnets that multi-cast had issues, due to our network infratructure, so in the end we created a "batch" package that pointed to a dummy.bat file (blank) and then called for all of the other files, including the main .exe as "additional" files.
I know this did not answer the original question, on the how and whats....
Yes, I am aware that multicasting to only select target devices on each subnet is the way to go. I don't have much "real-life" experience with multi-casting. I was reading some of the documentation and came across one that stated it can only be used with a "Push" delivery method. I have to use a Policy Supported Push method. I also wanted to know what goes on in the backround (i.e. all the multicast files are dumped into sdmcache on each subnet target, when using Multicast as the delivery method. Then what?)
Thanks for that information. After this deployment, Office 2007 is next!!
I'll e-mail you something off-line that may help you here (I hope you won't mind). Some of the TMC stuff is explained in training courses, and other stuff is in the manuals.
But at least I can give you something that should hopefully conceptuallise it pretty well for you .
LANDesk EMEA Technical Lead
Yes, when you mutli-cast out, just like a normal push (that is set to download to source) the files are placed in the sdmcache folder into subfolders that mirrow the tree structure of the source. For example, if your files are located on a DFS and you are using UNC and the path to them are \\servername\packages\winzip\
then you will find your files downloaded on the client in sdmcache\\packages\winzip.
Once the files are all staged, you can call for the installation a few ways. One will ensure a better success rate and if the package is small is the best way to go, if the package is really large, it might still be the best way to go, but the hash and file checking might slow it down again.
When the files are staged and you want to perform the actual install:
1. IMO, the best way, create a new software distribution task, using the same exact package, but this time use a different delivery method, use one, Push, or PSP that is set to download to source, under reboot, set that to what you want it set for and make any other changes you want.
What will happen is, as LANDesk tries to push the files down to the client, it will see the exisiting files, perform a hash check and verify each file is there, if one missing or has been updated since the staging, it will be replaced. Once the files are verfied, a fairly quick process, depending in package size, it wil then run the installation.
If for some reason the system was missed during the staging, it will get the entire package and install.
2. I do not normally recommend this as the success rate will not be as high, if files are missing, etc the job will fail, but you could either use a script that calls for the main .exe or msi, etc to run or you could create a new package that only calls the main .exe or etc, and contains any needed command lines, but does not contain the additional files.
Again, I would not recommend this, but wanted to let you know of other ways, we used this for our Office install, but had other tools in place to verify that the package was complete, etc. but it was a lot more work, but did bypass the hash and file verification of a 875 MB package and allowed us to get more systems done in a short time frame.
True. By default a multicast stage job is only a push. All it does is stage the files in the environment till you schedule your PSP. Once that happens your systems that are targets make a request to machines in the subnet. A request for the package. If a peer has the package it will download the files from that peer.
What James said is an okay idea. If the pre-stage multicast fails on any systems; when you start the actual task if there are files missing from the pre-stage it will just get them from a peer.
There is a difference between using Multicast in a push and using multicast to stage files. If you use it to stage files it simply places the files in a systems sdmcache folder for 14 days. Does not execute when it's done. The files are just out there and registered with the TMC service on the targeted systems.
When choosing multicast in your push delivery method. WHat happens? In each Braodcast domain that has a machine targeted to it, there is an election process. The machine that win's the election becomse the Multicast Domain Rep. All the files at that point are unicast not multicast to the MDR. Once the MDR starts to get a partial file sent to it. It will start broacasting the files to the other machines in it's broadcast domain. As soon as all the files end up in the sdmcache on the systems, the install process kicks off to install the software.
Thanks for pointing out about the stage vs. push, I had forgotten about that.