Deploying Vista – Part 19: Managing Windows Deployment Services (Continued)

This present article continues what we began in the previous one, namely, how to configure and manage servers running the Windows Deployment Services (Windows DS) server role.

Note:
Readers interested in understanding the basics of deploying Vista using the Windows Automated Installation Kit (Windows AIK) are referred to the first 13 articles of this series, which are listed on the author’s home page on WindowsNetworking.com.

In the previous article we examined the General and PXE Response Settings of the properties sheet of a Windows DS server. We also saw how to use the WDSUTIL command to display and modify server settings and prestage client computer accounts. Let’s continue and examine the remaining tabs of a Windows DS server’s properties sheet, and also look at how to use WDSUTIL to configure the settings on these tabs. 

Directory Services Tab

Figure 1: Settings on the Directory Services Tab

The Directory Services Tab of your Windows DS server’s properties sheet lets you define a naming policy for new client computers and specify where computer accounts for these computers will be created in Active Directory. For example, if you want to name the computers you deploy Vista onto as DESK001, DESK002, DESK003 and so on, enter the following string in the Format textbox on this tab:

DESK%03#

You can click the link on this tab for more information about the system variables you can use for creating computer naming strings like this.

The bottom section called Client Account Location on this tab lets you specify the location in Active Directory where the computer account will be created for client computers that use the naming policy configured on this tab. Note that if you prestage the computer accounts for some of your client computers in Active Directory, any naming policy configured on this tab is overridden for these client computers.

The information on this tab can be found in the following portions of the output of the WDSUTIL /get-Server /show:Config command:

     New machine naming policy: %61Username%#

and:

New Machine OU:

     OU type: Server Domain

     OU: CN=Computers,DC=contoso,DC=com

Boot Tab

Figure 2: Settings on the Boot Tab

The Boot Tab lets you specify the default network boot program and boot image that should be used for deploying an operating system onto different system architectures (x86, x64 and ia64). The network boot program (NBP) is the first executable file that is downloaded to the client from the PXE server. When the NBP runs on the client, the deployment process begins. The default NBP for both x86 and x64 architectures is pxeboot.com, a 16-bit program that requires the user to press the F12 key on the keyboard of the client machine before the PXE boot process can continue. If you wish to bypass the need of having a user press F12, you can change the NBP for these architectures to pxeboot.n12 instead. A list of other NBPs you can use are described in the MMC help file for Windows DS.

You can override a configured NBP on a per-client basis by using the following WDSUTIL command:

WDSUTIL /set-Device /Device:<computername> /BootProgram:<path>

You could use this command in a lab environment where you want to require that known clients (work computers that already have computer accounts in Active Directory) to wait for the user to press the F12 key while unknown clients (lab computers used for testing purposes) bypass F12 and begin installation automatically and immediately. This way you can easily deploy Vista on your lab computers while providing a check (F12) to prevent accidental installation of Vista on a work computer.

The Default Boot Image section of this tab can be used to specify a default boot image for each type of client hardware architecture. If your client computers are a mix of x86- and x64-based systems, you can use these settings to ensure that your x64-based systems always install an x64 operating system image (since x64 hardware supports both x86 and x64 operating systems).

The information on this tab can be found in the following portions of the output of the WDSUTIL /get-Server /show:Config command:

Boot Program Policy:

     Allow N12 for new clients: No

     Architecture discovery: Enabled

     Reset boot program: No

     Default boot programs:

         x86  – boot\x86\pxeboot.com

         x64  – boot\x64\pxeboot.com

         ia64 – boot\ia64\bootmgfw.efi

     Default N12 boot programs:

         x86  – boot\x86\pxeboot.n12

         x64  – boot\x64\pxeboot.n12

         ia64 – boot\ia64\bootmgfw.efi

and:

Boot Image Policy:

     Default image type for x64 clients: Both

     Default boot images:

         x86  –

         x64  –

         ia64 –

Client Tab

Figure 3: Settings on the Client Tab

The Client Tab is where you specify an XML answer file that will be used to cause the Windows DS client to run in unattended mode. Completely automating an installation of Vista using Windows DS actually requires creating two answer files, and we’ll examine this subject in more detail in a future article of this series.

