Windows 7 : Using WDS for Multicast Deployments

Any project designed to deploy Windows 7 in an organization will probably require that entire teams, departments, or offices be migrated in as short a time as possible. That means you could have dozens or even hundreds of machines all trying to download an image from a WDS server at the same time. Even a handful of WDS clients could congest the network. This congestion would slow down the image deployment. Worse still, it could negatively affect the other production systems on the network and prevent people from doing their jobs. Windows Server 2008 added the ability to do a multicast deployment to resolve this issue.

Normally, network conversations are one-to-one (sender-to-recipient) transmissions. In such a transmission, a sender sends each packet out once for each recipient. If a stream of data contains 1,000 packets and there are 100 recipients, then the sender transmits 100,000 packets. There will be 100 simultaneous conversations and the network might become congested. In a multicast transmission, a sender transmits each packet on the network to multiple simultaneous recipients. One packet is sent out at a time and each recipient listens for that packet. Using the previous example, the sender will transmit 1,000 packets. Each of the 100 recipients will listen to the transmission and pick up the data. There is much less data transmitted at once and the network is much less likely to be congested by the transmission.

In this section you will read about why multicast is important to WDS administrators, how multicast works, and how to set up a multicast deployment.

1. Why Multicast Deployments Are Needed

Imagine that you are working on a Windows 7 deployment project. You are using WDS to deploy a 7 GB installation image to a number of machines. Because a deployment is quick, the organization has decided that you can do this one team at a time during the workday. You start working on the first team where there are 20 machines to be updated. You go to each machine, start up the WDS client, and start a deployment. All 20 machines are installing at the same time. That’s when your phone starts to ring.

Figure 1 illustrates what has happened. Twenty WDS clients have simultaneously started downloading a single 7 GB installation image over the network. This is the default configuration for WDS and it will flood the network, resulting in the following:

  • The deployment will take much longer because each client has a one-to-one session with the WDS server and the installation image will take longer to download. The cumulative effect will cause all 20 machines to take much longer to install than they should have. That means the users of those machines cannot work for longer than expected.

  • The network congestion will affect other users’ ability to use network services such as file shares, SharePoint servers, email, and so on.

  • Your hearing will be affected when your boss screams through the phone at you.

Figure 1. A default nonmulticast deployment

Imagine if this was a much bigger deployment. A larger enterprise might decide to upgrade hundreds of machines at once. The network would not be able to handle this load and the WDS server might also struggle.

If you are deploying an identical installation image to a number of machines, wouldn’t it make sense if the WDS server could transmit it once on the network and all the clients received the transmission at the same time? Doing so would drastically reduce the impact on the network. In this scenario, around 1/20th of the original amount of data would be transmitted. That is the idea behind a multicast deployment.

2. How WDS Multicast Works

The basic idea of a multicast is that a server with data (the WDS server with an installation image) will transmit data once on the network and a number of listening clients (WDS clients) receive the data. This greatly reduces the workload on the server and the amount of congestion on the network. You can see how Figure 2 compares with Figure 1.

Figure 2. A multicast deployment

That option sounds pretty easy, but it’s not quite that simple. There are a few considerations:

Multicast IP Address Range

A multicast client will require a special IP range. You can configure a WDS server to obtain these IPv4 or IPv6 addresses from DHCP. You can also set up the WDS server to provide configurations to WDS clients from a range of IPv4 or IPv6 addresses that are configured on the WDS server. If you have multiple WDS servers in a site, you must ensure that they have nonoverlapping IP ranges if the WDS server will provide the IPv4 and IPv6 configurations.

WDS Clients with Differing Network Connections

It is likely that a WDS server will have to work with clients that have connections of different speeds. For example, there may be machines with 10 Gbps, 1 Gbps, and 100 Mbps network cards. A multicast deployment of an installation image will, by default, run at a single speed that suits all of the multicast WDS clients. In other words, the deployment will run at the speed of the slowest client (also known as the master client). That may mean that many 10 Gbps clients will download an installation image at 100 Mbps if a single slow WDS client joins the multicast session.

WDS allows you to limit how clients on slow network connections will delay clients on faster network connections. You can configure a multicast to run at different speeds. Clients can be divided up into three sessions (slow, medium, and fast) or two sessions (slow and fast). You can even specify a minimum supported connection speed in Kbps that a WDS client must meet in order to join the session.

