Multicasting Notes from the field
Problem
Typically when clients access a MDT Deployment share, they access it via a File Share. The modern Windows Server File Share can handle a reasonable load. However, if you start to get a lot of clients trying to download the same large OS image file over the network, you might get some performance problems, typically with the network.
Let’s talk numbers:
- MDT can run quite well within a virtual Machine, 1-2 virtual processors, 2-4 GB of ram, and a Gigabit network connection.
- MDT can easily handle 20-25 client deployments at the same time.
- When deploying a 4-8GB image (normal), the biggest bottle neck will be the network, even on Gigabit.
Multicast
Built into the Windows Server WDS OS Role, we find the tools necessary to run Multicast. WDS Multicast is a service program running in the background that listens to WDS requests against a networking port. WDSMulticast is only designed to multicast files, and is only practical for multicasting a few large files, which in the deployment world are *.wim files.
Multicast is designed to transfer one or more large files in a “Rolling Session” to one or more clients. Downloads should be slower than a typical Unicast session, however when you have a couple of clients connected to a Mulitcast session the overall load against the network will be much less than Unicast.
Here is the overall process:
- ClientA starts a multicast session to download Win7SP1x86.wim from the MDT/WDS Server.
- When the broadcast session of Win7SP1x86.wim reaches 25%, ClientB joins the session in progress. ClientB knows that it missed the first ¼ of the Win7SP1x86.wim file, so it starts writing 25% into its local copy of Win7SP1x86.wim.
- When the multicast session reaches 100% of Win7SP1x86.wim, ClientA is done and drops off. However, ClientB is still missing the first ¼ of the file, and stays on the multicast chanel as it restarts (rolls back) to zero.
- Eventually the multicast session of Win7SP1x86.wim reaches the 25% mark where ClientB first joined. ClientB now has 100% of the file and drops off. No clients are connected, and the server stops broadcasting.
MDT Multicasting
I’ve already mentioned the WDS Multicast Service component, now let’s talk the client side. MDT clients manage WDS Multicasting through the
WDSMCast.exe program, this program is distributed in the AIK, and is designed to run on WinPE only.
The
LTIApply.wsf script that downloads and installs OS WIM files is designed to use
WDSMCast.exe if available. There is really nothing to setup on the client, all WDS Multicasting setup steps are performed on the WDS Server.
Let’s take a look at the WDS Command being called:
"%FullPath%\WDSMCast.exe" /UseSparseFile:No /verbose /progress
/transfer-file /server:%ServerName% /namespace:"%Share%"
/SourceFile:"%SourceFile%" /DestinationFile:"%DestFile%"
/Username:%UserDomain%\%UserID% /password:"%UserPassword%"
The
LTIApply.wsf script will automatically fill in the Server Name, Credentials, Source and Target files. But what is this about NameSpace? NameSpaces are just a logical grouping of similar WDS Multicasting Sessions on a server. For MDT we will use the Share name on the UNC path for the DeployRoot. For my machine \\MDT1\DeploymentShare$ the NameSpace would be “DeploymentShare$” (Note the Dollar sign at the end).
It’s important to note that if the Multicast session fails on the client for whatever reason, then the
LTIApply.wsf script will automatically fall back to Unicast file transfer (access the file over a UNC \\server\deploymentshare$\Operaing Systems\Win7\Win7x86.wim path ).
Configuring the server
After you have enabled MDT on your server with the appropriate shares and files, and you have fully tested it out with a sample deployment, we can now enable WDS. Of course, your MDT Deployment Server needs to be on a Windows Server (2008 or 2012) machine that has the WDS OS Role enabled. If you are replicating your Deployment Share out to multiple servers, ensure that the WDS OS Role is enabled on all servers.
First off we need to enable the WDS “Namespace”, remember that from above? That’s easy to do using the
WDSUtil.exe command on each server. I liked to use the
WDSUtil.exe command because it was easy to execute the command on dozens of machines across the corporate network.
wdsutil.exe /new-namespace /FriendlyName:"Microsoft Deployment Server"
/NameSpace:DeploymentShare$ /ContentProvider:WDS
/ConfigString:c:\DeploymentShare /NameSpaceType:AutoCast
/FriendlyName can be anything
/NameSpace should be the share name of your DeploymentShare
/ConfigString should be the local file path of your DeploymentShare (not Network path)
When done, there is one final switch to set on the MDT Server to enable Multicast on the clients. Go to the properties of your Deployment Share. At the bottom of the page you will see a check box: “Enable multicast for this deployment share[…]”. Check the item, ready to go. This setting is found within the %DeployRoot%\control\
settings.xml file.
Performance notes
Remember, Multicast is about performance. We are trying to get as many simultaneous client installations running as we can for a single server. Unfortunately there is no “magic” setting here for WDS to make it go fast. It could all depend on your individual scenario.
Do all machines have a Gigabit connection to the server? Do you multicast a single file, or several dozen *.wim files from a single MDT/WDS server? Also note that Muilticast is slower than Unicast for single files. So I would not configure Multicast in my MDT Capture Lab. Since I’m only imaging/capturing a couple machines at a time.
It also sucks that in some cases you might not have a test lab big enough to test Multicast under full load. The only testing you get is in production! So there is little time for testing and performance tuning.
Sometimes it’s a good idea to keep your *.wim image files at “thin” as possible, however, note that Multicast works best when it can download a small number of large *.wim files. If your MDT installation process also downloads large files like Office, Drivers, and other applications from the same MDT server during state restore, you won’t get the multicast benefit. You might consider putting other large components in the image to improve download performance. Sure it bloats up the Wim file, but it may improve the overall performance under heavy load.
During multicast downloads check the WDS Console on the server to monitor performance. The WDS Server tool will show each session in progress, and show the speed it’s running at. Early in the production process I might monitor the sessions looking for slow connections. Perhaps killing any multicast session that is going too slow.
Remember from above, if at any time during a Multicast Session, the connection drops. MDT Client scripts will automatically fall back to a Unicast session, which is just a normal file read over the network share. SO it’s OK to kill slow sessions from the server console.
It’s also important to note that during a single WDS Multicast session, the server will slow the speed down to accommodate the slowest client. If you have a Gigabit network though out your company, but just one user who has a Fast Ethernet switch in their office, the entire multicast session will slow down for that one Fast Ethernet switch. Yikes!
There are ways to manage how slow machines are handled by the WDS Server, within the properties.
For Microsoft’s own IT department we worked on several settings trying to find the best solution. For whatever reason we couldn’t get the Slow/Med/Fast settings to download fast enough on the high end. And the slow sessions were just *too* slow. Finally we settled on “Automatically Disconnect […]” and set the cut off speed at 1024 KBps. for our 7GB file, that would mean any session taking longer than ( 7GB at 1024KBps yields 7k Seconds or 120 Minutes or 2 Hours ). We figured that if any individual session was slower than 2 hrs then that client *should* be bumped off to it’s own Unicast session, and not slow down the rest.
Thanks to Keith Garner for this post.
