The simplest way to diagnose long download times (observed from the client computer as a progress bar below an IP address) is to look at the average response time between the client and the server it is downloading from. To do this, in Windows PE, open the Command Prompt window, type ping <server’s IP address>, and then note the average latency measured. The output will look similar to the following, where the average latency is less than 1 millisecond (which is good):

C:\Windows\system32>ping 10.197.160.93
Pinging 10.197.160.93 with 32 bytes of data:
Reply from 10.197.160.93: bytes=32 time=2ms TTL=60
Reply from 10.197.160.93: bytes=32 time<1ms TTL=60
Reply from 10.197.160.93: bytes=32 time<1ms TTL=60
Reply from 10.197.160.93: bytes=32 time<1ms TTL=60
Ping statistics for 10.197.160.93:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 0ms, Maximum = 2ms, Average = 0ms

High round-trip time values indicate latency on the network, which is an indicator that TFTP download performance will be poor. To improve this performance, consider doing one or more of the following:

• Use a Windows Deployment Services server that is closer to each client.
  
  
• Remove stress and load from the network segment.
  
  
• If the client connects to the server after multiple network hops, use the output from the tracert command to identify the latent segment, and consider rerouting TFTP traffic to avoid the hop.
  
  

You can also diagnose TFTP download performance problems by examining a network trace of the download activity. Generally, the best practice is to obtain this trace from the client and server simultaneously to assess exactly where the blockage is occurring (server, client, or network). To do this, add a client and a third computer to a hub, start network traces from the server and the third computer, and then boot the client computer from the network.

In the preceding example, the average latency is less than 1 millisecond, which is good. If the average latency between the client and the server is longer than 5 milliseconds, TFTP performance will be seriously degraded.

You may be able to decrease the impact of latency on TFTP download times by increasing the TFTP block size. This means that more data will be sent each time, which cuts down on the number of round-trips. For instructions, see How to Modify the BCD Store Using Bcdedit.

Reducing the size of the boot image can also speed up TFTP downloads. To accomplish this, do the following:

• Use the tools in the Windows Automated Installation Kit (AIK) to create a custom boot image that contains the Windows Setup binary files and Microsoft Windows Preinstallation Environment (Windows PE). For instructions, see Creating Images. Ensure this image has been prepared by using PEIMG.exe /prep. For more information, see PEImg Command-Line Options (http://go.microsoft.com/fwlink/?LinkId=120707).
  
  
• Ensure that the Windows image (.wim) file that contains the boot image does not contain extra space. A best practice is to use the ImageX /export command to export your boot image to a "clean" .wim file before adding the image to the Windows Deployment Services server. For more information, see ImageX Command-Line Options (http://go.microsoft.com/fwlink/?LinkId=120708).
  
  
• Ensure that the .wim file that contains the boot image is using the maximum compression format, LZX. To do this, run Imagex /info ImageFile <ImageNumber|ImageName>. For more information, see ImageX Command-Line Options (http://go.microsoft.com/fwlink/?LinkId=120708).
  
  
• In situations where a server is overburdened, use PXE boot referrals to direct booting clients to different PXE servers for TFTP downloads. For more information, see Managing Network Boot Programs.
  
  
• Alter your physical network topology by doing one or more of the following:
  
  
  • Add a PXE server closer to the client computer.
    
    
  • Move the client computer closer to the PXE server.
    
    
  • Repair the existing network infrastructure (in the case of high-packet loss).
    
    
  • Upgrade to better cabling (Cat 5e is recommended).
    
    
  • Check the condition of the switches between the client computer and the PXE server to ensure that packets are not being dropped.
    
    

To begin, test several client computers on your network, and compare the performance with the test results outlined in the "Performance and Scalability Expectations" section in Optimizing Performance and Scalability. You can also enable logging to gather information. For more information, see the "Windows Deployment Services Client Logs" section in Logging and Tracing. If there are substantial variances between the expected results and your results, you probably have a performance blockage. To troubleshoot common blockages, ask yourself the following questions:

• Do performance problems occur only at certain times of the day? This may indicate a scalability problem that is probably caused by an overused network or an overburdened server.
  
  
• Do performance problems occur only for clients on a particular subnet or network location? If so, determine whether there is a network issue on that segment.
  
  
• Do performance problems occur only for clients that access a particular server? If so, check the server’s performance statistics as well as the network segment that connects the clients to the server to see whether the server is overused.
  
  

Performance problems that occur across a larger group of computers generally indicate either a concurrency problem (scalability) or a blockage in the network or server. To investigate, measure the amount of time it takes to download a file (of approximately the same size as the install image) from the server to the client, in Windows PE. Or try to download the install image after it has been placed in a shared folder on the server. If the time it takes to download a large file exceeds the expectations, you should analyze the switch utilization and observe other network metrics to identify the network conditions that are impacting download times.

If you suspect that the server is the blockage, use the steps in the Using Performance Monitoring section later in this chapter to identify the root cause of the blockage.

Performance problems in this phase are generally caused by network congestion, or inadequate resources on the server or client. If network congestion is the issue, consider doing the following:

• Creating more bandwidth on the network. This may mean upgrading your network infrastructure to support greater bandwidth and higher throughput. For example, it might mean moving from 100 MB to 1 GB, upgrading cabling, replacing hubs with routers or switches, or reducing the number of clients that can access a particular network segment simultaneously.
  
  
• Adding additional Windows Deployment Services servers to the network to handle the network demand. This means segmenting network infrastructure so that smaller groups of clients are answered by each server.
  
  
• Balancing the server load by adding dedicated image servers. For more information, see Storing and Replicating Images Using DFS.
  
  
• Reducing image size. Because larger images mean longer installation times and greater network strain, you should consider creating images that contain minimum customization, drivers, and applications; or consider creating specialized images for each department, hardware type, or function. For more information, see the "Reducing the Size of Images" section in the Servicing Images topic.
  
  

Most Windows Deployment Services server blockages occur because of inadequate bandwidth (at the network adapter), slow disk subsystems, or insufficient available physical memory. To identify the source of the blockage, use the information in the next section, Using Performance Monitoring. Typical causes of performance problems on individual client computers include the following:

• Problems with the physical network connection between the client computer and the network topology
  
  
• Problems with the switching equipment
  
  
• A bad disk controller interface on the client computer
  
  
• A bad network adapter on the client computer
  
  
• Insufficient RAM on the client computer (512 MB of RAM is the minimum requirement for Windows Vista)
  
  
• Poorly performing system drivers