WDS Clients Not Starting at the Same Time

It is possible that some WDS clients will start up later than others. For example, you might start a multicast deployment for 100 computers. You cannot boot up all 100 machines into the WDS client at the same time. That means that the multicast deployment will start before all of the clients are ready. WDS gives you two solutions to this.

By default, the late WDS clients will join the existing session and download the image. They are joining the bottom of the session and will be missing the first part of the image. Eventually the WDS server will reach the end of the transmission. All of those WDS clients that received the complete image will continue with their installation. The WDS server will not hang up. It knows that there are existing WDS clients that have a partial image. It will restart the multicast transmission from the start. Each of the late WDS clients will complete their download of the installation image. They will sign off and start their installation as the missing part of the image is downloaded. Eventually all WDS clients will complete their download and the WDS server can terminate the multicast. That means there may be more than one multicast of the installation image. It is much better than the default one-to-one behavior of WDS, but it is not as efficient as it could be in a large simultaneous deployment.

WDS supports scheduled multicasts. The WDS clients can be started up in advance. The WDS clients will wait for the multicast to start. The scheduled cast can be triggered to start when one of three possible conditions is met. An administrator can manually start it. It can start once a minimum number of WDS clients join the multicast, or it can be started at a specified date or time.

Disk Space on the Client

WDS client behavior is slightly different in a multicast deployment. In a normal nonmulticast deployment, the WDS client expands the installation image as it is downloaded. In a multicast deployment, the complete image is downloaded to the local disk of the WDS client before it can be expanded. In this way, a WDS client can join an existing WDS session and download a partial image before the missing piece can be retransmitted by the WDS server.

The requirements for multicast deployments are as follows:

Network Appliances

The devices on the network, such as switches and routers, must support multicast transmissions. Internet Group Membership Protocol (IGMP) snooping should be enabled on all devices that reside between the WDS server and the WDS clients. This will optimize the multicast transmission by ensuring that the multicast packets are sent only to the relevant multicast clients. If you do not enable IGMP snooping, the multicast will actually be a broadcast that is sent to all machines on the network.

Boot Image

If you are deploying Windows 7, you will probably be using a boot image that is created from the Windows 7 media or the latest version of the Windows Automated Installation Kit. The boot image will have support for multicast deployments.

3. Creating a Multicast Deployment

You now know some of the theory behind a WDS client. It is time to see how to put this theory to use. We will look at setting up the behavior of multicast on the WDS server. You can do this by editing options on the Multicast tab in the properties of the WDS server in the WDS console, shown in Figure 3.

Here you can configure how IPv4 or IPv6 addresses are assigned to WDS multicast clients. By default, the WDS server will manage a predefined range of IP addresses (select the Use Addresses From The Following Range radio button). You need to ensure that there is no IP range overlap between servers if more than one WDS server can service a subnet or subnets. You can choose to allow DHCP to manage the allocation of IP addresses (select the Obtain IP Address From DHCP radio button).

Figure 3. WDS server multicast configuration

The Transfer Settings area allows you to manage how WDS multicast will deal with clients with different network connection speeds. You have four options here:

  • The default, keep all clients in a single multicast session at the same speed

  • Divide clients into slow, medium, and fast sessions

  • Divide clients into slow and fast sessions

  • Automatically disconnect WDS clients that have a connection speed that is less than defined (in Kbps)

You will choose one of the Transfer Settings options based on how many client network speeds you have and how many simultaneous streams you want. For example, if you have 100 Mbps and 1 Gbps clients, then will want to support slow and fast sessions. If you add additional clients with 10 Gbps network cards, you might want to support slow, medium, and fast sessions.

You need to create a multicast transmission in the WDS console (under Multicast Transmissions) and associate it with an installation image if you want to perform multicast deployments. Any WDS client requesting that installation image will then initiate or join a multicast session. You can create a multicast transmission by right-clicking and selecting Create Multicast Transmission.

The Create Multicast Transmission wizard will appear. The first screen asks you to name the transmission. Provide a meaningful name that will make sense to you and others at a later time.

The Image Selection screen allows you to associate an installation image with the multicast transmission. You can navigate between image groups and select the installation image that you want to deploy via multicast.

