Extending Your Solution

Article
07/02/2012

Applies To: Windows Server 2008

Windows Deployment Services enables you to create a variety of custom deployment solutions. You can build an end-to-end deployment solution and Microsoft Windows Preinstallation Environment (Windows PE) provides an environment where you can use custom logic and processing.

In This Topic

Benefits
Creating a Custom Solution
Custom Solution Example

Benefits

Using the Windows Deployment Services platform as part of a custom deployment solution provides the following benefits. For more information about the components included with Windows Deployment Services, see Windows Deployment Services Components.

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 (DFS).
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 https://go.microsoft.com/fwlink/?LinkId=81029. For more information about the components included with Windows Deployment Services, see Windows Deployment Services Components.

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 Deployment Server) is BINLSVC, which is implemented in the DLL, Binlsvc.dll. However, you can replace BINLSVC with a custom provider to modify the standard solution for your environment.
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 others.

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 is implemented.
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 Windows Deployment Services offer the Automatic and Administrator options. There are methods for achieving the Custom option, but they generally involve prestaging the computer, either manually or by using Auto-Add policy. Microsoft recommends using the Microsoft Deployment Toolkit 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 topic does the following:

Starts running from within Windows PE and gathers a computer name and OU (in distinguished name form) from the user.
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 of Setup.
Edits the unattend file to add the computer name and OU that are 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 WinPEshl.ini file.

Instructions for Using the Sample Code

Perform the following steps to use these sample scripts.

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).
1. Create a custom Winpeshl.ini file like the one below, and then copy it to the \Windows\System32 folder of the mounted image.
2. Create a custom script (for example, domainOU.vbs) by using the sample code in the section following this procedure. Copy this script to the \Sources folder of the mounted image.
Unmount the image, and commit the changes.
Add the image back to your Windows Deployment Services server.
Create an image unattend file similar to the sample file below (Sample Image Unattend File).
Associate the unattend file with an install image.
Boot a client into the updated boot image and select the install image that is associated with 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% and %OU% with the values specified. 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="https://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="https://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="https://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
            <ComputerName>%COMPUTERNAME%</ComputerName>
        </component>
    </settings>
</unattend>

Sample WinPESHL.ini File

 [LaunchApps]
"%SYSTEMROOT%\system32\cscript.exe","%SYSTEMDRIVE%\sources\domainOU.vbs"

Share via