Deploying Vista

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part16.html

In the previous article of this series we looked at the first two steps for implementing Windows DS in your networking environment. These two steps are:

• Preparing your environment to make sure it meets the requirements for implementing Windows DS.
• Installing the Windows DS role on one or more servers running Windows Server 2008.

In this present article, we'll examine the final step for implementing Windows DS, namely:

• Performing the initial configuration of the Windows DS servers you have deployed.

Step 3: Performing Initial Configuration of a Windows DS Server

Performing the initial configuration of your Windows DS server does several things including:

• Creating the image store.
• Configuring the PXE server settings.

As we'll see later in a future article of this series, you can also further configure Windows DS server settings afterwards.
You can perform the initial configuration of a Windows DS server two ways:

• Using the Windows Deployment Services Configuration Wizard.
• Using the WDSUTIL command.

Let's examine both of these approaches now.
Performing Initial Configuration Using the Windows Deployment Services Configuration Wizard

Figure 1 shows the Windows Deployment Services MMC console immediately after installing the Windows Deployment Services server role on a server named SEA-WDS belonging to the contoso.com domain. This MMC console and the WDSUTIL command-line utility are the two primary tools you use for configuring and working with Windows DS servers.

Figure 1: The Windows Deployment Services MMC console
To perform the initial configuration of your Windows DS server, expand the Servers node in the console tree and select the node beneath it that represents your Windows DS server (Figure 2).

Figure 2: Selecting your Windows DS server
Tip:
If you are running the Windows DS console from a different computer, right-click the Servers node and select Add Server to add the Windows DS server you want to administer.
Now right-click on your Windows DS server and select Configuration Server from the shortcut menu. This launches the Windows Deployment Services Configuration Wizard (Figure 3).

Figure 3: Launching the Windows Deployment Services Configuration Wizard
Clicking Next displays the Remote Installation Folder Location page of the wizard (Figure 4).

Figure 4: Remote Installation Folder Location page of the wizard
This page of the wizard lets you specify the location for your server's image store. The image store (or image repository) is where you will store your boot images, install images, and other types of files that may be needed when deploying Vista onto bare-metal destination computers. We'll see how to populate the image store in the next article of this series.
By default, the wizard suggests the C:\RemoteInstall folder as the location for your image store, but for performance reasons it will be better if you specify a different partition on a separate hard drive. In this scenario, we'll be using a folder named Images on a separate volume (W: drive) as our image store location (Figure 5).

Figure 5: Locating the image store on a separate drive
Note:
You cannot locate the image store at the root of a drive.
Clicking Next displays the PXE Server Initial Settings page of the wizard (Figure 6).

Figure 6: PXE Server Initial Settings page of the wizard
This page of the wizard lets you configure how your Windows DS server will respond to PXE-enabled bare-metal destination computers when you boot those computers on to your network. You have three options you can select from on this page:

• Do not respond to any client computers – Choosing this option (which is the default) causes your Windows DS server to not respond to any computers when they boot up. In other words, your Windows DS server is "idling" when this setting is selected.
• Respond only to known client computers – Choosing this option causes your server to only respond to "known" computers, that is, client computers for which you have already created ("pre-staged") computer accounts in Active Directory. This option is useful if you want to prevent your Windows DS server from responding to unknown or "rogue" client computers, but it requires more preparation to set up.
• Respond to all (known and unknown) client computers – Choosing this option causes your server to respond to any PXE-enabled computers on your network when they boot up. This is the simplest option to choose so we'll select it for our scenario (Figure 7).

Figure 7: Configuring Windows DS to respond to any PXE-enabled client computers
Note:
If you select "Respond only to known client computers" you also have the option of selecting "For unknown clients, notify administrator and respond after approval" if desired. When this checkbox is selected, network boot requests from unknown client computers that PXE boot onto the network are placed in the pending queue and remain there until the request is approved, rejected, a time-out is reached, or the request is cancelled by the user. We'll examine this option in more detail later in a future article of this series.
Once you have configured your PXE Server Initial Settings as desired, click Finish to complete the wizard and configure your server. Files will then be copied, settings applied, the image store is created, and the Windows Deployment Services service is started. A final wizard page will then be displayed, giving you the option of adding images to the store immediately (Figure 8). Instead of using this page however, we'll clear this checkbox and add our images manually in the next article of this series.

Figure 8: You have the option to add images immediately to the store
Once the wizard is finished, the initial configuration of your Windows DS server is complete. The Windows Deployment Services console now displays a logical folder hierarchy for the image store on your server (Figure 9).

Figure 9: The Windows Deployment Services console showing the image store folders of a configured Windows DS server
Performing Initial Configuration Using the WDSUTIL Command

Advanced users can also perform the initial configuration of a Windows DS server from the command-line using the WDSUTIL utility. To perform the same initial configuration of your newly installed Windows DS server that we achieved using the wizard above, open a command prompt and run the following two commands:
WDSUTIL /Initialize-Server /reminst:"W:\Images"
WDSUTIL /Set-Server /AnswerClients:all
The first command above creates your image store in the Images folder on your W: drive, while the second command configures your server to respond to network boot requests from all computers, both known and unknown.
Tip:
If your Windows DS server is also your DHCP server, you will need to perform one additional configuration step by running the following command:
WDSUTIL /Set-Server /UseDHCPPorts:no /DHCPoption60:yes
Conclusion

This article and the previous one have walked you through the steps of implementing Windows Deployment Services in your networking environment and performing the initial configuration of your Windows DS server. Once this is done however, you are not yet ready to begin using Windows DS to deploy Windows Vista onto PXE-enabled bare-metal systems. Before you can begin deploying Vista, you still have to add boot and install images to your image store, configure the Windows DS client boot menu, and optionally perform other Windows DS configuration tasks. The next several articles of this series will walk you through these additional steps

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part17.html

In the previous two articles of this series we saw how to install the Windows Deployment Services role on a Windows Server 2008 server and how to perform the initial configuration of this role. One of the things this initial configuration process does is create the image store on your Windows DS server. In this present article, we'll look at how to work with your image store by adding images to it.
Boot vs. Install Images

There are two types of Windows images you will need to work with when you populate the image store of your Windows DS server. These two types of images are:

• Boot images – These are used to boot your PXE-enabled bare-metal target computers in order to start the Windows Vista installation process on them. The Sources folder on your Windows Vista DVD product media has a default boot image in it named boot.wim which you can use and/or customize to perform a remote network boot of bare-metal client computers on your network.
• Install images – These are the Windows Vista operating system images you will be installing on your target computers. The Sources folder on your Windows Vista DVD product media has a default install image in it named install.wim to install Windows Vista onto the client computers you have booted using your boot image.

Note:
You can use the default boot and install images as is, or you can customize them as desired. We'll look at how to customize images in a future article of this series.
Adding Boot Images

The first step in working with the image store of your Windows DS server is to add a boot image to the store. What's important here is to add the right boot image. You should always use a boot image from Windows Vista with Service Pack 1 (or later) product media, not from Windows Vista RTM product media. That's because if you use the boot image from the RTM product media, you won't be able to take advantage of certain advanced Windows DS features that were added later when Windows Server 2008 was released. These advanced Windows DS features include multicast deployment and other features we'll look at later in this series of articles.
Note:
For our scenario, we'll use volume-licensed Enterprise Edition of Windows Vista with Service Pack 1.
To add the default boot image to your image store, insert your Windows Vista SP1 product media in the DVD drive of your Windows DS server and cancel the AutoPlay dialog if it appears. Then open the Windows Deployment Services console and select the Boot Images folder of your server (Figure 1).

Figure 1: No boot images have been added yet to this Windows DS server
Now right-click the Boot Images folder and select Add Boot Image. This launches the Windows Deployment Services – Add Image Wizard (Figure 2).

Figure 2: The Add Image Wizard
Click Browse and use the Windows Explorer dialog to locate and select the boot.wim file in the Sources folder on your Windows Vista SP1 Enterprise DVD (Figure 3).

Figure 3: Selecting the default boot image on your product media
With the boot.wim file selected, click Open to add the path to the image to your wizard (Figure 4).

Figure 4: Adding the default boot image to your image store
Clicking Next brings up the Image Metadata page, which lets you specify a name and description for your boot image. The default name and description are shown in Figure 5, but you can modify these if desired.

Figure 5: Specifying a name and description for the boot image
Clicking Next displays a Summary page that lets you verify your actions before performing them (Figure 6).

Figure 6: Summary page of the Add Image Wizard
Clicking Next begins the process of adding the boot image to your image store (Figure 7).

Figure 7: The boot image is being added to the image store
Once the operation is complete, click Finish. Your Windows DS Console should now display the added boot image as shown in Figure 8.

Figure 8: The default boot image has been added to the image store
Adding Install Images

The next step in working with the image store of your Windows DS server is to add an install image to your store. Before you do this however, you should create at least one image group in your store. Image groups are logical folders used to organize your install images so you can manage them more easily. File resources are shared between images in an image group, and this means using image groups lets you make more efficient use of disk storage on your Windows DS server.
Let's begin by creating an image group on our Windows DS server. To do this using the Windows DS console, right-click on the Install Images folder of your Windows DS server and select Add Image Group from the shortcut folder, then type a descriptive name for your image group as shown in Figure 9.

Figure 9: Creating a new image group
Clicking OK adds the new image group to your store as shown in Figure 10.

Figure 10: Image group for Vista SP1 install images
Now right-click on your new image group and select Add Install Image from the shortcut menu. This launches the Windows Deployment Services – Add Image Wizard again, and like before when you added a boot image, you browse to the install.wim file in the Sources folder on your Windows Vista SP1 Enterprise product media and open the image. The default name and description for the install image is displayed on the List Of Available Images page of the wizard; use this page to select the operating system version you want to install (Figure 11).

Figure 11: Select the operating system version you want to install
Note:
In the above figure only one version of the operating system is available to install. This is because we're using volume-licensed media (Vista Enterprise). If you use retail media, you will have a choice between installing several operating system versions such as Vista Business and Vista Ultimate, and you must be sure to install only the version for which you have purchased a product key.
Now continue through the wizard and add the install image to your store in the same way that you added the boot image earlier.
Adding Images Using WDSUTIL

You can also use the WDSUTIL command to add both boot and install images from the command-line. For example, to add the default boot image from your Vista SP1 product media using WDSUTIL, type the following command:

WDSUTIL /Add-Image /ImageFile:"D:\Sources\boot.wim" /ImageType:boot

To create a new image group named Vista SP1 Enterprise Images in your store, do this:

WDSUTIL /Add-ImageGroup /ImageGroup:"Vista SP1 Enterprise Images"

To add the default install image from your Vista SP1 product media, do this:

WDSUTIL /Add-Image /ImageFile:"D:\sources\boot.wim" /ImageType:install /ImageGroup:"Vista SP1 Enterprise Images"

In the above examples we assume that D: is the drive letter of your server's DVD drive.
Conclusion

In this article we have seen how to add boot and install images to our Windows DS server. We'll be using these images soon for deploying Vista SP1 Enterprise onto bare-metal systems, but first we'll examine some further configuration options for Windows DS and that's the topic of the next article in this series

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part18.html

This present article and the next one dig deeper into this topic by examining 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.
Adding and Removing Servers

The Windows DS administration console can be used to manage multiple Windows DS servers remotely from a single location. To add a server to the console, right-click on the Servers node and select Add Server as shown in Figure 1:

Figure 1: Adding a server to the Windows DS console
In the Add Servers dialog box that appears, type the name of or browse Active Directory to locate the server you want to add to the console. To remove a server that was previously added, right-click the server and select Remove Server.
Managing Windows DS Services

To stop, start, or restart Windows DS services on a server, right-click on the server node, select All Tasks, and choose from the shortcut menu as shown in Figure 2:

Figure 2: Stopping and starting Windows DS services
You can also use the WDSUTIL command to stop and start Windows DS services from the command-line as follows:
WDSUTIL /Stop-Server /Server:<servername>
WDSUTIL /Start-Server /Server:<servername>
Here <servername> can be the FQDN or NetBIOS name of the Windows DS server you are managing. You can omit the /Server switch if you are running WDSUTIL on the Windows DS server itself.
Configuring Server Properties

You can manage various aspects of a Windows DS server by configuring its properties. You can do this in two ways:

• By right-clicking a server's node in the Windows DS console and selecting Properties to bring up the properties sheet for the server with its various tabs.
• From the command-line by using the WDSUTIL command, especially the /get and /set switches of this command.

Let's look at both of these methods.
First, you can use the /get-Server switch of WDSUTIL to retrieve the configuration of a Windows DS server. For example, the following command displays the configuration of a server named SEA-WDS:

