Monitoring, Logging, and Troubleshooting WDS

There are a lot of pieces to WDS, and from time to time, things will not work as expected. It is important to understand how to identify issues and know how to resolve them.

Monitoring WDS Performance

The effectiveness of WDS depends on the physical network. It is likely that many issues you encounter are caused by something in the network. For example, a machine's network adapter might not synchronize speed and flow control with a switch port. This would cause PXE client, boot image, and installation images to download very slowly. Network monitoring might reveal this and an enterprise monitoring solution, such as System Center Operations Manager with a third-party network management pack, would alert administrators to the issue as soon as it occurred.

System Center Operations Manager and WDS Microsoft's enterprise monitoring solution is System Center Operations Manager (SCOM or OpsMgr); the current version is OpsMgr 2007 R2. OpsMgr uses product expertise in the form of management packs to monitor individual products. Microsoft provides a management pack for WDS, which you can download from:

www.microsoft.com/downloads/en/details.aspx?FamilyId=5883D85E- 3B50-4C4F-BEF4-355FCEA4B035

You can use a number of counters in Performance Monitor on the WDS server to identify performance bottlenecks. Table below details some of these counters.

WDS Performance Monitor counters

Counter Group	Counter	Counter	Purpose
WDS TFTP Server	Active Requests	The number of current TFTP session requests.	Determine whether the WDS server can handle the TFTP requests.
WDS TFTP Server	Transfer Rate/Second	Total amount of TFTP data being downloaded from the WDS server per second.	Identify the amount of TFTP traffic and whether the network can handle it.
WDS Server	Active Requests	Total number of currently active requests, including RPC and multicast.	Determine whether the WDS server is able to handle the workload.
WDS Server	Requests/Second	The number of requests received in the last second.	Identify the amount of new client requests.
WDS Server	Processed/Second	The number of requests processed in the last second.	Used with Requests/Second to identify whether the WDS server is processing the workload.
Network Interface	Bytes Sent/Sec	The amount of data transmitted by the WDS server.	Determine whether the network is capable of handling the required traffic.
Physical Disk	Avg. Disk Sec/Read, Avg. Disk Sec/Write, and Current Disk Queue Length	Monitor the physical disk performance on the WDS server.	Determine whether the physical disk on the WDS server is overloaded with requests.
Process	Page Faults/Sec	High amounts of page faults are an indicator of insufficient RAM.	Monitor the server over time to determine trends. Unusual spikes indicate that the WDS server requires more memory.
Processor	% Processor Time	High CPU utilization will affect the overall performance of the WDS server.	Determine whether you need to have a specialized WDS server (not sharing other roles), add more WDS servers, or add more processor(s) to the existing server.

WDS Logging

Trying to troubleshoot without any intelligence on a problem is like navigating in the dark; you will only get to where you need to be by luck. If you are having problems, then you should enable logging to get WDS to record fault information. You can use this information to analyze the issue, seek help on the Internet or from Microsoft or other experts, and resolve the problem. You can enable logging on the WDS server and on the WDS client.

Logging on the WDS Server

You can enable WDS logging in the Application log and the System log (in Event Viewer) by running the following command:

WDSUTIL /Get-Server /Show:All /Detailed

You can use /Verbose or /Progress instead of /Detailed to change the amount of data being recorded.

You can enable tracing for individual WDS components by editing the Registry. Start by enabling tracing for WDS. To do this, change the value of EnableFileTracing (REG_DWORD) found at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSServer to 1. You will then enable tracing for the required individual components by setting the associated Registry value to have a value of 0, as shown in Table below. This is because tracing is disabled by default.

Table: Enable tracing for WDS components

WDS component 			Registry value
Windows Deployment		HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services Dynamic Driver		services\WDSServer\Providers\WDSDDPS\TraceDisabled
Provisioning Service (Windows
Server 2008 R2 only)

Windows Deployment Services	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Multicasting			services\WDSServer\Providers\WDSMC\TraceDisabled

Windows Deployment		HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services PXE			services\WDSServer\Providers\WDSPXE\TraceDisabled