DHCP Tab

Figure 4: Settings on the DHCP Tab

On production networks you will usually want your Windows DS server and DHCP server to be two separate machines. If you choose this setup, no further configuration will be required on either machine in order to make your deployment process work. For smaller environments and lab environments however, you may want to place these two roles on the same machine. If you do this however, you must perform two additional steps to ensure the deployment process will work:

1. Configure the PXE server component of your Windows DS server to not listen on UDP port 67 for client requests. To do this, select the Do Not Listen On Port 67 checkbox on the DHCP Tab shown above.
2. Add DHCP option 60 to the scopes on your DHCP server and configure this option as “PXEClient.” To do this when the DHCP Server role is running on your Windows DS server, select the second checkbox on the DHCP Tab shown above. If a non-Microsoft DHCP server is running on your Windows DS server however, you will have to configure this scope option using that DHCP server’s management interface.

The information on this tab can be found in the following portion of the output of the WDSUTIL /get-Server /show:Config command:

DHCP Configuration:

     DHCP service status: Not Installed

     DHCP option 60 configured: <Not Applicable>

Pxe Bind Policy:

     Use DHCP ports: Yes

     Rogue detection: Disabled

     RPC port: 5040

Network Settings Tab

Figure 5: Settings on the Network Settings Tab

The settings on the Network tab are used for configuring an address range for multicast deployment, configuring which UDP ports the PXE and TFTP server components of your Windows DS server can use, and tuning special Windows DS parameters according to the bandwidth of your LAN connection. In general, only the last setting is one you may want to consider modifying. These settings can also be modified from the command-line by using WDSUTIL /Set-Server /Transport with various options.

The information on this tab can be found in the following portion of the output of the WDSUTIL /get-Server /show:Config command:

WDS Transport Server Policy:

     IPv4 Source: Range

         Start IP: 239.0.0.1

         End IP: 239.0.0.254

     Start Port: 64001

     End Port: 65000

     Network Profile: 100Mbps

Advanced Tab

Figure 6: Settings on the Advanced Tab

The Advanced Tab lets you configure certain advanced options for your Windows DS servers. For instance, using the settings found in the Options Used By This Windows Deployment Services Server section of this tab, you can let your Windows DS server automatically discover domain controllers and Global Catalog servers (the default) or you can specify which domain controllers and Global Catalog servers your Windows DS server will communicate with. One reason you might decide to choose the second approach is when your Windows DS server is at a remote site that doesn’t have a domain controller. Another reason for choosing this approach might be if your Windows DS server is having trouble accessing a domain controller and you need to troubleshoot the problem. Note however that if you specify a domain controller and Global Catalog server for your Windows DS server to use and that domain controller or Global Catalog server unexpectedly goes offline, incoming client requests will no longer be serviced by your Windows DS server until the issue has been corrected.

The other settings found on this tab concern DHCP Authorization of the PXE server component of your Windows DS server. By default, this PXE server does not need to be authorized in Active Directory in order to respond to requests from clients. In general, there is no real gain from choosing the option to authorize your Windows DS server’s PXE server in Active Directory as the security gains from doing this can usually be bypassed easily. For example, if a rogue employee has access to a LAN drop on your network, they could connect a computer, install Windows Server 2008, install the AD DS role, create a new forest, install the DHCP Server role, authorize the DHCP Server in their AD DS forest, and begin leasing out addresses. Clearly, physical security is the best defense against rogue DHCP servers on your network. However, if you do decide to authorize your Windows DS server, the PXE server must be configured to listen on port 67. In other words, authorization checks are only performed when your Windows DS server is running on a computer that is not also a DHCP server on your network.

The information on this tab can be found in the following portions of the output of the WDSUTIL /get-Server /show:Config command:

Server Authorization:

     Authorization state: Not Authorized

and:

Directory Services Use Policy:

     Preferred DC:

     Preferred GC:

Conclusion

This article and the previous one have examined how you can manage your Windows DS servers using the MMC console and the WDSUTIL command-line utility. The next articles in this series will look at managing images using Windows DS including creating capture images and discover images, performing offline servicing of images, and other topics related to image management.