C:/>WDSUTIL /get-Server /server:SEA-WDS /show:Config

Windows Deployment Services Management Utility [Version 6.0.6001.18000]
Copyright (C) Microsoft Corporation. #All rights reserved.#i

SETUP INFORMATION FOR SERVER SEA-WDS
[-----------------------------------------------------------------------------]
  Server State:
     OS version: 6.0
     WDS operational mode: Native
  Installation State:
     REMINST location: W:\Images
     REMINST share up-to-date: Yes
     Boot files installed:
         x86  - Yes
         x64  - No
         ia64 - No
  [-----------------------------------------------------------------------------]
  CONFIGURATION INFORMATION FOR SERVER SEA-WDS
[-----------------------------------------------------------------------------]
  Server Authorization:
     Authorization state: Not Authorized
  Answer Policy:
     Answer clients: Yes
     Answer only known clients: No
     Response delay: 0 seconds
  Directory Services Use Policy:
     Preferred DC: 
     Preferred GC: 
     Prestage devices using MAC: No
     New machine naming policy: %61Username%#
     Domain search order: Global Catalog Only
     New machines join domain: Yes
  New Machine OU:
     OU type: Server Domain
     OU: CN=Computers,DC=contoso,DC=com
  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
  Interface Bind Policy:
     Policy: Exclude Registered
     Registered interfaces:
  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
  Banned GUIDs List:
  Boot Image Policy:
     Default image type for x64 clients: Both
     Default boot images:
         x86  - 
         x64  - 
         ia64 - 
  WDS Client Policy:
     Logging policy:
         Enabled: No
         Logging level: Info
       Unattend policy:
         Enabled: No
         Command-line precedence: No
         WDS unattend files:
             x86  - 
             x64  - 
             ia64 - 
  OSChooser Policy:
     Menu name: 
  Server Auto-Refresh Policy:
     Refresh period: 900 seconds
  BCD Refresh Policy:
     Enabled: No
     Refresh period: 60 minutes
  Auto-Add Policy:
     Policy: Disabled
     Poll interval: 10 seconds
     Max retry count: 2160 times
     Message: 
     Retention period:
         Approved devices: 30 days
         Other devices: 1 days
     Defaults for x86:
         Referral server: 
         Boot program path: 
         WDS client unattend file path: 
         Boot image path: 
         User: Domain Admins
         Join rights: Full
         Join domain: Yes
     Defaults for x64:
         Referral server: 
         Boot program path: 
         WDS client unattend file path: 
         Boot image path: 
         User: Domain Admins
         Join rights: Full
         Join domain: Yes
     Defaults for ia64:
         Referral server: 
         Boot program path: 
         WDS client unattend file path: 
         Boot image path: 
         User: Domain Admins
         Join rights: Full
         Join domain: Yes
  WDS PXE Providers:
     Name: BINLSVC
     Path: C:\Windows\system32\binlsvc.dll
     Order: 1
     Critical: Yes
  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
  [-----------------------------------------------------------------------------]

The command completed successfully.
Now let's look at each of the tabs on a server's properties sheet and what the various configuration options mean. As we do this we'll also correlate the GUI configuration settings with sections of the command output shown above.
Tip: You can also display the configuration settings for all Windows DS servers in your forest by using the following command:

WDSUTIL /get-AllServers /show:Config /Forest:Yes

General Tab


Figure 3: Settings on the General Tab The General tab displays the FQDN of the server, the location of the remote installation folder where the images are stored, and the mode of the server. The information on this tab can be found in the following portion of the output of the WDSUTIL /get-Server /show:Config command:

SETUP INFORMATION FOR SERVER SEA-WDS
[-----------------------------------------------------------------------------]
  Server State:
     OS version: 6.0
     WDS operational mode: Native
  Installation State:
     REMINST location: W:\Images
     REMINST share up-to-date: Yes
     Boot files installed:
         x86  - Yes
         x64  - No
         ia64 - No
  [-----------------------------------------------------------------------------]

PXE Response Settings Tab


Figure 4: Settings on the PXE Response Settings Tab
The settings on the PXE Response Settings tab were discussed earlier in the article Deploying Vista Part 16: Configuring Windows Deployment Services in this series. That's because these settings can be configured when you perform the initial configuration of your Windows DS server using the Windows Deployment Services Configuration Wizard. The settings on this tab can also be found in the following portion of the output of the WDSUTIL /get-Server /show:Config command:
Answer Policy:
Answer clients: Yes
Answer only known clients: No
Response delay: 0 seconds
In addition, the settings for notifying administrators can be found here in the command output:
Auto-Add Policy:
Policy: Disabled
You can use the /set-Server switch of the WDSUTIL command to configure these settings from the command line. For example, the following command will change the PXE response policy from responding to all clients to responding to none:

WDSUTIL /set-Server /Server:<servername> /AnswerClients:None

Use this command to change the response policy back to responding to all clients:

WDSUTIL /set-Server /Server:<servername> /AnswerClients:All

To change the response delay (the amount of time a PXE Server has to wait before answering a booting client) from 0 seconds to 60 seconds, use this command:

WDSUTIL /set-Server /Server:<servername> /ResponseDelay:60

To configure your Windows DS server to only respond to known clients, use this command:

WDSUTIL /set-Server /Server:<servername> /AnswerClients:Known

Known clients are ones whose computer accounts must be prestaged before the PXE server will respond to them to initiate Vista deployment on these computers. To prestage a client computer, you can use the /add-Device switch of WDSUTIL. For example, to prestage a computer named DESK123 that has MAC address 00-17-31-C5-D2-8E, use the following command:

WDSUTIL /Add-Device /Device:DESK123 /ID:00000000000000000000001731C5D28E

Note the twenty leading zeros before the 12-byte MAC address in the above command. When you run this command, it creates a computer account in Active Directory for the computer you are going to install Vista on. To see this, open Active Directory Users and Computers and select the Computers container and you should see an object named DESK123 in the container. Now enable Advanced Features under the View menu and double-click on the DESK123 object, then select the Attribute Editor and scroll to display the netbootGUID attribute as shown in Figure 5:

Figure 5: Computer account for DESK123 showing the netbootGUID attribute
If your computer has a tag on it listing the GUID of the machine, you can also use this in the /ID switch in the above command instead of the MAC address. The /add-Device switch also takes additional options for prestaging clients. For example, the following command prestages a computer account for computer DESK123, specifies server SEA-WDS as the server from which the client will download the Windows DS network boot program and boot image using TFTP, specifies the name and relative path of the network boot program, specifies the name and relative path of the XML answer file used to automate the installation screens of the Windows DS client, gives domain user Tony Allen (CONTOSO\tallen) full access to the computer including permission to join the computer to the domain, specifies the name and relative path of the boot image to be used during deployment, and specifies the organizational unit in which the computer account will be created in the domain:

WDSUTIL /add-Device /Device:DESK123 /ID:00000000000000000000001731C5D28E /ReferralServer:SEA-WDS /BootProgram:boot\x86\pxeboot.com /WDSClientUnattend:WDSClientUnattend\unattend.xml /User:CONTOSO\tallen /JoinRights:Full /BootImagePath:boot\x86\images\boot.wim /OU:"OU=Seattle Computers,OU=Seattle,DC=contoso,DC=com"

Tip: If you make a mistake using the WDSUTIL /add-Device command, you can modify the attributes of the computer account you created by using the /set-Device switch of WDSUTIL. You can also modify attributes of the account directly using the Attribute Editor tab of the advanced properties of the o object in the Active Directory User and Computers console

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part19.html

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.

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part20.html

Working with Windows DS Images

If you may recall from previous articles of this series that Windows DS employs two types of Windows images (.wim files) to work its magic:

• Boot images – Used to boot PXE-enabled bare-metal systems in order to install Windows Vista on them.
• Install images – Images of the Windows Vista operating system which you can install onto systems.

On your Windows Vista Enterprise edition DVD, you'll find two plain-vanilla images in the Sources folder:

• Boot.wim – A default boot image you can use to boot bare-metal systems whose network cards support PXE booting from the network.
• Install.wim – A default install image you can use to install the default (i.e. un-customized) Windows Vista operating system on a computer.

In the simplest scenario, you can use Windows DS to boot a bare-metal PXE-enabled system using Boot.wim and then install Vista on the system in a plain-vanilla configuration using Install.wim and you may perform this installation manually, or you can use answer files to automate the process.
There's more to Windows DS image management than this however. For instance, you can customize the default boot image by adding additional drivers to it. You can also create a special type of boot image called a Discover Image that can let you use Windows DS with systems that do not support PXE. And you can add multiple boot images to your image store and configure the boot menu that appears when the client boots. You can also customize the default install image to deploy a pre-configured installation of Vista instead of the default installation. You can also create another special type of boot image called a Capture Image to capture an install image from a preconfigured reference computer. In this article, and the next few of this series, we will examine these various ways of managing Windows DS images.
Understanding Discover Images

We will begin by discussing Discover Images, which are special boot images that can be used for installing Vista onto systems that are not PXE-compliant, that is, which do not have a PXE-enabled network card that can be used to acquire a TCP/IP address from a PXE server. (Remember that Windows DS includes a built-in PXE server that can work together with a DHCP server to enable destination computers that have no operating system to boot over the network.)
If you have older systems that do not have PXE-enabled network cards in them, you can boot these systems using a bootable Discover Image and then install Vista onto them over the network using Windows DS. However, even if you do not have such an old system, there are other reasons you may want to use Discover Images. For instance, Discover Images can be very useful for deploying Vista in high-security environments where PXE booting is not allowed for reasons of policy.
Another scenario where you may want to use Discover Images is when you have more than one Windows DS server servicing your network (see Figure 1). In this case, you could create multiple Discover Images and then configure each of them to connect to a different Windows DS server from which to perform deployments. This is the scenario we will focus on for the remainder of this article; How to create and configure Discover Images to allow you to select which Windows DS server to use for installing Vista on a particular destination system.

Figure 1: Environment with two Windows DS servers
Creating and Using Discover Images

Creating a Discover Image is straightforward. Begin by selecting the Boot Images folder for your server in the Windows Deployment Services console. Then right-click on the default boot image in the right-hand pane and select Create Discover Boot Image (Figure 2):

Figure 2: Creating a discover image from your default boot image
This launches the Create Discover Image Wizard as shown in Figure 3 next:

Figure 3: The Create Discover Image Wizard
Fill in the information needed on the Discover Image Metadata page of the wizard. In this example, we're going to create a Discover Image that will enable the client to connect to the Windows DS server named SEA-WDS2 in the contoso.com domain. We will append "WDS2" to the name of the Discover Image so we can distinguish it from the default boot image, and we'll give the discover image a better description than the default one provided. We will also specify that our new discover image will be named discover_WDS2.WIM and will be created in the W:\DiscoverImages folder. Figure 4 shows the Discover Image Metadata page of the wizard with all this information entered.

Figure 4: Configuring the name, description, location, and Windows DS server for our new discover image
Clicking “Next” causes the wizard to begin extracting the image information from the default boot image file (Figure 5):

Figure 5: Image information is being extracted from boot.wim
Once the image information is extracted, the image is captured to the discover_WDS2.WIM destination file (Figure 6):

Figure 6: Capturing image information as discover_WDS2.WIM
Once the Discover Image has been captured and metadata written, click Finish to end the wizard. Now, right-click on the Boot Images folder and select Add Boot Image to launch the Add Image Wizard, then add your new Discover Image to the image repository of your Windows DS server. (Refer back to article 17 in this series for a walkthrough of adding boot images to the Windows DS image store.)
Tip: You can also use the WDSUTIL /New-DiscoverImage command to create a new Discover Image.
Now let us repeat the process above to create a second discover image, only this time the image will direct the client to the server named SEA-WDS instead of SEA-WDS2. Once this second Discover Image has been created, add it to the Boot Images folder of your Windows DS server.
The Boot Images folder will now look like this (Figure 7):

Figure 7: Three boot images—one default boot image and two discover boot images
Now, if you turned on a PXE-enabled bare-metal client system and it happened to connect to server SEA-WDS2, you would be offered three boot images to choose from:

• Microsoft Windows Longhorn Setup (x86)
• Microsoft Windows Longhorn Setup (x86) – WDS
• Microsoft Windows Longhorn Setup (x86) – WDS2

Since we do not want to use the default boot image, let us disable it, which will remove it from the client's boot menu. To disable the default boot image, right-click on it and select Disable as shown in Figure 8:

Figure 8: Disabling the default boot image (boot.wim)
Disabling a boot image changes its status from Online to Offline as shown in Figure 9:

