you can find here https://tinyurl.com/289ho4y Multicasting is a new feature of R2 in SCCM and is a welcome addition to the OSD feature. Multicast allows for image deployment with a much reduced network load. If, for example, you are deploying a 500 MB image to 20 workstations that have just arrived from the OEM then with normal OSD imaging you would see network traffic equal to around 10 Gig! Using multicasting would result in a significant decrease in network utilization. Depending on the configuration, as little as about 500 MB of traffic required to deploy to all 20 machines! This is the same amount of network traffic you would consume deploying to just a single imaging system using typical OSD imaging before multicast! How do you setup multicast? Let’s walk through the configuration that is required step by step. First, we need to enable multicasting. Multicast requires a distribution point and the ‘transport server’ component of WDS installed on a Windows 2008 server. From there select the properties of the distribution point site system role and make sure the option for BITS, HTTP and HTTPS transfer is selected as shown 
Note the new multicast tab that is added when R2 is installed. Select the multicast tab and enable multicasting. 
There are two options when using multicast – autocast and scheduled multicast. To enable autocast just select to enable multicast. In this configuration the multicast session starts as soon as the first machine powers up and requests the image. As additional machines are also booted up for imaging they will ‘join’ the current multicast session already in progress and consume the remainder of the stream. When the stream ends it will start again and the systems that joined late will consume the parts they missed. While autocasting isn’t as efficient as scheduled multicast it is still significantly more efficient that standard OSD image delivery. Scheduled multicast allows for more control of the multicast session. Here you choose either a time delay before starting the multicast session or a minimum number of clients that must join the session before it starts. The multicast session will start whenever either of the two requirements are met. The idea here is to allow the administrator time to get all of the systems started and ready and then all systems can load the image simultaneously – providing the best usage of network resources. Scheduled multicast is enabled by selecting the ‘enable scheduled multicast’ check box. There are other configuration options on this screen but no extra configuration is required unless by your network. The ‘out of the box’ settings work fine for most environments. In addition, while DHCP and Windows 2008 based WDS (transport component as noted earlier – the PXE boot piece does not need to be on the same server) are needed, there is no special configuration requirement for either to make use of multicasting. The next step is to configure the image package to be deployed by multicast. In properties of the imported image, select the ‘distribution settings’ tab as shown 
Select the option to allow the package to be deployed by multicast and optionally select the other two options. In my testing I tried to select to only allow the image to be transferred via multicast but this didn’t seem to work. When I disabled multicast the image would still deploy, even with this option set. in addition to enabling multicast for the image, you can also enable multicast on any package that is part of the image deployment. On each package select properties and then select the ‘distribution settings’ tab. the same options are available here as were on the image package as shown 
As shown on both the image and the package, multicast is something that takes place in Windows PE only. So, setting these options per package will not result in the package being delivered via multicast through normal software distribution. Finally, enable the task sequence advertisement to deliver the image via multicast. On the properties of the advertisement select the ‘distribution points’ tab as shown. 
To enable multicast MAKE SURE you have selected to ‘download content locally when needed by running task sequence’. This requirement isn’t documented and I spent hours trying to understand why my multicast sessions weren’t starting up before realizing this setting was required. Thats it – we are now ready to go for delivering images via multicast. Let’s walk through a couple of scenarios using autocast and scheduled multicast. In our scenarios we will use PXE booted systems but multicast also works fine when booting from media – the experience is just slightly different when in Windows PE. Autocast – single machine
To test multicast generally you will use a single machine. So, what is your indication that multicast is actually working? When the image begins to deploy you will see that a multicast session is requested, the image is downloaded locally via multicast and then reassembled as shown in the following three screenshots. 
Autocast – two machines
As mentioned, in autocast the first requesting machine will start the multicast as shown above. Any subsequent machines that boot up during the existing multicast session will join in progress and then loop back to the start and request the initial bits again. The screenshots below show two sysems – the one on the left was started ahead of the one on the right but both are downloading the same image. The one on the right started mid-stream. 
After downloading the image the one on the left proceeds to extract while the one on the right finishes up getting the image. 
Scheduled multicast works similarly except here the multicast session will not start until either time has expired or the minimum number of machines have joined the multicast session. The screenshot below shows a system waiting for either more systems to join or the timeout to expire. 
So, while this is all going on – what is happening in the background to make this all work? The SMSTS log varies slightly in each scenario but the core details are the same. The SMSTS log section below is from a machine participating in an autocast multicast session. In the log snip below we see the imaging system flag the multicast enabled distribution point that it wants to use for the multicast session, construct details for the multicast session request and then send the request to the multicast point 
Continuing in the log we see the request information submitted to the multicast point followed by a reply with information the imaging system needs to join the multicast session. Once we get the proper information back from the multicast point we then request and establish the multicast session 
Next we see the response from the multicast server, the session get setup and the download begin 
Once downloaded we begin to reconstruct the wim file and start applying the image. 
When initially setting up the multicast session we say reference to sending information to the multicast point. If we look in the mcsisapi log we see the request received, processed and the resulting reply sent back to the imaging agent as shown 
There is certainly more ‘behind the scenes’ detail that takes place but this give a good picture, end to end, of how to configure, use and understand the process of using multicasting in R2.
