Windows Deployment Services enables you to create a variety of custom deployment solutions. You can build an end-to-end deployment solution for Windows Vista and Windows Server® 2008. Additionally, Microsoft Windows Preinstallation Environment (Windows PE) provides an environment where you can use custom logic and processing. This chapter discusses ways to extend your solution and provides useful examples.
In This Topic
Using the Windows Deployment Services platform as part of a custom deployment solution provides the following benefits:
- Increased interoperability. Common
barriers for new deployment solutions include the need for new
hardware and the need for changes to network infrastructure to
support advanced networking configurations (for example, having two
Pre-Boot Execution Environment (PXE) servers on the same network
segment). Windows Deployment Services has built-in extensibility
points that help you avoid these potential conflicts. You do not
need to have a separate physical server for each deployment
solution because of the unified PXE server architecture. Also, you
do not need to store images in multiple locations or in multiple
formats because the management approach (which uses the Windows
imaging format) provides a central repository for images.
- A scalable PXE server infrastructure.
The PXE server that is included in Windows Deployment Services
enables you to implement custom logic that dictates which clients
are answered. The PXE server handles advanced networking
configurations by giving you control over which interfaces the
server binds to. This control extends to the IP address and MAC
address layers. The PXE server can handle the throughput generated
by more than 5,000 client PXE requests per second.
- Image storage and management. Windows
Deployment Services stores images in a central location, and the
management tools enable you to perform all common tasks, such as
adding and removing images and configuring server settings.
- Enumeration of images. Many network
installation scenarios face a common problem: getting a list of
available install images from a central distribution point and
returning that list to the client. Windows Deployment Services does
just this. It shows an authenticated client computer a list of
available images that are stored on a server or in a remote storage
location, which is referenced by using Distributed File System
- Network boot support. Offering support
for booting from the network becomes more complex when different
variations of Windows PE need to be supported (for example,
different languages, different hosted applications, and different
architecture versions). Windows Deployment Services accomplishes
this by using the image storage structure and management tools
provided in Windows PE.
Creating a Custom Solution
You can use the Windows Deployment Services PXE server and the Windows Deployment Services client (which is essentially Setup.exe and supporting files for Windows Deployment Services) to create a custom solution. The Windows Deployment Services extensibility points are documented in the Windows Vista software development kit (SDK) at http://go.microsoft.com/fwlink/?LinkId=81029.
Windows Deployment Services PXE Server
The PXE server implementation in Windows Deployment Services consists of a PXE server and a PXE provider. The PXE server contains the core networking capability: it binds to network interfaces, listens for incoming PXE requests, and formats the Dynamic Host Control Protocol (DHCP) response packets. The PXE server supports a plug-in interface. Plug-ins are also known as PXE providers, and they provide the business logic. The server and provider enable you to develop custom PXE solutions while taking advantage of the core PXE server networking code base. The PXE server logic in Windows Deployment Services has two main features:
- A default provider that you can
change. The provider installed by default with Windows
Deployment Services is BINLSVC, which is implemented in the DLL,
Binlsvc.dll. You can remove this PXE provider from the server and
replace it with a custom-written provider.
- Support for multiple providers on a single
server. Rather than having two PXE listeners on the network
(each with its own application logic), you can have multiple
providers. This means that you can have only one PXE listener on a
network that has two or more sets of application logic.
With this PXE server implementation, you can perform either of the following tasks:
- Create a PXE plug-in for a stand-alone PXE
server (for example, a server that is not joined to or
communicating with an Active Directory Domain Services (AD DS)
domain). The plug-in might use a .txt file, an .xml file, or a SQL
database as its data store.
- Enable a second, registered provider to
offer functionality without disrupting or reconfiguring Windows
Deployment Services. One of the most powerful implementations
available is writing a filter provider, which is an additional PXE
provider that resides above BINLSVC (or any other PXE provider) in
the ordered provider list. This filter provider acts as a gate
before the next provider in the list, enabling the next provider to
service selected clients by passing some requests and filtering
Windows Deployment Services Client
The Windows Deployment Services client is a graphical user interface (UI) that is built on Setup.exe in Windows Vista (it contains additional logic that is specific to Windows Deployment Services). The Windows Deployment Services client has the ability to establish a communication channel with a Windows Deployment Services server. This channel provides a mechanism for authentication and for retrieving a list of install images stored on the server. In addition, the Windows Deployment Services client sends progress and status messages to the server while the image is being installed. The library within the Windows Deployment Services client includes the following functionality:
- The ability to authenticate and enumerate
images that are stored on a Windows Deployment Services server
- The ability to send client installation
events that can be used for reporting and monitoring purposes (for
example, sending notifications that the client installation has
started or has finished)
The following is a common scenario that uses this functionality.
- A computer boots into a boot image that contains the Windows
Vista Setup files. The client can boot in any of several ways (from
a CD, DVD, or hard disk drive, or over the network).
- A custom application (with a custom UI) is started.
- The application detects the computer's MAC address and contacts
a database to acquire the correct unattend file.
- The application uses the Windows Deployment Services client
library to retrieve a list of available images stored on a Windows
Deployment Services server and displays the list of choices to the
client (by using the custom UI).
- The application deploys the image that the user selects, and it
also copies the unattend file that was acquired previously.
- The application sends progress and status messages to the
server by using the functionality provided by the Windows
Deployment Services client library.
Custom Solution Example
Remote Installation Services (RIS) offered three options for naming a computer:
- Automatic: The computer name is
automatically generated, and the client computer account is created
in a particular organizational unit (OU), based on the policy that
- Custom: The person performing the
installation specifies the computer name and OU. These values
override the dictated server policy.
- Administrator. The person performing
the installation specifies the computer name and OU after the
installation is completed.
Installations using the Windows Deployment Services client offer the Automatic and Administrator options. There are methods for achieving the Custom option, but they generally involve prestaging the device, either manually or by using Auto-Add functionality. Microsoft recommends using Business Desktop Deployment (BDD) to implement the Custom scenario. However, you can also provide this functionality with a few changes to your boot image, as illustrated in the sample scripts later in this topic..
The Microsoft Visual Basic® script at the end of this document does the following:
- Starts running from within Windows PE and gathers a
computer name and OU (in distinguished name form) from the
- Runs the command setup.exe /wds /noreboot. At this
point, the Windows Deployment Services installation proceeds, and
Setup does not restart as normal after finishing the
Windows PE phase.
- Edits the unattend file to add the computer name and OU that
were entered by the user. Note that the image that is selected
needs an image unattend file that specifies the computer name and
OU. When the script is finished, the client will reboot if the
script is the last (or only) executable file listed in the
Instructions for Using the Sample Code
To use these scripts, perform the following procedure to use these sample files.
- Export a copy of a boot image from your server.
- Mount the boot image as read/write. (Remember, the second image
in the Boot.wim file is marked as RAMDISK bootable, and it contains
the Setup files).
- Create a custom Winpeshl.ini file, and then copy it to the
\Windows\System32 folder of the mounted image.
- Create a custom script (for example, domainOU.vbs) by using the
sample code in the section following this procedure. Copy this
script to the mounted image's \Sources folder.
- Create a custom Winpeshl.ini file, and then copy it to the \Windows\System32 folder of the mounted image.
- Unmount the image, and then commit the changes.
- Add the image back to your Windows Deployment Services
- Create an image unattend file similar to the sample file
(Sample Image Unattend File).
- Associate the unattend file with an install image.
- Boot a client into the updated boot image.
- Select the install image associated the unattend file.
The script starts running when Windows PE boots. It shows a basic UI which enables the user to enter the computer name and the computer OU. The script performs the install and then replaces all occurrences of %COMPUTERNAME% with the value specified in the message box, as well as replacing all occurrences of %OU% with the value specified in the message box. Remember that the OU must be entered in a distinguished name form — for example, OU=MyOU,DC=Domain,DC=com.
Sample Visual Basic Script
Option Explicit Dim computerName, OU, unattendFile, WshShell, result, fso, unattendFileObject, strContents '---------------------------------------------------------------------- unattendFile = "C:\Windows\Panther\unattend.xml" ' end user defined settings '---------------------------------------------------------------------- Set WshShell = WScript.CreateObject("WScript.Shell") dim answer do while answer <> vbYes computerName = InputBox("Enter the desired computer name", "Computer Name") OU = InputBox("Enter the distinguished name of the desired OU", "Organization Unit") answer = MsgBox("Is this correct?" & vbCrLf & vbCrLF & "Name: " & computerName & vbCrLF & "OU: " & OU, vbYesNo, "Computer Account Details") loop WshShell.Run "%SYSTEMDRIVE%\sources\setup.exe /wds /noreboot", 0, true Set fso = CreateObject("Scripting.FileSystemObject") if fso.FileExists(unattendFile) = false then wscript.echo "Couldn't find unattend file" else 'Read the unattend file in and replace apprpriate variables Set unattendFileObject = fso.OpenTextFile(unattendFile, 1) strContents = unattendFileObject.ReadAll strContents = Replace(strContents, "%OU%", OU) strContents = Replace(strContents, "%COMPUTERNAME%", computerName) unattendFileObject.Close 'Write the updated contents back to the unattend file Set unattendFileObject = fso.OpenTextFile(unattendFile, 2) unattendFileObject.Write(strContents) unattendFileObject.Close End If
Sample Image Unattend File
The following is a sample image unattend file.
<?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="specialize"> <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Identification> <UnsecureJoin>false</UnsecureJoin> <MachineObjectOU>%OU%</MachineObjectOU> <Credentials> <Domain>MyDomain</Domain> <Username>MyUserName</Username> <Password>MyPassword</Password> </Credentials> <JoinDomain>%MACHINEDOMAIN%</JoinDomain> </Identification> </component> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ComputerName>%COMPUTERNAME%</ComputerName> </component> </settings> </unattend>
Sample WinPESHL.ini File