Figure 9: The default boot image is now offline (disabled)
Finally, use the Windows Deployment Services console to add your two Discover Images to the Boot Images folder of the other Windows DS server. (You do not need to copy the two Discover Image .wim files to the other server in order to do this, you can simply launch the Add Image Wizard by right-clicking on the Boot Images folder belonging to your other server and selecting Add Boot Image from the shortcut menu.) Then disable the default boot image on the other Windows DS server so clients will not be able to use it to boot and connect to a Windows DS server.
Both Windows DS servers (SEA-WDS and SEA-WDS2) now have the same two Discover Images added to their repositories. Now if you boot a PXE-enabled bare-metal system onto the network, the network card on the system will obtain an IP address from one of the PXE servers (i.e. Windows DS servers). At that point, you press F12 and the Windows Boot Manager menu is displayed, showing the two Discover Images as options to choose from (Figure 10). You can then choose the Windows DS server you want to use to install Vista onto the system.

Figure 10: Boot menu showing two discover boot images to choose from
Conclusion

In this article we have examined how Discover Images work. In the next article we will look at capture images, another type of boot image you can crate and use in Windows DS

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part21.html

In the previous article of this series we examined discover images, which are boot images you can use to deploy Windows Vista onto non-PXE systems or to allow users to select which Windows DS server to use for their installation. Another type of boot image you can create in Windows DS is the Capture Image, which you can use to capture an install image from a preconfigured master installation of Windows Vista so that you can then duplicate this installation onto multiple destination computers.
Recall from article 13 of this series that performing a basic image-based deployment of Windows Vista using the Windows Automated Installation Kit (Windows AIK) involves the following seven steps:

1. Install the reference computer.
2. Customize the reference computer.
3. Sysprep the reference computer.
4. Boot the reference computer using Windows PE.
5. Capture a base image from the reference computer.
6. Copy the base image to a network share.
7. Deploy the base image onto destination computers.

With a server-based deployment solution based on Windows DS however, these steps are reduced to the following:

1. Install the reference computer.
2. Customize the reference computer.
3. Sysprep the reference computer.
4. Create a capture boot image and add it to the store of your Windows DS server.
5. Boot the reference computer and select the capture image from the boot menu, then walk through the pages of the Capture Image Wizard to capture an image of your reference computer, upload the image to your Windows DS server, and add the image as an install image.
6. Use Windows DS to deploy the captured image of your reference computer onto destination computers.

Let us see how all this works. Note that because the first three steps are the same for both processes, we will not repeat them here.
Creating and Using Capture Images

Creating a capture image is even easier than creating a boot image. Begin by selecting the Boot Images folder of your Windows DS server. Then right-click on your default boot image and select Create Capture Boot Image from the shortcut menu as shown in Figure 1 below. Note that in this figure two Windows DS servers named SEA-WDS and SEA-WDS2 are being displayed. We will be working only with server SEA-WDS2 in this example, and to prevent our sysprepped reference computer from connecting with server SEA-WDS when the reference computer is booted, we have stopped the Windows DS service on server SEA-WDS. To do this, right-click on SEA-WDS.contoso.com in the console tree and select All Tasks | Stop. Note also that there are currently three boot images displayed in the Boot Images folder on SEA-WDS2:

• Microsoft Windows Longhorn Setup (x86) – This is the default boot image (boot.wim)
• Microsoft Windows Longhorn Setup (x86) – WDS – This is a discover image that connects booting clients with server SEA-WDS
• Microsoft Windows Longhorn Setup (x86) – WDS2 – This is a discover image that connects booting clients with server SEA-WDS2

Figure 1: Creating a capture boot image
Selecting the Create Capture Boot Image option from the shortcut menu launches the Create Capture Image Wizard. As shown in Figure 2 below, we have entered a name, description, and location for saving the capture image we are creating. (The capture image will be named capture.WIM and will be saved in the CaptureImages folder on W: drive.)

Figure 2: Specifying a name, description, and location for saving the new capture image
When you have complete the wizard, your new capture image has been created, and the next step is to import this image into the image repository on your server. To do this, right-click on the Boot Images folder and select “Add Boot Image” to launch the Add Image Wizard. On the Image File page of this wizard, browse to select the capture image that you created earlier (Figure 3).

Figure 3: Adding the new capture image to the image store
Follow the remaining steps of the wizard until the capture image has been added to the store and is displayed in the Boot Images folder as shown in Figure 4 below. Note that this figure also shows that we have disabled all boot images on the server except for the capture image. That way we would not be prompted with a boot menu when we restart our sysprepped reference computer. Of course, you could leave the other boot images enabled and then select the capture image when the boot menu appears, but that would add an additional step.

Figure 4: The capture image is ready to capture an image of a sysprepped reference computer
Tip:
You can also create a new capture image using the WDSUTIL /New-CaptureImage command.
Now we are ready to capture an install image from a sysprepped reference computer on which Windows Vista has previously been installed and customized to create a master installation we want to clone to client systems on our network. Begin by configuring the master computer to boot from the network using a PXE-enabled network card. Turn the master computer on. As the master computer boots, it will acquire an IP address from the PXE server (server SEA-WDS2.contoso.com) and then it will prompt you to press F12 to continue. Pressing F12 will cause the master computer to download and install the capture boot image from server SEA-WDS2. (If you have additional boot images enabled on your Windows DS server, you will be presented with a Windows Boot Menu at this point and will have to select the capture image from the list of boot images displayed). Once the capture boot image has been downloaded, it will be loaded and run. Figure 5 shows this happening:

Figure 5: Loading the capture image
Once the capture image has initialized, the Image Capture Wizard launches within the Windows Preinstallation (WinPE) environment as shown in Figure 6:

Figure 6: The Image Capture Wizard
The next screen of the wizard prompts you to select the volume you wish to capture an install image from (usually C: drive) and a name and description you wish to have assigned to the captured image (Figure 7):

Figure 7: Specifying a name and description for the captured image and the disk volume you wish to capture
The next wizard screen prompts you to specify a location and filename for saving the captured image onto the master computer (Figure 8). Why save the captured image locally? In case the network goes down during the capture and the wizard is unable to upload the captured image to the image store on your Windows DS server. In this example we are capturing the image as the file cap3.wim and saving it in a folder named Capture Image on C: drive of the reference computer.
Also on this wizard screen is a checkbox you must select in order to upload the captured image to your Windows DS server. Select this checkbox, then type the FQDN of the Windows DS server you wish to upload the captured image to and click Connect. When a credentials dialog is displayed, type credentials for a user with administrator privileges for the domain. Once the wizard has successfully established a connection with your SEA-WDS2, the bottom list box displays a list of Image Groups on the server—select the Image Group you wish to upload the captured install image to.

Figure 8: Specifying the image name, local storage location, and uploading of the captured image to an Image Group on the specified Windows DS server
Clicking Finish begins the capture process (Figure 9):

Figure 9: An install image is being captured from the reference computer
Once the image of the reference computer has been captured and saved locally, the saved image is automatically uploaded over the network to your Windows DS server (Figure 10):

Figure 10: Uploading the captured image to the Windows DS server
Once the upload is finished, click Close to end the wizard. Your reference computer will now reboot, and you will probably want to immediately shut it down as soon as it restarts so you can capture another image from it later if needed. If you let the reboot continue, Windows Setup will run and the machine OOBE (Windows Welcome) prompts will be displayed.
Finally, you should use the Windows Deployment Services console to verify that the captured install image has been successfully uploaded to your Windows DS server (Figure 11). (If the captured image isn’t displayed, close the Windows DS console and re-open it.) At this point you are ready to deploy the captured image onto bare-metal destination computers, which is the topic of the next article in this series.

Figure 11: The captured image has been added to the repository on your Windows DS server as an install image

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part22.html

This present article continues our look at the Windows Deployment Services (Windows DS) server role by examining how to deploy Windows images to bare-metal hardware using Windows Deployment Services.
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 of this series we examined how to use a capture boot image to capture an install image from a preconfigured master installation of Windows Vista so that we can then duplicate this installation onto multiple destination computers. In other words, we have now completed the first five steps of the following six-step process for using Windows DS to deploy images:

1. Install the reference computer.
2. Customize the reference computer.
3. Sysprep the reference computer.
4. Create a capture boot image and add it to the store of your Windows DS server.
5. Boot the reference computer and select the capture image from the boot menu, then walk through the pages of the Capture Image Wizard to capture an image of your reference computer, upload the image to your Windows DS server, and add the image as an install image.
6. Use Windows DS to deploy the captured image of your reference computer onto destination computers.

What remains to demonstrate is how to perform the final step, that is, how to take the captured image of our reference computer which is stored in the image repository on our Windows DS server and apply this captured image onto a bare-metal PXE-enabled destination computer.
Manually Deploying an Image Using Window DS

Let's first examine how to manually deploy images from a Windows DS server. Our goal in this walkthrough will be to deploy the captured image of our reference computer onto a bare-metal PXE-enabled client computer. Based on the previous few articles on this series, the following table shows the state of each Windows DS server and of the boot and install images on each server:
Server
Boot images
Install images
SEA-WDS (running)
Default boot image (disabled)
WDS discover image (enabled)
WDS2 discover image (enabled)
Windows Vista Enterprise (enabled)
SEA-WDS2 (running)
Default boot image (disabled)
Capture image (disabled)
WDS discover image (enabled)
WDS2 discover image (enabled)
Windows Vista Enterprise (enabled)
VistaMaster03 captured image (enabled)
What we want to do is boot our bare-metal client computer from server SEA-WDS2 using the WDS2 discover boot image on that server, then, we want to deploy the captured image of our reference computer onto the client computer.
Begin by ensuring that the bare-metal client computer has its BIOS configured to boot from the network (Figure 1):

Figure 1: Booting the PXE-enabled bare-metal client computer.
What is happening in the above figure is this. The client computer broadcasts DHCP DISCOVER to any listening DHCP server on the network. The DHCP server, which in this example is SEA-DC1.contoso.com, respond with DHCP OFFER, offering an available IP address to the requesting client computer. The client computer then responds with DHCP REQUEST, asking the DHCP server if it may lease the offered IP address. The DHCP server responds with DHCP ACK indicating that the client has leased the offered address.
At this point the client computer broadcasts DHCP REQUEST again, this time to any listening PXE server on the network. The Windows DS servers are of course PXE servers, so one of them responds at this point with DHCP REPLY. The client computer then downloads the default network boot program (WDSNBP.com) which runs on the client computer using Trivial File Transfer Protocol (TFTP), detects the architecture type of the client computer (here x86), displays the name (IP address) of the responding Windows DS server (ServerHostName), displays the name of the default boot program for the client's hardware architecture (in this case the boot program is pxeboot.com since the client's hardware platform is x86), and prompts the user to press F12 to continue the network boot process (see Figure 2):

Figure 2: Network boot begins.
When the user presses F12, the default boot program (pxeboot.com) is downloaded to the client and then runs, displaying the Windows Boot Manager menu (Figure 3). This menu displays the available boot images on the responding Windows DS server, and in this example we see the two discover images we created earlier in Part 20 of this series. We'll select the boot image named "Microsoft Windows Longhorn Setup (x86) – WDS2" as we want to deploy an install image from SEA-WDS2 onto the client computer.

Figure 3: Select the Windows DS server you want to deploy an image from.
Pressing ENTER shows the next screen (Figure 4) in which the boot image is being downloaded via TFTP from the Windows DS server to the client computer:

Figure 4: Downloading a boot image from the Windows DS server.
Once the boot image has been downloaded and initialized, the Windows Preinstallation Environment (Windows PE) is now running on the client. For more information on Windows PE, see article 10 and article 11 in this series. The first screen when the boot image initializes prompts you to select your locale and keyboard language (Figure 5):

Figure 5: Initial screen when the boot image initializes.
Clicking Next brings up a credential dialog, and you must enter credentials for performing the deployment (Figure 6). Since image groups have Allow Read and Execute permissions for the Authenticated Users built-in identity for all their images, any domain user credentials will do here. Note that this credential box also displays the name of the Windows DS server you've connected to in its title bar.

Figure 6: Enter credentials for deploying the image.
Clicking OK now displays a list of available install images on the Windows DS server (Figure 7). Since we want to deploy the image we captured earlier from our reference computer, we are going to select the first option (VistaMaster03) from the list of install images displayed on this screen.

Figure 7: Selecting an install image to deploy onto the client computer.
Clicking Next lets us choose the disk on which we want to install Windows Vista (Figure 8):

Figure 8: Select the disk to use for installation.
Clicking Next causes the client to wait for the Windows DS server to begin deploying the image (Figure 9):

Figure 9: The Windows DS server is preparing to deploy the image.
After a few moments, the server begins deploying the image to the client system (Figure 10):

