This chapter includes guidelines, techniques, and best practices to maximize performance, scalability, and reliability. Among other useful information, you will find techniques to identify blockages in your deployment, such as issues with network and server performance.

In This Topic

Best Practices for Avoiding Performance and Scalability Problems

The following are best practices that you can use:

  • Ensure that the network interface between the server and client has sufficient bandwidth. Consider gigabit network adapters on the physical server with Category 5e (Cat 5e) cabling to a switch that can handle a GB back-plane connection, with 100-MB ports on the front-plane (100 MB-clients, 1-GB back end to the server).

  • Use high-quality Ethernet cabling. We recommend at least Cat 5 or Cat 5e is recommended throughout the physical network.

  • Use network switches. Do not use a hub.

  • Partition network segments to distribute the load across multiple servers.

  • Keep network latency to a minimum to optimize TFTP transfers.

  • Ensure that the disk that contains the RemoteInstall folder has enough throughput to meet the client demand. On small-scale solutions, this may mean getting a Serial Advanced Technology Attachment (SATA) drive that spins at 7,200 RPM or faster. On mid-scale solutions, this may mean getting multiple drives and configuring them using Redundant Array of Independent Drives (RAID) configuration. On large-scale solutions, this may mean investing in a hardware RAID array. The disk volume that contains RemoteInstall should be separate from the system volume.

  • Ensure that there is sufficient memory on the server to handle the demands. This may mean upgrading a server from 32-bit (x86) to 64-bit (x64). (for details about how to evaluate whether this solution is worthwhile for you, see Performance and Scalability Expectations).

  • Ensure that there is enough processor bandwidth on the server to handle the demands. If the server has a lot of processes or services that are running, you may need to distribute the processes and services or upgrade the server’s processor.

Configuring the Server for Performance and Scalability

Performance is the speed of a single client installation. In tests, Windows Deployment Services performs on par with a network-based installation from a file share. As expected, factors such as image size, network speed, and disk speed on the client affect the installation times. Typical installations using the standard Windows Vista image took around 20 minutes from first client boot to desktop.

A key benefit of using Windows Deployment Services is the ability to deploy to several clients simultaneously. Again, many factors influence the solution's ability to scale, but the most important ones are the following (in order from most to least influential):

  1. Network bandwidth. Windows Deployment Services performs best using a 1-GB-per-second network adapter. In tests, a server with a 100-MB-per-second network adapter could perform a maximum of 10 simultaneous installations, while keeping the installation time under an hour (regardless of the server RAM, disk speed, or processor speed). By contrast, a high-end server with a 1-GB-per-second network adapter could install Windows images on 75 simultaneous clients in 45 minutes.

  2. RAM on the server. If the computer has enough available memory, it is possible to cache an entire image into memory. This reduces the number of disk read/write operations and, in turn, speeds up the process. If several different images are being deployed concurrently, you may need more RAM.

  3. Disk speed on the server. Disk speed is another factor that can slow down deployments (even when you have the maximum amount of RAM). The install image must be read from the disk at least once, and a faster disk speed can accelerate this process.

  4. Disk speed on the client. A blockage in the client computer's disk may keep it from achieving the shortest possible installation times.

Performance and Scalability Expectations

This section outlines the approximate amounts of time that elapsed during the image apply and TFTP download phases.

Unicasting

The following table outlines the hardware configurations of the servers that were used during these scalability tests.

Server type Network interface card Hardware configuration

Low-end

100-MB network adapter

  • Single-processor x86

  • 1 GB of RAM

  • 5,400-RPM disk interface

Middle

100-MB network adapter

  • Single-processor x86

  • 2 GB of RAM

  • 7,200-RPM disk interface

High-end

1-GB network adapter

  • Dual-processor x64

  • 4 GB of RAM

  • 10,000-RPM disk interface

Note

Network configuration for the high-end server involved connecting the server’s GB network adapter to a GB switch, which was connected to 100-MB switches that supported a GB back-plane configuration.

Time elapsed during the image apply phase

This table shows the approximate time (in minutes) from start to finish that it took for all of the clients to apply an install image.

Number of clients Low-end Mid-range High-end

1

25

25

25

10

61

55

25

25

125

117

25

50

235

220

35

75

355

330

45

Time elapsed during the TFTP download phase

The following table shows the time (in seconds) it took to download Boot.wim using TFTP.

Number of clients Low-end Mid-range High-end

1

70

55

40

10

210

145

75

25

450

360

120

50

910

805

270

75

1515

1400

420

Time elapsed when the TFTP block was increased

The following table shows the effect on time (in seconds) of changing the default TFTP block size. The times are cumulative for the total number of clients simultaneously downloading the same boot image.

Network adapter Number of clients Default 4,000 8,000 16,000 32,000

GB

50

270

180

118

92

85

GB

75

422

267

171

126

125

100 MB

75

1,410

 

 

1,140

 

Multicasting

Microsoft performed tests to compare the installation times of multicast and unicast transmissions using the same hardware, software, and image set. The following table outlines the configurations of the servers and clients that were used during these tests. The boot and install images were taken from an x86-based version of Windows Server 2008. The size of the boot image was approximately 128 MB, and the size of the install image was approximately 1.32 GB. Note that the out-of-box experience (OOBE) and logon were automated by using an unattend file.

  Network interface card Hardware configuration Operating system

Server

1-Gbps network adapter

  • Dual Xenon processor 5150

  • 2.67 Ghz

  • 8 GB of RAM

  • 64-bit version of Windows Server 2008

Client

100 megabits network adapter

  • Varied but capable of installing the x86-based version of Windows Vista

  •  

Multicast Installation

  25 clients 100 clients 300 clients

 

Restart computer and start clock.

Restart computer and start clock.

Restart computer and start clock.

Time when the first client started download of boot image using TFTP

:23

:21

:23

Time when the last client finishes download of boot image using TFTP

1:02

2:40

7:16

Time when the first client started the multicast transfer

3:04

3:55

8:18

Time when the last client finished the multicast transfer

6:06

7:54

12:30

Total amount of time until the last client reached the desktop

19:47

22:40

27:40

Unicast Installation

  SMB 25 clients SMB 100 clients SMB 300 clients

 

Restart computer and start clock.

Restart computer and start clock.

Restart computer and start clock.

Time when the first client started download of boot image using TFTP

:21

:22

:20

Time when the last client finished download of boot image using TFTP

:58

2:40 

7:13

Time when the first client started image transfer using unicast/SMB

3:14

4:38

8:29

Time when the last client started image transfer using unicast/SMB

13:36

38:15

1:47:58

Total amount of time until the last client reached the desktop

20:59

45:37

1:55:15

Testing of Security Options with Multicast

The following table lists the times for the start and end of the multicast transfer of the install image, and the percentage of the CPU used for the multicast transfer, depending on the level of security that was enabled during the test. This test involved 25 client computers.

  No Security Hashing (default) Signing

Start of multicast transfer of the install image to the client

Clock started

Clock started

Clock started

End of multicast transfer of the install image to the client

2:19

2:27

31:05

Percentage of CPU used during the multicast transfer

~5%

~11%

~25%