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.
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.
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.