Figure 10: The install image is being deployed to the client.
At this point Windows Setup continues in the usual way until the machine OOBE (a.k.a. Windows Welcome) begins as shown next in Figure 11:

Figure 11: First screen of the machine out-of-box-experience (OOBE).
The machine OOBE allows each user to customize their computer by giving it a name, creating a local user account, selecting a desktop background, and so on. For example, if you were an OEM and you were going to deliver the computers to customers, the customer would walk through OOBE the first time they turned the computer on. Once you complete the machine OOBE, you are then prompted to enter your credentials for logging on to the domain (Figure 12):

Figure 12: The user named John Chen logs on to his computer for the first time.
At this point, you can verify the installation. The reference computer whose image we captured had the game Freecell installed on it, so if we look under Games on the Start menu the program should be present (Figure 13):

Figure 13: Verifying that John's computer was deployed using the captured image of the reference computer.
Conclusion

In this article we have examined how to deploy a captured Vista image manually using Windows Deployment Services. In the next article we will look at how to automate such a deployment using answer files

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part23.html

In the previous article of this series we looked at how to use Windows DS to manually deploy a captured image of a preconfigured reference computer onto a PXE-enabled bare-metal destination computer. This present article examines how to automate this image deployment process by using answer files.
Windows Deployment Services and Answer Files

To perform an unattended image-based deployment using Windows DS, you must create and configure two answer files:

• Unattend.xml – This answer file is used to suppress the user interface screens of the Windows DS client that are normally displayed at the beginning of the install process. These screens include specifying a locale/language, providing credentials to connect to the Windows DS server, choosing the install image you want to install on the system, and selecting a disk/partition for installation purposes.
• ImageUnattend.xml – This answer file is used to suppress the machine out-of-box-experience (OOBE) or Windows Welcome screens that are normally displayed at the end of the install process. These screens include specifying a local/language, accepting the EULA, specifying a product key if required, specifying a computer name or autogenerating one, configuring firewall protection level, specifying a time zone, and configuring the network location (Home, Work or Public).

To create these two answer files, you should use Windows System Image Manager (Windows SIM). The sections that follow will demonstrate how to create and configure each of these answer files and then we'll walk through the steps of performing our unattended install.
Creating and Configuring Unattend.xml

I'll assume you are already familiar with using Windows SIM. If not, please refer back to article 6 and article 7 from this series. The simplest way to demonstrate how to create the Unattend.xml file for automating the Windows DS client experience is to show screenshots from Windows SIM as follows. First, add the Microsoft-Windows-International-Core-WinPE component for your architecture (x86 in this walkthrough) to the windowsPE configuration pass section of your answer file (refer back to article 3 in this series if you need a refresher on configuration passes). Then configure the settings for this component in your answer file as shown in Figure 1 if you are installing the U.S. English version of Windows Vista Enterprise as we are in this walkthrough deployment.

Figure 1: Configuring locale/language settings for the windowsPE configuration pass.
You also need to specify the language for the Microsoft-Windows-International-Core-WinPE\SetupUILanguage component as shown in Figure 2:

Figure 2: Configuring locale/language settings for the windowsPE configuration pass (continued).
Next, add the Microsoft-Windows-Setup\DiskConfiguration\Disk\CreatePartitions\Crea tePartition and Microsoft-Windows-Setup\DiskConfiguration\Disk\ModifyPartitions\Modi fyPartition components to the windowsPE configuration pass section of your answer file. Specify 0 for the DiskID setting and true for the WillWipeDisk setting as shown in Figure 3 below. This will wipe (delete all partitions from) the first disk on your system and install Vista on this disk using the partition info you provide next.

Figure 3: Wiping all partitions from disk 0.
Select the Microsoft-Windows-Setup\DiskConfiguration\Disk\CreatePartitions\Crea tePartition node in your answer file and specify true for Extend, 1 for Order, and select Primary for Type as shown in Figure 4 below. This will create a new primary partition that fills disk 0.

Figure 4: Creating a primary partition that fills the disk.
Next, select the Microsoft-Windows-Setup\DiskConfiguration\Disk\ModifyPartitions\Modi fyPartition node in your answer file and specify true for Active, select NTFS for Format, specify a label and drive letter, type 1 for Order, and specify 1 for the PartitionID setting as shown in Figure 5 below.

Figure 5: Creating and formatting the destination volume for your installation.
Next, add the Microsoft-Windows-Setup\WindowsDeploymentServices\ImageSelection\Ins tallImage and Microsoft-Windows-Setup\WindowsDeploymentServices\ImageSelection\Ins tallTo components to the windowsPE configuration pass of your answer file. Then select the Microsoft-Windows-Setup\WindowsDeploymentServices\ImageSelection\Ins tallImage node in your answer file and specify the filename of the install image you want to install, the name of the Image Group to which it belongs, and the name of the install image as displayed in the Windows Deployment Services console (see Figure 6):

Figure 6: Specifying which install image to deploy to the destination computer.
Now select the Microsoft-Windows-Setup\WindowsDeploymentServices\ImageSelection\Ins tallTo of your answer file and specify that the install image you specified earlier should be installed onto partition 1 of disk 0 as shown in Figure 7:

Figure 7: The image will install to partition 1 of disk 0.
Finally, add the Microsoft-Windows-Setup\WindowsDeploymentServices\Login\Credentials component to the windowsPE configuration pass of your answer file and specify domain user credentials for performing the install (Figure 8):

Figure 8: Specifying credentials for the destination computer to connect to the Windows DS server.
Validate your answer file and save it as Unattend.xml. Then copy your answer file to the \RemoteInstall\WdsClientUnattend folder on the image repository volume on your Windows DS server, which in this walkthrough is the W:\RemoteInstall\WdsClientUnattend folder on server SEA-WDS2. Then, using the Windows DS console, display the properties of the server, select the Client tab, select the Enable Unattended Installation checkbox, click the Browse button for your architecture, and browse to W:\RemoteInstall\WdsClientUnattend\Unattend.xml and click OK. This configures your Windows DS server to use your answer file to automate the first portion of the deployment process (see Figure 9):

Figure 9: Associating the Unattend.xml file with the Windows DS client.
Creating and Configuring ImageUnattend.xml

Now let us create and configure our second answer file, which will automate the Windows Welcome process. Start with a new (blank) answer file and add the Microsoft-Windows-Shell-Setup component to the specialize configuration pass section. Then configure the TimeZone setting, type "*" (asterisk) for ComputerName to autogenerate the computer name of the destination system, and (optionally) other settings as desired as shown in Figure 10:

Figure 10: Specifying the time zone and computer name.
Now add the Microsoft-Windows-International-Core component to the oobeSystem configuration pass and configure local/language settings as shown in Figure 11:

Figure 11: Specifying the local/language.
Next add the Microsoft-Windows-Shell-Setup\OOBE component to the oobeSystem configuration pass section of your answer file and configuring the settings for EULA, network location, and PC Protection as shown in Figure 12 below. (Note that the Network Location setting shown here doesn't "take" when configured via an answer file and you'll be prompted to select your network location when you first log on to your computer.)

Figure 12: Configuring OOBE settings for network location, EULA, and PC Protection.
Next, add the Microsoft-Windows-Shell-Setup\UserAccounts\LocalAccounts\LocalAccount\Pass word component to the oobeSystem configuration pass section of your answer file. Then select the Microsoft-Windows-Shell-Setup\UserAccounts\LocalAccounts\LocalAccount node and create a new local administrator account for the destination computer as shown in Figure 13:

Figure 13: Creating a local administrator account.
And do not forget to specify a password for your new account (Figure 14):

Figure 14: Specifying a password for the account.
Now validate and save your answer file as Unattend.xml and copy the file to your Windows DS server using removable media or some other method. In the Windows Deployment Services Console, right-click on the install image you want to deploy and select Properties, and on the General tab select the Allow Image To Install in Unattended Mode checkbox as shown in Figure 15:

Figure 15: Allowing an install image to install in unattended mode.
Click the Select File button and browse to the answer file you created above (Figure 16):

Figure 16: Select the answer file that will automate Windows Welcome.
Clicking OK creates a folder with the same name (cap3) as your install image file (cap3.wim) and a subfolder named Unattend beneath, and copies your Unattend.xml file to this Unattend folder, renaming the file as ImageUnattend.xml (Figure 17):

Figure 17: Copying the Windows Welcome answer file to the image repository.
Performing the Unattended Install

We're now ready to perform our unattended install of Windows Vista Enterprise onto our bare-metal PXE-enabled destination computer. Configure your destination computer to boot from the network, turn it on, and press F12 when prompted (Figure 18):

Figure 18: Press F12 to begin the deployment process.
Then when the Windows Boot Manager menu is displayed, select server SEA-WDS2 as shown in Figure 19:

Figure 19: Select the Windows DS server you want to use for your deployment.
Go make some coffee now and have a piece of cake. When you come back, enter your user credentials at the Windows logon screen as shown in Figure 20 and enjoy your game of FreeCell.

Figure 20: The deployment is complete—log on and enjoy your game of FreeCell

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part24.html

Introducing Microsoft Deployment Toolkit

The Windows AIK provides a collection of tools and documentation for performing unattended installs of Windows Vista, but these tools are not integrated with one another. For instance, you must use one tool (Windows SIM) to create your answer file, another tool (ImageX) to capture an image of your sysprepped reference computer, yet another tool (Package Manager) to service your images, another tool (WinPE) to boot your bare-metal destination computers, and so on. By adding Windows DS to the mix, you can centralize the management and deployment of your images, but you still have to work with a collection of disparate tools to perform your deployment.
To simplify desktop deployment, Microsoft first created Microsoft Solution Accelerator for Business Desktop Deployment (BDD), an integrated toolset together with comprehensive guidance for deploying Windows Vista and the 2007 Office System. BDD went through several versions including:

• BDD 2.0 and 2.5 – Used for deploying Windows XP that was released in two editions: Standard edition for smaller midmarket customers, and Enterprise edition for larger organizations that had an Microsoft Systems Management Server 2003 infrastructure deployed.
• BDD 2007 – Used for deploying Windows XP, Windows Vista, and the 2007 Office System and released in a single edition for both midmarket and enterprise customers.

BDD has now morphed into Microsoft Deployment Toolkit 2008 (MDT 2008) which lets you deploy the following versions of Microsoft Windows:

• Windows Vista
• Windows XP Professional
• Windows Server 2008
• Windows Server 2003

In addition, you can use MDT 2008 to deploy the 2007 Microsoft Office system and Microsoft Office 2003 to your desktop computers.
MDT 2008 simplifies the task of deploying Windows Vista (the focus of this present series of articles) by providing the following benefits:

• Provides an integrated workspace from which you can perform hardware/software inventories, mitigate application compatibility issues, migrate user profiles, package and deploy applications, create and manage distribution shares and deployment points, and to build, service and deploy your images.
• Supports integration with Windows DS for centralized server-based deployments.
• Supports integration with your existing systems management infrastructures that use SMS 2003 and Microsoft System Center Configuration Manager 2007 (SCCM 2007).
• Allows you to customize various aspects of the deployment process to suit the needs of your organization.

Understanding LTI vs. ZTI

Depending on your infrastructure, MDT 2008 enables you to perform two basic types of deployments:

• Light Touch Installation (LTI) – Lets you deploy Vista without having any systems management infrastructure in place in your organization. LTI is an ideal solution for small to medium-sized organizations who need to deploy Vista to dozens or even hundreds of systems at a site or in a department. LTI deployments can be performed manually, partially unattended, or almost fully unattended as desired. In its simplest form, LTI can even be used to deploy Vista in a workgroup scenario from a single computer running Windows XP. For greater scalability, you can integrated MDT with Windows DS to perform centralized, server-based LTI deployments.
• Zero Touch Installation (ZTI) – Lets you deploy Vista by leveraging the capabilities of your existing SMS 2003 or SCCM 2007 infrastructure. ZTI deployments are usually completely automated in nature and are also usually integrated with Windows DS.

Note: This present series of articles will focus on LTI deployments of Windows Vista SP1 Enterprise Edition.
Types of Deployment Scenarios

MDT 2008 supports a variety of different deployment scenarios:

• New Computer Scenario – Deploy Vista onto a bare-metal system that has no operating system for a user who does not have an existing computer or user profile on your network. Use this scenario when deploying systems for new employees.
• Upgrade Computer Scenario – Upgrade a system running Windows XP to Windows Vista and retain the user's existing profile settings. Use this scenario when you have existing systems whose hardware will support running Vista.
• Refresh Computer Scenario – Re-image an existing system that is already running Vista in order to resolve problems the user is experiencing with her computer.
• Replace Computer Scenario – Deploy Vista onto a bare-metal system for a user who has an existing computer running Windows XP. During the deployment process, the user's existing profile settings and data are migrated from her old XP computer to her new Vista computer.

