• Benefits
  
  
• Creating a Custom Solution
  
  
• Custom Solution Example
  
  

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 (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.
  
  

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.

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 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:

1. Starts running from within Windows PE and gathers a computer name and OU (in distinguished name form) from the user.
   
   
2. 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.
   
   
3. 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 WinPEshl.ini file.
   
   

Instructions for Using the Sample Code

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

<?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

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