Figure 4 shows the Multicast Type screen. On this screen you can switch between the default Auto-Cast option (where the multicast starts as soon as any WDS client requests it) or the Scheduled-Cast option. The Scheduled-Cast option allows you to control the start of a multicast. In this way, you can make the most of multicast functionality and available bandwidth. By default, if you select Scheduled-Cast, WDS clients will join the multicast but nothing will happen until an administrator approves starts the session. There are two suboptions for Scheduled-Cast that allow the session to start automatically.

Start When The Number Of Clients That Have Requested The Image Is

This option allows an administrator to set a threshold. A minimum number of WDS clients must join the multicast before it starts.

Start At A Later Time

WDS administrators can define a date and time when the multicast session can start.

Figure 4. Configuring the multicast type

You can choose to not select any Scheduled-Cast suboptions, select one at a time, or combine them as required.

The new multicast transmission will appear in the WDS console under Multicast Transmissions. It will have a status of Waiting while no WDS clients are connected to it.

Note that you cannot edit the properties of a multicast transmission. You will have to delete it and re-create it if you want to make any changes. You can have more than one multicast transmission, thus providing support for different installation images.

Now you can boot up your WDS clients. Log into the WDS client and select the image that is associated with the new multicast transmission. If you selected the Scheduled-Cast option, the image download will not start right away. Instead, you will be told that the WDS client is waiting for the server, as shown in Figure 5.

Back in the WDS console, you can navigate into your new multicast transmission object to see which WDS clients are connected (you might need to refresh the screen). Here you have a few options. You can instruct a WDS client to bypass multicast and start a normal download. You can also disconnect the client to abort the image download.

You can right-click on a multicast transmission to manually start the session. You can do so even if the transmission has not yet met any defined start conditions.

Figure 5. A WDS client waiting for a scheduled multicast

The multicast session will appear as Active once it starts. The detail for each WDS client’s session can be seen within the multicast transmission object. Here you get information that can be used to monitor progress and troubleshoot the multicast transmission:

  • Identifying information (MAC address and IP address)

  • Image download progress (Status)

  • The amount of time that the WDS client has been connected to the multicast transmission

  • Data transfer rate

  • WDS client CPU utilization

The image will be expanded and installed once it is downloaded to the clients.

4. Troubleshooting a Multicast Deployment

Two problems can commonly occur with a multicast deployment.

4.1. Slow Multicast Image Download

The most common complaint will be that a multicast transmission is very slow. You should use the multicast transmission client information in the WDS console. Doing so gives you a quick overview of what is happening.

The most obvious thing to do is to check the network. Things like dodgy switch ports or other network activity could affect the speed of an image download. Microsoft recommends that you use switches instead of hubs, and that you use CAT5 or CAT5e cabling or better. Check with your network administrator colleagues or the network monitoring systems to see if anything stands out.

You may have a mix of clients with different connection speeds. If so, make sure that you have set up the multicast configuration (WDS server properties) to divide up the transmission into slow/fast or slow/medium/fast sessions.

Sometimes a single faulty machine can cause a large multicast to run slowly. This machine will have a slow connection and will become the master client, thus reducing the download for everyone else in its session. You can identify the master client by running this command:

Wdsutil /Get-AllMulticastTransmissions /ShowiInstall /DetailsiClients

This code will return information on each of the clients. Search for an attribute called Master Client where the value is set to Yes. This is the machine that is causing the session to be slow. Note the ClientID value for this machine. This value is what you will use to identify the machine. You can disconnect this machine in the console or by running this command:

Wdsutil /Disconnect-Client /ClientID:<ClientID of the master client>

The role of master client will switch to the next slowest machine. Check the download rates to see if they have improved. If not, you will need to identify and disconnect the new master client.

4.2. Network Flooding with IGMP Snooping Disabled

Without IGMP snooping enabled on network devices, the multicast will effectively become a broadcast and can flood the network. The obvious answer would be to enable IGMP snooping. This might not be possible. If that is the case, you can limit the life of the multicast packets on the network using a Registry edit on the WDS server. Microsoft suggests that you set the time-to-live (TTL) for the multicast packets to 32. On Windows Server 2008 you do so by editing HKEY_ LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\Multicast\ Profiles. On Windows Server 2008 R2, you do so by editing HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\WDSServer\Providers\WDSMC\Protocol.