Note:This present series of articles will focus mainly on demonstrating the New Computer deployment scenario.
Installing MDT 2008

You can install MDT 2008 on x86 or x64 systems running the following operating systems:

• Windows Server 2008 Standard or Enterprise edition
• Windows Server 2003 SP1 or later Standard or Enterprise edition
• Windows Vista Business, Enterprise or Ultimate edition
• Windows XP Professional SP2 or later

Depending on the platform you choose to install upon, you may also need to download and install the .NET Framework 2.0, MMC 3.0, and various updates.
It's also a good idea to have a second hard disk drive in the computer you are installing MDT on so that you can use this drive to host MDT's distribution share and (depending on your setup) deployment point. This will be explained in more detail in the next article of this series.
Be sure you begin by downloading the latest version of MDT 2008, which at the time of writing is MDT 2008 Update 1. For the scenario used in this series of articles, we're going to install MDT on a server named SEA-MDT that is running Windows Server 2003 R2 SP2 and which belongs to the contoso.com domain. This means that the only additional software we need to preinstall on the system is the .NET Framework 2.0, which can be obtained from Microsoft Download Center.
Begin by downloading MicrosoftDeploymentToolkit_x86.msi or MicrosoftDeploymentToolkit_x64.msi as needed from here, and double-click on the Windows Installer package to launch the setup process (Figure 1):

Figure 1: Installing MDT 2008 Update 1
A complete install of both tools and documentation is selected by default (Figure 2):

Figure 2: Select installation options
Once you have finished installing MDT, launch the Deployment Workbench by clicking Start, All Programs, Microsoft Deployment Toolkit, Deployment Workbench (Figure 3):

Figure 3: The MDT Deployment Workbench
The Workbench is the integrated workspace from which you can perform all of your deployment-related tasks. As you can see from the above figure, the Workbench has four main areas:

• Information Center – Provides access to the Getting Started guide and other MDT documentation, news updates concerning MDT, and the latest version of MDT components (see Figure 5 below):
• Distribution Share – This is where you bring together your operating system installation files and package files, your application installation files, and any out-of-box device drivers you will need to perform your deployment.
• Task Sequences – This is where you define the steps that will take place during your deployment (essentially configuring your answer file).
• Deploy – this is where you create your deployment points (the actual sets of OS, app and driver files needed for performing your deployments) and the MDT database (stores configuration information used for customizing your deployments).

Figure 4: The Components node of the Workbench
Conclusion

In the next article of this series, we will prepare MDT for deploying Vista by adding some necessary components, creating the distribution share and adding Vista installation files to the share, creating a task sequence for a basic install of Vista, and creating a deployment point for our install

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part25.html

Introduction

In the previous article we installed Microsoft Deployment Toolkit 2008 (MDT 2008) and provided a brief overview of the Deployment Workbench, an integrated user interface from which you can perform deployment-related tasks. In this article we'll prepare MDT so we can use it to perform a basic deployment of Windows Vista Enterprise. As we prepare MDT, we'll learn about some of the basic tasks you will perform using the Workbench including:

• Adding components to MDT
• Creating the distribution share
• Populating the distribution share
• Creating a task sequence
• Creating a deployment point

In future articles of this series, we'll be examining these tasks in greater depth.
Adding Components to MDT

As Figure 1 below shows, the Components node under Information Center is where you can add additional components to your Workbench. Two such components are required:

• MSXML 6.0 – The Microsoft XML parser
• Windows Automated Installation Kit (Windows AIK) – Described earlier in article 1 of this series.

If required for your environment, you can also add other components to the Workbench including:

• User State Migration Tool (USMT) – Used to migrate user profile settings and data during desktop migration
• Application Compatibility Toolkit (ACT) – Used to verify whether your applications will be compatible with the latest version of Windows
• Microsoft Assessment and Planning Toolkit (MAP) – Used to inventory your computers to determine whether you can successfully upgrade or migrate to the latest version of Windows.
• Various other tools for managing volume licensing and planning migration to the latest version of Microsoft Office.

Figure 1: The Components node under Information Center.
Tip:Before you download any components, right-click on the Components node at the left and select Check For Updates to make sure the list of available components displayed in your Workbench is up to date. If newer versions of components are available, these can be either downloaded from the Internet or from a shared folder that you've previously populated on your network.
Begin by selecting MSXML 6.0 and Windows Automated Installation Kit 1.1 (for x86 or x64 as needed) and click Download to download these two components to your technician computer (the computer on which you have MDT installed). Once downloaded, these components will be displayed in the Downloaded section as shown in Figure 2 (note that downloading the Windows AIK may take some time):

Figure 2: MSXML 6.0 and Windows AIK 1.1 have been downloaded.
With MSXML 6.0 selected, click Browse to open an Explorer window showing the downloaded components as in Figure 3:

Figure 3: The downloaded components.
Double-click on msxml6.msi to install the MSXML parser, and when this is done return to the Workbench, select the Windows AIK, and click Install (Figure 4):

Figure 4: Installing the Windows AIK.
Once this is finished, you should see both components under Installed as shown in Figure 5:

Figure 5: Required components have been installed.
Creating the Distribution Share

Now you are ready to create your distribution share, which is the folder that will contain the source files for Windows Vista plus any packages, drivers, or applications you want to include in your install. Begin by right-clicking on the Distribution Share node and select Create Distribution Share Directory as shown in Figure 6:

Figure 6: Creating the distribution share.
In the Create Distribution Share Wizard, type or browse to the path of a folder on your local file system. By default, MDT suggests creating the folder C:\Distribution, but for this example we will create this folder on a separate volume named M: drive (see Figure 7).
Note:
The volume your distribution share is located on must have sufficient free space for your Vista source files and any application files, packages, and drivers you need to perform your deployments.

Figure 7: Specifying the distribution share.
Figure 8 shows the directory structure under your distribution share:

Figure 8: Structure of distribution share.
Populating the Distribution Share

Your next step is to populate your distribution share by adding operating system installation files, packages, drivers, and application files. Since we're only doing a basic Vista install, we'll just add Windows Vista SP1 Enterprise installation files to the share. Right-click on the Operating Systems node under Distribution Share and select New to launch the New OS Wizard as shown in Figure 9:

Figure 9: The New OS Wizard.
Insert your Windows Vista SP1 Enterprise CD into the CD-ROM drive of your technician computer, click Next, and specify the drive letter for your CD-ROM drive as shown in Figure 10:

Figure 10: Specify the location of the Vista source files.
Click Next and type a name for the directory that will contain the source files you are adding to the share (Figure 11):

Figure 11: Where Vista source files will be stored.
Once the wizard is finished, the source files will be displayed as available as shown in Figure 12:

Figure 12: Vista source files have been added to the distribution share.
If you right-click on the source files you added to your share and click Properties, you can display detailed information concerning the added files (Figure 13):

Figure 13: Properties of added source files.
In our example, the Vista source files will have been copied from the product CD to the following directory:
M:\Distribution Share\Windows Vista SP1 Enterprise
Creating a Task Sequence

Your next step is to create a task sequence, which is a sequence of scripted steps that MDT will perform during your deployment. Begin by right-clicking on the Task Sequences node in your Workbench and select New as shown in Figure 14:

Figure 14: Creating a new task sequence.
For Light Touch Installation (LTI) deployments, creating a task sequence is similar to configuring an unattend.xml answer file (and in fact leverages such an answer file under the hood). On the General Settings page of the New Task Sequence Wizard, type an ID (no spaces) for your new task sequence and also a name and description (Figure 15):

Figure 15: Naming the task sequence.
On the Select Template page, select Standard Client Task Sequence (Figure 16):

Figure 16: Selecting a template for your task sequence.
On the Select OS page, select the only operating system (Windows Vista SP1 Enterprise) that is currently available to install (Figure 17):

Figure 17: Select an OS to install.
Do not specify a product key since we'll assume you're using Key Management Service (KMS) hosts on your network to activate your volume-licensed Vista Enterprise computers (Figure 18):

Figure 18: Leave the product key unspecified.
On the OS Settings page, specify the name and organization of the user who will be using the computer (Figure 19):

Figure 19: Specifying OS settings.
On the Admin Password page, type the password for the local Administrator account that will be created on the computer (Figure 20):

Figure 20: Specify password for local Administrator account.
Once the wizard is finished, the task sequence will be displayed in your Workbench as shown in Figure 21:

Figure 21: Task sequence for a basic Vista Enterprise deployment.
You can display the properties of the task sequence by right-clicking on it and selecting Properties. We will examine how to configure task sequences in more detail in a future article in this series.
Creating a Deployment Point

You're almost done preparing your technical computer for deploying Vista. You just need to create a deployment point, which is a folder that contains all the files needed to deploy your Vista image (plus drivers, packages and applications if needed) onto a bare-metal system. Begin by right-clicking on the Deployment Points node under Deploy, and select New (Figure 22):

Figure 22: Creating a new deployment point.
On the Choose Type page of the New Deployment Point Wizard, select Lab Or Single-Server Deployment as shown in Figure 23. (We will examine the different types of deployment points in a future article)

Figure 23: Creating a lab deployment point.
Type LAB as the name of your new deployment point (Figure 24):

Figure 24: Naming the deployment point.
Continue through the next few pages of the wizard leaving the defaults specified until you get to the Network Share page (Figure 25). Note that the wizard will create a hidden share named Distribution for your distribution share M:\Distribution.

Figure 25: The deployment point is a hidden share on your server.
On the Configure User State page, select Do Not Save Data And Settings since this is a New Computer Scenario where the user did not previously have a computer (Figure 26):

Figure 26: No user data or settings for the New Computer Scenario.
Once the wizard is finished, you must update the new deployment point in order to actually create it. To do this, right-click on the new LAB deployment point and select Update (Figure 27):

Figure 27: Updating the deploying point.
An Update Deploy Point dialog box will display the progress (Figure 28):

Figure 28: The deployment point is being updated.
Updating the deployment point creates three new subdirectories under your M:\Distribution directory:

• Boot
• Captures
• Servicing

The Boot directory (Figure 29) contains Windows PE for your LTI deployment in two forms:

• An .iso image you can burn onto a CD or DVD to manually launch the install process on a bare-metal system.
• A .wim image you can add to the Boot Images folder in the image repository on a Windows Deployment Services (Windows DS) server (if you have one) so that you can automatically launch the install process on a PXE-enabled bare-metal system.

Figure 29: Updating the deployment point creates WinPE images you can use for LTI deployments.
Your technician computer is now ready to deploy Vista Enterprise using LTI deployment.
Conclusion

In this article we prepared MDT for deploying Vista by adding necessary components, creating the distribution share and adding Vista installation files to the share, creating a task sequence for a basic install of Vista, and creating a deployment point for our install. In the next article of this series, we will use MDT to deploy Vista onto a bare-metal destination computer using LTI.

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part26.html

In the previous article I have shown you how to prepare Microsoft Deployment Toolkit 2008 (MDT 2008), in order to use it to perform a basic deployment of Windows Vista Enterprise for the New Computer scenario. This article builds on the previous one by showing how to use MDT to actually perform the install using two approaches:

• Using MDT together with a Light Touch Windows PE CD.
• Using MDT together with a Windows Deployment Services (Windows DS) server.

Note:
The LTI deployments covered in this article are not fully automated. A future article in this series will show how to completely automate LTI deployments.
Installing Vista Using a Light Touch WinPE CD

In the previous article we created a LAB deployment point for LTI installs of Vista. When we updated our deployment point, it created a Boot folder within our distribution share. This Boot folder contains Windows PE images in two forms that we can use for performing our LTI deployments (see Figure 1):

• An .iso image we can burn onto a CD or DVD to manually launch the install process on a bare-metal system.
• A .wim image we can add to the Boot Images folder in the image repository on a Windows Deployment Services (Windows DS) server (if you have one) so that you can automatically launch the install process on a PXE-enabled bare-metal system.

Figure 1: Windows PE images you can use for LTI deployments
To install Windows Vista on a bare-metal destination computer using a Light Touch WinPE CD, begin by burning the LiteTouchPE_x86.iso file (or x64 file if you created that one instead) onto CD media. Then turn on your destination computer, insert the LTI WinPE CD, and press any key to boot from CD when prompted. At that point, Windows PE will load and initialize on the machine, after which, the Welcome Windows Deployment screen will be displayed as shown in Figure 2:

