WDS Multicast Configuration
(Last updated on November 30, 2018)
When I’m doing a new Specops OS Deploy installation for a customer I’m always asking if they will be using Multicast and if they have it enabled/configured in the network.
And I’m also recommending our customers to use Windows Server 2008 R2 on the Deployment Servers, due to enhanced functionality compared to previous versions of Windows Server.
Multicast makes it possible to utilize the network better when deploying multiple clients because the server is sending one stream of data, which is then received by all clients.
Instead of each client downloading one stream of data each.
So, 10 client’s downloading one 7GB image, is still ~7-14GB of data with Multicast. While 10 client’s downloading the same 7GB image with normal unicast is 70GB of data in your network.
If they intend to use Multicast and have it configured I’m usually configuring WDS to utilize 2 or 3 Multicast Streams instead of the default one stream.
The reason is that Multicast will adjust the speed to the slowest client in the stream, or else that one would not be able to keep up and lose data. Having one slow client will reduce the speed of all the other clients. This might not be an issue if you are only deploying clients during night time and out of office hours.
The clients will then use and connect to the fastest possible stream that they can keep up with.
But, using three streams will also cause three times as much data in your network.
Another cool thing with Windows Server 2008 R2 multicast is that if one client starts the Multicast stream and has got for example 40% of the data when a second client connects to the stream. The second client will first download 40-100% of the file, and then restart the stream and download 0-40%. So it will not have to wait for the stream to restart before downloading the whole image as in previous versions of Windows Server.
Customers who are not sure that they will be using Multicast or not sure they have configured Multicast correctly in the switches etc may experience very slow deployments with Multicast.
The image transfer may take up to 12 hours.
This is usually caused by Quality of Service in the network equipment. Multicast has not been used that much in the past, and in those cases mostly for Audio and Video services, so some switch/router manufacturers have enabled QoS by default limiting the multicast traffic to ~200kb/sec.
Transferring 7GB of data at 200kb/sec will take a while…
Luckily we have support for both Multicast and Unicast in the same network. For a customer where we experience multicast issues, I’m usually configuring WDS to disconnect a slow client from the multicast stream and let it fallback to unicast.
From my experience 2048kb/sec (2MB/sec) has been a good average number. The client will always start with a multicast transfer, but if it’s too slow it will fall back to unicast. When the customer sorts out any networking problems or disables the Multicast QoS in the switches the client’s will automatically use the full power of multicast.
Since a client will start with Multicast and then after a while be disconnected in the above solution it may increase the deployment time slightly. If that is a problem, you can delete the multicast stream and the clients will use unicast directly.
You can later use the PowerShell command Add-SDMulticastStream to recreate the Multicast Stream when it’s needed.
You should generally not route multicast traffic over WAN Links. Instead block all Multicast IGMP Traffic over the WAN Link and put a Deployment Server on the other site instead.
And also enable IGMP Snooping on your LAN switches to optimize the bandwidth so the traffic is not broadcased all over your network.
A switch will, by default, flood multicast traffic to all the ports in a broadcast domain (or the VLAN equivalent). Multicast can cause unnecessary load on host devices by requiring them to process packets they have not solicited. When purposefully exploited this is known as one variation of a denial-of-service attack. IGMP snooping is designed to prevent hosts on a local network from receiving traffic for a multicast group they have not explicitly joined. It provides switches with a mechanism to prune multicast traffic from links that do not contain a multicast listener (an IGMP client).
IGMP snooping allows a switch to only forward multicast traffic to the links that have solicited them. Essentially, IGMP snooping is a layer 2 optimization for the layer 3 IGMP. IGMP snooping takes place internally on switches and is not a protocol feature. Snooping is therefore especially useful for bandwidth-intensive IP multicast applications such as IPTV.
If multiple servers are using multicast functionality on a network (Transport Server, Deployment Server, or another solution), it is important that each server is configured so that the multicast IP addresses do not collide. Otherwise, you may encounter excessive traffic and corrupt/failed deployments when you enable multicasting. Note that each Windows Deployment Services server will have the same default range. To work around this issue, specify static ranges that do not overlap to ensure that each server is using a unique IP address or Multicast Address Dynamic Client Allocation Protocol (MADCAP). Note that you should only use IP addresses inside the Multicast Address range. To specify this option, right-click the server in the MMC snap-in, click Properties, and then click the Network Settings tab.
If you face this problem, you will see Event ID 514 or 515 on your Deployment Servers.
Product: Windows Operating System
Symbolic Name: EVT_WDSMCS_E_DUPLICATE_MULTICAST_ADDR
Message: The multicast IP address %1 is being used by another Windows Deployment Services server, which has IP %2. Use the Windows Deployment Services management tools to configure your multicast IP address range to avoid this multicast IP address. If you allow this overlap to continue, your network usage will be increased.
Product: Windows Operating System
Symbolic Name: EVT_WDSMCS_E_NON_WDS_DUPLICATE_MULTICAST_ADDR
Message: The multicast IP address %1 is being used by another multicast server, which has IP %2. Use the Windows Deployment Services management tools to configure your multicast IP address range to avoid this multicast IP address. If you allow this overlap to continue, your network usage will be increased.
Restart the WDS Service to apply your changes.