Windows Deployment		HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services TFTP			services\WDSServer\Providers\WDSTFTP\TraceDisabled

Windows Server 2008 R2 has additional tracing, which you can enable using the Registry values in Table below with the following settings:

7F0000: Includes packet tracing and protocol tracing
3F0000: Excludes packet tracing
3E0000: Excludes packet tracing and protocol tracing (default setting)

Table: Enabling additional WDS tracing on Windows Server 2008 R2

WDS component 			Registry value
Windows Deployment		HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services TFTP                   services\WDSServer\Providers\WDSTFTP\TraceFlags

Windows Deployment		HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services Multicasting		services\WDSServer\Providers\WDSMC\TraceFlags

Tracing will consume resources and will affect performance. You should only enable tracing when you need to analyze a problem. Be sure to undo your changes when you have finished troubleshooting.

The resulting trace logs can be found at %windir%\tracing\wdsserver.log.

Logging on the WDS Client

Sometimes issues will happen on the client and nothing will appear in logs on the WDS server. You can enable trace logging on the WDS client to identify the cause of these issues. You can turn on logging by running the following command on the WDS server:

DSUTIL /Set-Server /WDSClientLogging /Enabled:Yes

You can then set the logging level with this command:

WDSUTIL /Set-Server /WDSClientLogging /LoggingLevel:<LoggingLevel>

The possible logging levels are as follows:

None
Errors
Warnings
Info

You can find the client logs on the WDS server in Event Viewer. Browse to Applications and Services Logs ? Microsoft ? Windows ? Deployment-Services-Diagnostics. The Admin log will contain any errors and the Operational log will contain informational messages. Note that there is a code to identify the architecture of the clients:

Architecture 0 is x86.
Architecture 9 is x64.
Architecture 6 is Itanium.

Some logging can also take place on the WDS client, depending on when the error occurs. Any issues during the execution of the Windows PE boot image, before disk configuration, will be logged to X:\Windows\Panther. You can access this location while the boot image is still running by pressing Shift+F10 to launch the command prompt.

Issues that take place in the boot image after the disk configuration will be logged to $Windows.~BT\Sources\Panther, usually on the C: volume, and can also be accessed using the command prompt.

Any issues that occur on the first boot after the installation image is installed will be logged to \Windows\Panther, usually found on the C: volume of the machine.

Now you have the means to determine what is happening if any problems are reported with your WDS deployment implementation.

Troubleshooting WDS

Any troubleshooting of WDS should start with analyzing the performance of the server and capturing logs to get as much information as possible. There are a number of issues that are commonly reported. We will now describe how you can resolve these issues.

A 64-bit PXE client does not see 64-bit boot images. Sometimes an x64 machine will not be able to see or download x64 boot images on the WDS server. This is because the BIOS is not correctly reporting the architecture of the machine. You can overcome this by forcing WDS to recognize the correct architecture by running this command on the WDS server:

WDSUTIL /set-server /architecturediscovery:yes

A 64-bit PXE client is correctly identified but still won't boot. Make sure that you have added and created x64 boot images with the appropriate x64 drivers. If the x64 boot image is still not working, then you can configure WDS to use an x86 boot image as the default boot image for x64 machines.

The WDS Capture wizard does not display the drive you want to capture. Ensure that the required storage drivers are included in the capture boot image. If they are, then it is possible that you have forgotten to run Sysprep to generalize the reference machine. You will need to reinstall the operating system, configure the machine, and generalize it.

The boot image cannot access network resources. Press Shift+F10 to open a command prompt. Check that the machine has a valid IP by running the ipconfig command. If it does not, then it is likely that the boot image does not have a valid network driver. Use ping to verify that you can access the default gateway, a domain controller, and the WDS server. Any failures should be investigated in cooperation with the network administrators.

Download and startup of the boot image is slow in a nonmulticast environment. You may need to adjust the TFTP block and window size. Microsoft provides step-by-step instructions for this task here: http://technet.microsoft.com/library/cc731245(WS.10).aspx.