Figure 2: LTI deployment starts on the destination computer
Click on Run The Deployment Wizards To Install a New Operating System and then click Next. This launches the Deployment Wizard and displays the User Credentials screen where you specify domain user credentials (here CONTOSO\jchen) that can access the deployment point on your technician computer (Figure 3):

Figure 3: Specifying credentials that can access the deployment point on the computer that has MDT installed on it
Click OK. Then on the first screen of the Windows Deployment Wizard, select the task sequence you wish to use to govern the install. Since we only created one task sequence in the previous article, this is the only one displayed here in Figure 4:

Figure 4: Choose a task sequence to run on the destination computer
Click Next and specify a name for your new computer (see Figure 5). We will choose JCHEN-PC as the name of John Chen's new computer:

Figure 5: Specifying a name for the new computer
Click Next and select Join A Domain, then type CONTOSO (or something else depending on your environment) for the name of the domain the new computer will join (Figure 6):

Figure 6: Select the option to join a domain after installation is complete
Click Next and make sure Do Not Restore User Data And Settings is selected on the next page of the wizard (see Figure 7). We select this option because there are no user data or settings for John Chen because we are using the New Computer scenario (John has just joined the company and this will be his computer).

Figure 7: Select the option not to restore user data and settings
Click Next and specify the locale and keyboard layout for John's computer (Figure 8):

Figure 8: Specify locale and keyboard layout
Click Next and specify the timezone for John's machine (Figure 9):

Figure 9: Specifying the time zone
Click Next and select Do Not Enable BitLocker For This Computer since John's PC is a desktop computer not a laptop (Figure 10):

Figure 10: Configuring BitLocker settings
Click Next, click Details, and review the settings to be used for the installation. When ready to begin the install, click Begin (Figure 11):

Figure 11: Review installation settings
At this point an Installation Progress dialog box will display the progress of the installation. The first action performed will be to partition and format the disk (Figure 12):

Figure 12: The hard disk is being partitioned and formatted
After that, Windows Setup will proceed in the usual way by copying the Windows image file to the destination computer, installing the image, and performing the remaining installation steps (Figure 13):

Figure 13: The Windows image is being applied
Once the installation process is finished (there may be several reboots) the user will automatically be logged onto his computer using the built-in local Administrator account on the computer (the password for this account was specified when the task sequence was created—see the previous article in this series for details). Once the user's desktop appears, a Deployment Summary screen will be displayed (Figure 14):

Figure 14: The installation is finished
If you click Start, right-click on Computer, and select Properties, you can verify from the Full Computer Name displayed that computer JCHEN-PC is joined to the contoso.com domain as intended (Figure 15):

Figure 15: The computer is domain-joined as intended
Installing Vista Using Windows DS

Another way to perform an LTI deployment is to boot your destination computers using a boot image on a Windows DS server. To do this, you need to make sure that your destination computers have network cards that are PXE-enabled and that their BIOS has been configured to boot from the network first. Once you've ensured this is the case, you then must add the Light Touch boot image (.wim file) to the Boot Images folder on your Windows DS server. To do this, open the Windows DS console, expand the server node, right-click on the Boot Images folder and select Add Boot Image (Figure 16):

Figure 16: Adding the LTI boot image to your Windows DS server
In the Add Image Wizard, type \\technician_computer\distribution_share\Boot\LiteTouchPE_x86.wim to connect to the Boot folder in the distribution share on your technician computer. In this example, the technician computer is named SEA-MDT while Distribution$ is the name of the hidden distribution share on the computer (Figure 17):

Figure 17: Specify the path to the LTI boot image on the technician computer
Type a name and description for the boot image or accept the defaults (Figure 18):

Figure 18: Specify a name and description for the LTI boot image
Click Next and review the Summary page of the wizard (Figure 19):

Figure 19: Summary page of wizard
Click Next and the LTI boot image is added to the image repository on your Windows DS server (Figure 20):

Figure 20: Boot image is being added to the repository
The LTI boot image should now be visible in the Boot Images folder of your Windows DS server (Figure 21):

Figure 21: LTI boot image is ready for use for deploying Vista
Now, go to your destination computer and turn it on. When the computer acquires an IP address you will be prompted to press F12, after which you will be presented with a menu of boot images you can boot from. Select the Light Touch boot image, and after the image is downloaded and WinPE initializes you will be presented with the Welcome to Deployment screen shown earlier in Figure 2. From that point on the install continues in the same way as before when you booted your destination computer from the LTI WinPE CD earlier in this article.
Conclusion

In this article and the previous one we have seen how to manually perform a Light Touch Installation (LTI) of Windows Vista onto bare-metal hardware using Microsoft Deployment Toolkit 2008. In the next article of this series we will see how to completely automate LTI.
In the previous article I have shown you how to prepare Microsoft Deployment Toolkit 2008 (MDT 2008), in order to use it to perform a basic deployment of Windows Vista Enterprise for the New Computer scenario. This article builds on the previous one by showing how to use MDT to actually perform the install using two approaches:

• Using MDT together with a Light Touch Windows PE CD.
• Using MDT together with a Windows Deployment Services (Windows DS) server.

Note:
The LTI deployments covered in this article are not fully automated. A future article in this series will show how to completely automate LTI deployments.
Installing Vista Using a Light Touch WinPE CD

In the previous article we created a LAB deployment point for LTI installs of Vista. When we updated our deployment point, it created a Boot folder within our distribution share. This Boot folder contains Windows PE images in two forms that we can use for performing our LTI deployments (see Figure 1):

• An .iso image we can burn onto a CD or DVD to manually launch the install process on a bare-metal system.
• A .wim image we can add to the Boot Images folder in the image repository on a Windows Deployment Services (Windows DS) server (if you have one) so that you can automatically launch the install process on a PXE-enabled bare-metal system.

Figure 1: Windows PE images you can use for LTI deployments
To install Windows Vista on a bare-metal destination computer using a Light Touch WinPE CD, begin by burning the LiteTouchPE_x86.iso file (or x64 file if you created that one instead) onto CD media. Then turn on your destination computer, insert the LTI WinPE CD, and press any key to boot from CD when prompted. At that point, Windows PE will load and initialize on the machine, after which, the Welcome Windows Deployment screen will be displayed as shown in Figure 2:

Figure 2: LTI deployment starts on the destination computer
Click on Run The Deployment Wizards To Install a New Operating System and then click Next. This launches the Deployment Wizard and displays the User Credentials screen where you specify domain user credentials (here CONTOSO\jchen) that can access the deployment point on your technician computer (Figure 3):

Figure 3: Specifying credentials that can access the deployment point on the computer that has MDT installed on it
Click OK. Then on the first screen of the Windows Deployment Wizard, select the task sequence you wish to use to govern the install. Since we only created one task sequence in the previous article, this is the only one displayed here in Figure 4:

Figure 4: Choose a task sequence to run on the destination computer
Click Next and specify a name for your new computer (see Figure 5). We will choose JCHEN-PC as the name of John Chen's new computer:

Figure 5: Specifying a name for the new computer
Click Next and select Join A Domain, then type CONTOSO (or something else depending on your environment) for the name of the domain the new computer will join (Figure 6):

Figure 6: Select the option to join a domain after installation is complete
Click Next and make sure Do Not Restore User Data And Settings is selected on the next page of the wizard (see Figure 7). We select this option because there are no user data or settings for John Chen because we are using the New Computer scenario (John has just joined the company and this will be his computer).

Figure 7: Select the option not to restore user data and settings
Click Next and specify the locale and keyboard layout for John's computer (Figure 8):

Figure 8: Specify locale and keyboard layout
Click Next and specify the timezone for John's machine (Figure 9):

Figure 9: Specifying the time zone
Click Next and select Do Not Enable BitLocker For This Computer since John's PC is a desktop computer not a laptop (Figure 10):

Figure 10: Configuring BitLocker settings
Click Next, click Details, and review the settings to be used for the installation. When ready to begin the install, click Begin (Figure 11):

Figure 11: Review installation settings
At this point an Installation Progress dialog box will display the progress of the installation. The first action performed will be to partition and format the disk (Figure 12):

Figure 12: The hard disk is being partitioned and formatted
After that, Windows Setup will proceed in the usual way by copying the Windows image file to the destination computer, installing the image, and performing the remaining installation steps (Figure 13):

Figure 13: The Windows image is being applied
Once the installation process is finished (there may be several reboots) the user will automatically be logged onto his computer using the built-in local Administrator account on the computer (the password for this account was specified when the task sequence was created—see the previous article in this series for details). Once the user's desktop appears, a Deployment Summary screen will be displayed (Figure 14):

Figure 14: The installation is finished
If you click Start, right-click on Computer, and select Properties, you can verify from the Full Computer Name displayed that computer JCHEN-PC is joined to the contoso.com domain as intended (Figure 15):

Figure 15: The computer is domain-joined as intended
Installing Vista Using Windows DS

Another way to perform an LTI deployment is to boot your destination computers using a boot image on a Windows DS server. To do this, you need to make sure that your destination computers have network cards that are PXE-enabled and that their BIOS has been configured to boot from the network first. Once you've ensured this is the case, you then must add the Light Touch boot image (.wim file) to the Boot Images folder on your Windows DS server. To do this, open the Windows DS console, expand the server node, right-click on the Boot Images folder and select Add Boot Image (Figure 16):

Figure 16: Adding the LTI boot image to your Windows DS server
In the Add Image Wizard, type \\technician_computer\distribution_share\Boot\LiteTouchPE_x86.wim to connect to the Boot folder in the distribution share on your technician computer. In this example, the technician computer is named SEA-MDT while Distribution$ is the name of the hidden distribution share on the computer (Figure 17):

Figure 17: Specify the path to the LTI boot image on the technician computer
Type a name and description for the boot image or accept the defaults (Figure 18):

Figure 18: Specify a name and description for the LTI boot image
Click Next and review the Summary page of the wizard (Figure 19):

Figure 19: Summary page of wizard
Click Next and the LTI boot image is added to the image repository on your Windows DS server (Figure 20):

Figure 20: Boot image is being added to the repository
The LTI boot image should now be visible in the Boot Images folder of your Windows DS server (Figure 21):

Figure 21: LTI boot image is ready for use for deploying Vista
Now, go to your destination computer and turn it on. When the computer acquires an IP address you will be prompted to press F12, after which you will be presented with a menu of boot images you can boot from. Select the Light Touch boot image, and after the image is downloaded and WinPE initializes you will be presented with the Welcome to Deployment screen shown earlier in Figure 2. From that point on the install continues in the same way as before when you booted your destination computer from the LTI WinPE CD earlier in this article.
Conclusion

In this article and the previous one we have seen how to manually perform a Light Touch Installation (LTI) of Windows Vista onto bare-metal hardware using Microsoft Deployment Toolkit 2008. In the next article of this series we will see how to completely automate LTI.

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part27.html

Introduction

This series of articles on automating Windows Vista deployment continues by walking through how to completely automate a Light Touch Installation of Windows Vista using Microsoft Deployment Toolkit 2008.
In the previous two articles we saw how to manually perform a Light Touch Installation (LTI) of Windows Vista Enterprise for the New Computer scenario. This present article shows how to completely automate the LTI process for the New Computer scenario.
Understanding Configuration Files

MDT 2008 automates the deployment process by using several different scripts. These scripts in turn are themselves controlled by settings you can define in configuration files. These configuration files are plaintext files that use the INI file format. The configuration files used by MDT are these:

• CustomSettings.ini – This is the main configuration file used for controlling the scripts that automate the deployment process.
• BootStrap.ini – This is an additional configuration file that is primarily needed for the New Computer and Replace Computer scenarios to ensure the target computer can connect to your deployment point in order to begin the deployment process.

Let us examine what these two configuration files look like in the lab environment we used in the previous three articles. Begin by opening the Deployment Workbench and expanding the Deploy node to display the Deployment Points node beneath it. Then right-click on the LAB deployment point we created previously and select Properties (see Figure 1):

Figure 1: Displaying the properties of a deployment point
In the LAB Properties dialog that opens, select the Rules tab (Figure 2):

Figure 2: Rules tab shows contents of CustomSettings.ini file
The Rules tab displays the contents of the CustomSettings.ini configuration file for that deployment point. You can also view this information by opening Windows Explorer and browsing to the M:\Distribution\Control folder and double-clicking on the CustomSettings.ini file to open it in Notepad. You can see that this file has the standard INI format with sections defined by square brackets (e.g. [Settings]) and name/value pairs in each section (e.g. Priority=Default).
To view the contents of the Bootstrap.ini file, click the Edit Bootstrap.ini button at the bottom right of the Rules tab. Doing this opens the Bootstrap.ini file in Notepad (Figure 3):

Figure 3: Contents of Bootstrap.ini file
Understanding Rules

MDT refers to these name/value pairs on each line of these configuration files as rules. MDT also calls the left-hand side of each rule a property. By adding or removing rules, you can customize how the scripts work that drive the MDT deployment process. These scripts also create and configure additional properties that cannot be specified in configuration files.
Key to being able to customize how MDT deployments work, is knowing what each property does and how to configure it. The best way of becoming familiar with these is to read through the Properties section of the Microsoft Deployment Toolkit Reference found here. This may seem to be dry reading, but it is worthwhile reading it through carefully as you will learn a lot about how to customize LTI deployments.
Automating Light Touch Installation

Let us now look at how we can automate the LTI process for deploying Windows Vista SP1 Enterprise. We are going to use the same environment we set up in the last two articles, so review these articles first if you need to.
Begin by opening the Rules tab shown previously for the LAB deployment point. Select all the text within this tab and delete, then paste the following text into the tab:
[Settings]
Priority=Default
Properties=MyCustomProperty
[Default]
OSInstall=YES
DeployRoot=\\SEA-MDT\Distribution$
SkipAdminPassword=YES
SkipApplications=YES
SkipAppsOnUpgrade=YES
SkipBDDWelcome=YES
SkipBitLocker=YES
SkipBitLockerDetails=YES
SkipTaskSequence=YES
SkipCapture=YES
SkipComputerBackup=YES
SkipComputerName=YES
SkipDeploymentType=YES
SkipDomainMembership=YES
SkipFinalSummary=YES
SkipLocaleSelection=YES
SkipPackageDisplay=YES
SkipProductKey=YES
SkipSummary=YES
SkipTaskSequence=YES
SkipTimeZone=YES
SkipUserData=YES
UserID=jchen
UserDomain=CONTOSO
UserPassword=Pa$$w0rd
KeyboardLocale=en-US
DeploymentType=NEWCOMPUTER

TaskSequenceID=TEST-001
UILanguage=en-US
UserLocale=en-US
SkipTimeZone=Yes
TimeZoneName=Central Standard Time
JoinDomain=CONTOSO
DomainAdmin=Administrator
DomainAdminDomain=CONTOSO
DomainAdminPassword=Pa$$w0rd
The Rules tab should now look something like this (Figure 4):

Figure 4: CustomSettings.ini file used for automating LTI
We will examine what these various rules do in a moment. But first, click Apply to save the changes to your CustomSettings.ini file.
Now continue by opening your Bootstrap.ini file in Notepad and changing the contents to look like this (Figure 5):

Figure 5: Bootstrap.ini file used for automating LTI
Once again, we will discuss what these rules mean in a moment. But first, select File, then Save to save the changes to your Bootstrap.ini file, then close Notepad and click OK to close the LAB Properties dialog.
Now, in your Deployment Workbench, right-click on your LAB deployment point and select Update (Figure 6):

Figure 6: Updating the deployment point
Updating a deployment point does two things:

• Updates your configuration files and associated scripts with the changes you have made.
• Generates new Light Touch Windows PE boot images (.wim and .iso files) in your distribution share.

Note:
If you have not made any changes to the DeployRoot property or to the credentials (UserID, UserDomain, UserPassword) then you can select Update (Files Only) instead of Update. Doing this updates your configuration files and scripts, but does not generate new WinPE boot images. Either way, you must update your deployment point whenever you make changes to your configuration files.
Performing the Installation

You have made the appropriate changes to your configuration files and you have also updated your deployment point. If you generated new WinPE boot images, you need to use these to initiate your deployment, so either burn the .iso file to a CD and boot your target computer using this CD, or add the .wim file to the Boot Images folder of your Windows Deployment Services server if you are using that approach—see the previous two articles in this series for details.
Once you boot your bare-metal target computer, either by inserting the WinPE boot CD or by PXE-booting it from your Windows DS server, the LTI deployment process will begin, only instead of seeing this screen which you saw in the previous article (Figure 7):

Figure 7: The Windows Deployment wizard will NOT be displayed!
which was followed by a number of wizard screens where you had to provide input, this time the wizard will be skipped entirely and you'll see this screen instead (Figure 8):

Figure 8: This is what you will see when you automate the LTI process
In other words, the install begins automatically with no user prompts required, and after a couple of reboots you'll be logged on automatically to Vista using the default Administrator account. You can then log off as Administrator and log on as a domain user to verify that the computer has been successfully joined to your domain. You have just successfully performed a completely automated LTI deployment of Vista Enterprise.
Understanding the Bootstrap.ini File

In order to perform a completely automated LTI deployment for the New Computer scenario from a Lab deployment point, your Bootstrap.ini file must look something like this (I have inserted comments prefixed by semicolons each rule or set of rules for explanatory purposes):
[Settings]
Priority=Default
[Default]
DeployRoot=\\SEA-MDT\Distribution$
; REQUIRED—Specify the deployment point you wish to connect the target computer to.
UserID=jchen
UserDomain=CONTOSO
UserPassword=Pa$$w0rd
; REQUIRED—Specify domain user credentials for connecting to the deployment point.
; Note that the password is unencrypted so be sure to safeguard this file!
KeyboardLocale=en-US
; REQUIRED—Specify your keyboard locale setting.
SkipBDDWelcome=YES
; REQUIRED—This rule causes the Welcome page of the wizard to be skipped.
Understanding the CustomSettings.ini File

In order to perform a completely automated LTI deployment for the New Computer scenario from a Lab deployment point, your CustomSettings.ini file should look something like this (once again I've inserted comments after each rule or set of rules for explanatory purposes):
[Settings]
Priority=Default
Properties=MyCustomProperty
[Default]
OSInstall=YES
; Authorizes deploying an OS onto the target computer.
DeployRoot=\\SEA-MDT\Distribution$
; REQUIRED—See previous section above.
SkipAdminPassword=YES
SkipApplications=YES
SkipAppsOnUpgrade=YES
SkipBDDWelcome=YES
SkipBitLocker=YES
SkipBitLockerDetails=YES
SkipTaskSequence=YES
SkipCapture=YES
SkipComputerBackup=YES
SkipComputerName=YES
SkipDeploymentType=YES
SkipDomainMembership=YES
SkipFinalSummary=YES
SkipLocaleSelection=YES
SkipPackageDisplay=YES
SkipProductKey=YES
SkipSummary=YES
SkipTaskSequence=YES
SkipTimeZone=YES
SkipUserData=YES
; REQUIRED—These rules prevent various pages of the Windows Deployment wizard from being displayed.
UserID=jchen
UserDomain=CONTOSO
UserPassword=Pa$$w0rd
; REQUIRED—See previous section above.
KeyboardLocale=en-US
; REQUIRED—See previous section above.
DeploymentType=NEWCOMPUTER
; Specifies that the New Computer deployment scenario is being performed.
TaskSequenceID=TEST-001
; This rule idenfies the task sequence being used to perform the deployment.
UILanguage=en-US
UserLocale=en-US
SkipTimeZone=Yes
TimeZoneName=Central Standard Time
; These rules are pretty self-explanatory.
JoinDomain=CONTOSO
DomainAdmin=Administrator
DomainAdminDomain=CONTOSO
DomainAdminPassword=Pa$$w0rd
; These rules join the target computer to the domain once the install is finished.
Conclusion

In this article we have seen how to completely automate the LTI process for the New Computer scenario when using MDT 2008 to deploy Windows Vista SP1 Enterprise onto bare-metal hardware. The next few articles of this series will dig deeper into how to customize various aspects of MDT deployments

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part28.html

The previous four articles in this series introduced you to Microsoft Deployment Toolkit 2008 (MDT 2008) using two walkthroughs, one that could be used to deploy Windows Vista manually to a bare-metal destination computer, and another that showed you how you could automate the installation process. This present article and several following it will dig deeper into configuring various aspects of MDT 2008.
Understanding Distribution Shares

As you learned in the previous articles, the distribution share is the place in MDT where you bring together your operating system installation files and package files, your application installation files, and any out-of-box device drivers you will need to perform your deployment. The distribution share is therefore where all of your installation-related files will reside, including various configuration files used by MDT for performing Light-Touch Installation (LTI) deployments. Let us examine how to create a distribution share and how to populate the share with operating system images, drivers, packages, and applications.
Creating the Distribution Share

Before you create your distribution share, make sure you have enough disk space available for all the installation files that will be stored in it. Then to create your distribution share, open your Deployment Workbench, right-click on the Distribution Share node and select Create Distribution Share Directory from the shortcut menu as shown in Figure 1:

Figure 1: Creating your distribution share
By default MDT prompts you to locate your distribution share folder on your boot volume (see Figure 2):

Figure 2: Specifying the location of your distribution share folder
You will probably want to use a separate disk volume for your distribution share. Click Finish to create your distribution share folder.
Note:
The option for upgrading your distribution share is for when you are upgrading from BDD to MDT.
Adding Operating System Installation Files to the Distribution Share

Once you have created your distribution share, your next task is to add operating system installation files to it. To add OS installation files, right-click on the Operating Systems node under Distribution Share and select New from the shortcut menu. This launches the New OS wizard as shown in Figure 3:

Figure 3: Adding OS installation files to your distribution share
Using this wizard, you can add the following types of OS installation files to your distribution share:

• The OS installation files found on your Windows Vista or Windows Server 2008 product DVD media.
• A custom .wim file that you've captured from a sysprepped reference computer that you've suitably configured.
• An install image located in the image repository on a Windows Deployment Services (Windows DS) server somewhere on your network.

If you choose the first option in Figure 3 above, you first specify the drive letter of the DVD-ROM drive that has your product DVD media in it. Then you give your OS installation files a descriptive name like "Windows Vista SP1 Enterprise x86" as appropriate. Note that adding OS installation files to your distribution share can take several minutes.
If you choose the second option, you first specify the location of your custom .wim file. Then you are presented with the choices showin in Figure 4:

Figure 4: Adding a custom .wim file to your distribution share
As long as you have already added OS installation files for the OS your custom .wim file uses, you can leave the first choice selected here. But if you captured an image of an OS whose installation files have not previously been added to your distribution share, then you must choose the second option.
The third option (Windows DS) is a bit more complicated so we will examine it in a future article where we will examine how to integrate MDT with Windows DS.
Note:
Once you have added your OS installation files to your distribution share, they will be listed in the details pane (Figure 5):

Figure 5: A distribution share with various OS installation files added
Note that only four product DVD media were used to populate the Operating Systems node of this distribution share:

• Windows Vista SP1 Enterprise x86
• Windows Vista SP1 Enterprise x64
• Windows Server 2008 x86
• Windows Vista SP1 Retail x86

Why then are there 15 different operating systems here? Because a single install image (.wim file) on a product DVD can contain multiple editions of the operating system. You can view additional details concerning each operating system by scrolling to the right in the details pane of your Deployment Workbench. You can also view the details of a single operating system by right-clicking on it and selecting Properties (Figure 6):

Figure 6: Properties of an operating system
Adding Out-of-Box Device Drivers to the Distribution Share

If the operating system you are going to deploy does not have in-box device drivers for all of your destination computer's hardware, you can use the Deployment Workbench to add additional out-of-box device drivers as needed to your distribution share. For example, you may need to add out-of-box drivers for boot-critical SCSI adapters so that Setup can detect the fixed disks and install Windows.
To add an out-of-box device driver, right-click on the Out-of-Box Drivers node under Distribution Share and select New to launch the New Driver Wizard. Browse to the location where the driver files (.inf and other files) are located (Figure 7):

Figure 7: Adding an out-of-box device driver to your distribution share
You can typically assign your driver to the All Drivers driver group. Otherwise create a new driver group and add your driver to it if you plan on using different driver groups for installing to different types of hardware, but note that if you do this then you must edit your CustomSettings.ini file accordingly for this to work.
Once you have added your drivers to your distribution share, they will be displayed in the details pane as shown in Figure 8:

Figure 8: Out-of-box drivers have been added to the distribution share
To view details concerning a driver, right-click on it and select Properties (Figure 9):

Figure 9: Properties of a driver
Note:
By default, any drivers you add to the share are enabled. You can disable a driver by deselecting the checkbox at the bottom left of Figure 9 above. You can also delete a driver from the share if it is no longer needed by right-clicking on the driver and selecting Delete.
Conclusion

This article has shown you how to create a distribution share and add operating system installation files and device drivers to the share. The next article in this series will continue by examining how to add packages and applications to a distribution share

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part29.html

Introduction

The previous article examined how to create a distribution share in MDT 2008 and how to add operating system installation files and device drivers to it. This article continues from the previous one by examining how to add packages and applications to a distribution share.
Adding Packages to the Distribution Share

You can also add packages to your distribution share so they can be installed when you deploy Vista using MDT. A package or Windows package file may contain security updates, hotfixes, language packs, or other software. Packages for Windows Vista or Windows Server 2008 typically have the .msu file name extension and contain one or more .cab files (each .cab representing one update), an .xml manifest describing the contents of the package, a plaintext properties file, and possibly other metadata. Packages for language packs however are simple .cab files.
To add a package to your distribution share, right-click on the OS Packages node and select New to launch the New Package wizard, then browse to the folder where your .msu or .cab file is located (Figure 1):

Figure 1: Adding a package to your distribution share
Once packages have been added, they are displayed in the details pane of Workbench (Figure 2):

Figure 2: Packages added to a distribution share
To view detailed properties of a package, right-click on it and select Properties (Figure 3):

Figure 3: Detailed properties of a package
Note:
You can enable or disable a package by selecting or deselecting the checkbox at the bottom of the General tab above.
The Groups tab lets you assign the package to a specific package group. By default, all packages are assigned to the All Packages package group, but you can create additional package groups if needed. Package groups are useful if you will be deploying multiple operating systems or operating system version levels and these OSes or OS version levels use different packages or package levels. For instance, a language pack that applies to Windows Vista RTM would not apply to a language pack that applies to Windows Vista SP1 (see Figure 4).

Figure 4: Creating a new package group for packages that apply to Vista SP1
Adding Applications to the Distribution Share

You can also add applications to your distribution share so they can be installed when you deploy Vista using MDT. To deploy an application you will need the Windows Installer (.msi) file for the application so you can install it silently using the msiexec /qn /i command.
As an example, let us add the Microsoft Office Live Meeting 2007 client application to our distribution share. Begin by downloading the executable Setup file for the application from Office Online. This Setup file is named LMSetup.exe and once you have it you must extract the .msi file from the Setup file by typing the following at a command prompt:
LMSetup.exe –out <path_to_folder>
Executing this command extracts the file LMConsole.msi into the folder specified. Now copy this .msi file onto removable media or a network share and you are ready to add it to your distribution share. Begin by right-clicking on the Applications node in your Workbench and selecting New to launch the New Application Wizard (Figure 5):

Figure 5: Adding an application to your distribution share
If you have an .msi file to install your application, choose the first option in the screen above and continue as shown below. If the source files for your application are located somewhere on your network and you just need to run a command on the destination computer to install the application, choose the second option.
Click Next and specify a name for the application and optionally the application's publisher, version and language (Figure 6):

Figure 6: Specify a name for the application
Click Next and browse to the local or network folder where the .msi file is located (Figure 7):

Figure 7: Specify the location of the .msi file
Click Next and either accept the default name for the local directory that will be created for the .msi file, or enter a different name if preferred (Figure 8):

Figure 8: Specify the name of the folder where the .msi file will be locally stored on your technician computer
Click Next and enter the command that will silently install the application on the destination computer (Figure 9):

Figure 9: Specify the command that will silently install the application
Click Finish to import the application into your distribution share. Imported applications will be displayed in the details pane of your Workbench as shown in Figure 10:

Figure 10: Applications that have been added to the distribution share
You can right-click on the imported application and select Properties to display detailed properties for the application. The General tab displays the application's name, the application's source directory on your technician computer, and other information (Figure 11):

Figure 11: General tab of an application's properties
Note:
You can enable or disable an application on the General tab.
The Details tab displays the command used to silently install the application and other information (Figure 12):

Figure 12: Details tab of an application's properties
The Dependencies tab is used to manage dependencies when the order in which applications are installed is important. You can manage your imported applications by editing their properties, enabling or disabling them, or removing them from your distribution share if desired.
Note:
Do not configure an application to reboot the computer after it is installed or the task sequence used by MDT to deploy Windows will be unable to complete its tasks and the deployment will fail.
Examining the Distribution Share

Figure 13 shows the structure of the distribution share after adding the operating system installation files, device drivers, packages and applications described in this article and the previous one:

Figure 13: Typical structure of a distribution share on the technician computer
Examining the Resulting Installation

At this point you can follow the procedure outlined in part 25 and part 26 of this series to test your populated distribution share as follows:

1. Create a task sequence.
2. Create a Lab deployment point.
3. Update your deployment point.
4. Burn the WinPE .iso file to a CD.
5. Boot a bare-metal system using the CD.
6. Follow the prompts of the Windows Deployment Wizard to install Windows Vista SP1 Enterprise together with the device drivers, packages and applications you populated your distribution share with.

The Windows Deployment Wizard will ask you whether to install the additional language pack (on the Package page of the wizard) and whether you want to install Microsoft Live Meeting 2007 (on the Select One Or More Applications To Install page). For example, after the desktop appears on our destination computer, a dialog is displayed indicating that the Live Meeting client is being installed (Figure 14):

Figure 14: The application is being installed
Once installation is finished, you can verify from the Start Menu that the application is available (Figure 15):

Figure 15: The application has been installed
You can use Programs in Control Panel to verify that the package for the KB942288 hotfix shown in Figure 2 above has been installed (Figure 16):

Figure 16: The package has been installed
You can verify from Regional and Language Options in Control Panel that the additional language pack is available on the system (Figure 17):

Figure 17: The language pack has been installed
And you can verify from Device Manager that the device driver has been installed (Figure 18):

Figure 18: The device driver has been installed
Conclusion

This article and the previous one have explored how to create and populate the distribution share on your technician computer. The next article will examine how to create and configure deployment points

[patris1]

http://www.windowsnetworking.com/articles_tutorials/Deploying-Vista-Part30.html

The previous two articles examined how to create a distribution share in MDT 2008 and how to add operating system installation files, device drivers, packages and applications to it. This article examines the different types of deployment points you can create for MDT and how to configure them.
Types of Deployment Points


Once you have created your distribution share using the Deployment Workbench, you can create your deployment points. The difference between them is that your distribution share contains everything needed for all your deployments—operating system images, device drivers, packages, and applications—while deployment points may contain only a subset of those files, depending on the type of deployment point. And while you can only create one distribution share in MDT, you can create more than one deployment point, depending on the needs of your environment.
MDT 2008 allows you to create four different types of deployment points:

• Lab or single-server deployment (Lab) – This is the simplest type of deployment point and basically just shares out your entire distribution share folder as a hidden share. For example, if your distribution share folder is the default (C:\Distribution) then your Lab deployment point is simply the \\technician_computer\Distribution$ share. You must create a Lab deployment point before you create any other type of deployment point, and you can only create one Lab deployment point for your environment. You will typically have more than one environment of course—one for testing, one for piloting, one for production—so each environment you have will need its own technician computer and its own Lab deployment point. Another reason that the Lab deployment point is important is because you can use it to create bootable Windows PE media that you can use to boot destination computers to begin the installation process on them.
• Separate deployment share (Network) – This type of deployment point is a shared folder either on your technician computer or (more usefully) on a network file server. You typically create one or more of this type of deployment point to add redundancy to your deployment environment or to improve performance by load-balancing multiple deployment shares in larger environments. Separate deployment shares only contain a subset of the files contained in your Lab or single-server deployment point.
• Removable media (Media) – This type of deployment point can be used for performing deployment when the destination computers are not on a network. You can copy your deployment files to a USB storage device such as a flash drive, or you can burn it to a DVD and use it to deploy Windows onto the destination computers.
• SMS 2003 OSD – Unlike the previous three kinds of deployment points which are all used for Light Touch Installation (LTI) deployments, this fourth type of deployment point is used for Zero Touch Installation (ZTI) deployments that use Microsoft Systems Management Server (SMS) 2003 together with the SMS 2003 Operating System Deployment (OSD) Feature Pack. Note that you must still create a Lab deployment point before you can create your SMS 2003 OSD deployment point.

Note:
This present series of articles focuses on LTI deployments of Windows Vista—in a future series of articles I'll examine deploying Windows 7 using Microsoft System Center Configuration Manager 2007.
Creating a Lab Deployment Point


Creating a Lab deployment point on your technician computer is straightforward. Open the Deployment Workbench, right-click on the Deployment Points node under Deploy, and select New to launch the New Deployment Point Wizard. Select Lab or Single-Server Deployment as shown in Figure 1:

Figure 1: Creating a Lab deployment point
Next give your deployment point a descriptive name (Figure 2):

Figure 2: Give the deployment point a descriptive name
The next page of the wizard lets you configure whether users will be allowed to install additional applications during an upgrade computer scenario. If you select the checkbox shown in Figure 3 below, the Windows Deployment Wizard running on the destination computer will display a page that prompts the user to select additional applications to install. Leaving the checkbox cleared will suppress this wizard page:

Figure 3: Allow users to select additional applications on upgrade
If you select the checkbox on the next page shown in Figure 4 below, the Windows Deployment Wizard running on the destination computer will display a page that lets you choose whether to capture an image of the destination computer after the operating system has been deployed onto the system:

Figure 4: Allow image capture
If the checkbox is selected on the next page (Figure 5) the Windows Deployment Wizard running on the destination computer will display a page that prompts the user to specify the password for the local Administrator account for the destination computer:

Figure 5: Specify the local Administrator password
If the checkbox is selected on the next page (Figure 6) the Windows Deployment Wizard running on the destination computer will display a page that prompts the user to specify the product key for the destination computer:

Figure 6: Specify the product key
The next page of the New Deployment Point Wizard is called Network Share, but for a Lab deployment point what you're really specifying here is the share name for the distribution share folder (see Figure 7). By default, the C:\Distribution folder is shared as a hidden share named Distribution$:

Figure 7: Network share page
The next page shown in Figure 8 specifies how user state information should be migrated during an Upgrade Computer scenario or Replace Computer scenario deployment. We will examine user state migration in more detail in a future article.

Figure 8: Configure user state migration
When you finish the wizard, your new Lab deployment point is displayed in the Deployment Workbench (Figure 9):

Figure 9: The Lab deployment point has been created
Double-clicking on the deployment point displays its properties. The General tab (Figure 10) displays descriptive information and lets you choose which platforms are supported for the deployment point. For a Lab or Network deployment point, you can also enable multicast deployment if you are using MDT together with Windows Deployment Services:

Figure 10: General tab of deployment point properties
Tip:
Run the Deployment Workbench on an x86 computer if you need to install both x86 and x64 versions of Windows Vista SP1.
The Rules tab (Figure 11) shows the contents of the CustomSettings.ini file, which is used to configure the various pages of the Windows Deployment Wizard as it runs on the destination computers. You can also click the button at the bottom right of this tab to view or edit the Bootstrap.ini file. We briefly examined how to modify the CustomSettings.ini file in Part 27 of this series and will revisit this topic again in a future article.

Figure 11: Rules tab of deployment point properties
The Windows PE tab (Figure 12) lets you specify which types of images will be created when the deployment point is updated (discussed later below). This tab is also where you select which driver group contains the device drivers needed for this deployment group (driver groups were discussed in Part 28 of this series) and lets you perform other customizations of your Windows PE images such as adding a background bitmap image or additional folders containing files or tools you may need.

Figure 12: Windows PE tab of deployment point properties
Creating a Network Deployment Point


Creating a separate deployment share or Network deployment point is similar to creating a Lab deployment point as shown above. The main differences are that the default name given to the deployment point is Network, and you have to fill in the name of the local or remote computer and the share name (see Figure 13). The underlying folder for the share will be created on the specified computer when you update the deployment point (discussed later below).

Figure 13: Configuring a Network deployment point
Creating a Removable Media Deployment Point


Creating a removable media deployment point is similar to creating a Network deployment point. The differences this time are that the default name given to the deployment point is Media, and you have to fill in the name of the local or remote computer and the share name (see Figure 14). The underlying folder for the share will be created on the specified computer when you update the deployment point (discussed next below).

Figure 14: Creating a removable media deployment point
Updating a Deployment Point

After you create a deployment point, you must update it. Updating a deployment point is when the deployment point is actually created on the file system of the local or remote computer. To update a deployment point, right-click on it and select one of the following two options (see Figure 15 below):

• Update – Creates the folder structure for the deployment point (if needed), copies various MDT scripts and tools to the deployment point, and creates Windows PE .iso and .wim images for deploying Windows manually or deployment Windows using Windows DS. You generally use this option when first updating a deployment point or when you need to generate new Windows PE images for the deployment point.
• Update (files only) – Does everything the first option does except that it doesn’t create the Windows PE images. You generally use this option when you have made changes to your CustomSettings.ini or Bootstrap.ini files but don't need to generate new Windows PE images.

Figure 15: Updating a deployment point
Conclusion


In this article and the previous ones we have looked at how to configure distribution shares and deployment points in MDT 2008. The next article of this series will examine how to configure Task Sequences