It seems that I can not use unattend.xml (WinPE 2.0) technique to deploy win2k,xp, 2k3 images to deploy server.

If I generalize master server using sysprep, capture wim image of generic master using imagex, then
to deploy generic wim image using imagex, how to apply my own custom parameters like machine name etc?

I dont think WinPE 2.0 unattend.xml is useful in case of 2k, 2k3 & xp. Its only useful in case of deploying vista wim images.

Note: I tried to create unattend.xml file for winxp wim image using Windows System Image Manager , but it throws error.

If I'm not mistaken the setup/sysprep itself interprets the answer file. So I think you have to use the "old" unattend.txt (INI-)format to specify answers for Win2k, XP and 2k3.

I dont want to deploy OS using setup method (win32.exe /unattend:unattend.txt).

Instead I have generic .wim image which doesnt contain host specific info like host name, users etc.
The only mechanism i have to deploy this image to bare-metal machine is to apply using imagex.
For vista image, i can parameterize the the image deployment using winpe2.0 & unattend.xml.
But what about other windows flavors?

vista and up only

let me get this right, you have a Windows 2k/XP/2003 installation, prepared with sysprep, captured to a wim-file. And now you are trying to get the 2k/XP/2003 sysprep to use your unattended.xml as answer file, right?

This can't work (or I have missed out a updated sysprep that can use the xml-file). You have to use the old unattend.txt/sysprep.inf file format.

http://www.microsoft.com/resources/documen...unatt_tools.asp

I want to deploy captured wim-file image to bare metal machine.
The only way i can deploy this wim file to bare metal is
- boot bare metal with winpe 2.0
- create appropriate partitions etc
- imagex /apply captured-generic-image.wim 1 c:

Now my concern is - captured-generic-image.wim is generic - it doesnt have host specific information like host name etc.
How to specify these parameters for deploying "image".

For setup based installation, we use unattend.txt

It looks like to me that winpe 2.0 unattend.xml mechanism is only used for parametrizing *vista* wim images and not other?
Then what is the mechanism to apply custom parameters to 2k/xp/2k3 images captured using imagex?

given you have sysprepped the image, there should be a sysprep folder on the system drive. To provide answers just put a "sysprep.inf" in there, similar to unattend.txt, but according to the documentation from MS there are some limitations/differences.

For a first test you could just try to rename your unattend.txt to sysprep.inf and place it in the sysprep folder.

I don't know if this concerns you but I highlighted a bit I found from one of the WDS docs. (I threw in the rest as well in case anyone wanted to read it... )

Using unattend files with Windows Deployment Services
Windows Deployment Services allows you to automate both the Windows Deployment Services client and the latter stages of Windows Setup. This two phase approach is accomplished by using two different unattend files. The Windows Deployment Services unattend is stored on the Windows Deployment Services server in the \WDSClientUnattend folder and is used to automate the first phase of setup. The file used to configure unattend options during Windows Setup is stored in a sub-folder (either $OEM$ structure or \Unattend) in the per-image folder and is used to automate phases two through seven.
To automate either phase you will need to create an Unattend.xml file, copy it to the appropriate location and assign it for use. “Assignment” may be performed at the server level or the client level. The server level assignment may further be broken down by architecture allowing you to have differing settings for x86 and x64 clients. Assignment at the client level overrides the server level settings.
Prerequisites for using unattend files
• Complete the steps in the section, "Configuring Windows Deployment Services."
Administrative credentials
To complete this task, you must be a member of the Local Administrators group on the Windows Deployment Services server and have sufficient permission to add a computer to a domain.
Known issues with using unattend files
You might encounter the following issues when you configure unattend options:
• Windows Deployment Services management tools only support setting install image unattend for Windows Vista and Windows Server "Longhorn" images. Down-level images require using your existing Sysprep.inf files and manually creating a $OEM$ directory structure.
Steps for using unattend files
Unattended installation is configured through the following steps:
1. Creating an appropriate unattend file depending on whether you are configuring the Windows Deployment Services client, Windows Setup or legacy setup. The Windows System Image Manager, included as part of the Windows AIK, provides an excellent environment for authoring unattend files.
2. Associating the unattend file with an image or machine type.
The following procedures describe how to configure for unattended installation by architecture, per computer, and for Windows Setup.
Configuring Windows Deployment Services unattend
To associate a WDS client unattend file by architecture using WdsMgmt
1. Create a directory under the RemoteInstall directory called WDSClientUnattend.
2. Create an Unattend.xml file with settings applicable to the Windows Deployment Services client.
3. Rename the Unattend.xml file to WDSClientUnattend.xml.
4. Copy the WDSClientUnattend.xml file to RemoteInstall\WDSClientUnattend.
5. Start the WdsMgmt MMC.
6. Expand the list in the left-hand pane to show the Servers list.
7. Right-click the Windows Deployment Services server containing the Windows Vista or Windows Server "Longhorn" image to which you want to associate the unattend file, and then click Properties.
8. Click the Windows DS Client tab.
9. Click Enable Unattend Mode.
10. Click Browse next to the appropriate architecture.
11. Browse to the WDSClientUnattend folder, click WDSClientUnattend.xml, and then click Open.
12. Click OK.
13. To close Server Properties, click OK.
To associate a WDS client unattend file by architecture using WDSUTIL
1. WDSUTIL, the Windows Deployment Services command-line management tool, requires elevated privileges to run: click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run Elevated.
2. At a command prompt, type:
WDSUTIL /set-server /wdsunattend /policy:enabled /file:filepath /architecture:x86
Where filepath is the path name and file name of the unattend file.
Note
Help for WDSUTIL is available by typing WDSUTIL /? at a command prompt.
To associate a Windows Deployment Services client unattend file per computer
• From a command prompt, type:
WDSUTIL /set-device /device:computername /ID:GUID or MAC address /WdsClientUnattend:relative path
Where relative path is the path from the REMINST share to the folder containing WdsClientUnattend.xml.
Note
A sample WdsClientUnattend file is included in Appendix A of this guide.
Configuring Windows Setup unattend
To associate a Windows Setup unattend file to an image using WdsMgmt
1. From the WdsMgmt snap-in, click to expand the image group containing Windows Vista or Windows Server "Longhorn" images.
2. Right-click the image you want to associate the unattend file to and click Properties.
3. Click Allow image to install in unattend mode.
4. Click Select File.
5. Enter the name and path, or browse to choose the unattend file and then click OK.
6. To close Image Properties, click OK.
To associate a Windows Setup unattend file to an image using WDSUTIL
1. WDSUTIL, the Windows Deployment Services command-line management tool, requires elevated privileges to run: click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run Elevated.
2. From a command prompt, type:
WDSUTIL /set-image /image:imagename/imagetype:install /imagegroup:imagegroupname/unattendfile:unattendfile
Where imagename is the name of the image with which to associate the unattend file, imagegroupname is the name of the image group containing the image file and unattendfile is the path and file name of the unattend file to associate with the image.
To associate Sysprep.inf with a down-level image
1. At a command prompt, change directories to the image group containing a down-level image.
2. In the image group containing the legacy image, create a directory with the same name as the WIM to which you want to associate the image:
Md C:\RemoteInstall\Images\imagegroupname\imagename
3. Create an $OEM$ directory structure:
Mc C:\RemoteInstall\Images\imagegroupname\imagename\$OEM$
4. Copy a Sysprep.inf file appropriate to the image to the $OEM$ directory:
Copy C:\Sysprep.inf C:\RemoteInstall\Images\imagegroupname\imagename\$OEM$
5. Add files or make other changes as necessary and appropriate, following conventions for $OEM$.
6. After the image is applied, the entire $OEM$ directory will be copied over and the contents will be applied to the image.
Note
For more information about Sysprep.inf and the $OEM$ directory, see Designing Automated Setup Tasks (http://go.microsoft.com/fwlink/?LinkId=66136).

Would following steps work for 2k/xp/2k3 image based deployment?

1. Prepare master installation with sysprep tool (generalize it)
2. Capture the image of sysprepe'd active partition using imagex (may be by network booting into WinPE)
3. To parameterized the image:
- mount the image using imagex
- parameterize the image by editing sysprep.ini file (add custom info)
- commit the changes to image
4. Deploy the image to target machine

here is how I do my Win2k/2k3 deployments using Sysprep/imageX:

Capture base image:
1. Prepare master installation with sysprep tool (generalize it)
2. Capture the image of sysprepe'd active partition using imagex (using WinPE 2.0)

Deploy Base Image to new servers:
1. Boot system via WinPE 2.0
2. Deploy the syspreped WIM image to target machine
3. Before rebooting machine, make changes to the sysprep.inf file for server name, and other settings.
4. reboot machine and let it finish out the mini-setup

gr8!! it would avoid creating separate image for each target machine

In step 2 If I capture the image using any other 3rd party imaging tooll (say ghost or any other sector based imaging utility), would it be possible to make changes to sysprep.inf file in step 4 (i.e. before rebooting the machine)?

When you say make changes to the sysprep.inf file, I'm not sure if you are talking about the one in the image file, or the one that is on the system you just copied the image to?

My process listed above, i modify the sysprep.inf file located on the system I am imaging (step 3).

I make changes to the following sections of the file:

Im talking about system's sysprep.inf file.

if I have 620 mb of wim image, what shud be the minimum partition needs to be created on target machine?
"imagex /info wimimage" doesnt give any useful info.

Wait.. how do you modify the sysprep.inf file before the reboot? This is the part I'm confused about. Is your sysprep file sitting on the network share or WDS server or is it sitting on the sysprepped machine?

Personally, I use a HTA or VBS script. The sysprep.inf is on the imaged machine, once you apply the image.

This is very interesting so I tried it out in VMWare.. here is what I did..

1. use ghost to layed down a Syspreped image onto a new VM Machine.
2. Boot up PE and run imagex /capture c: and saved the WIM to a network share.
3. created a new VM machine, and boot up WinPE.
4. Diskpart the new drive and format it to NTFS
5. run imagex /apply the.wim back to C:

In the VM preped with ghost in step 1, a reboot will cause the VM go into mini-setup, but in the VM applied with ImageX, it bluescreens at me.

anyone have any suggestions? Is this a VM issue? thanks.

I tried it on VM instance only.
Only difference between your and my steps are:
Instead of your (1) step , I install OS on VM manually - then syspreped it.

You can try followin steps:
1. deploy normal (NOT syspreped) image to new VM m/c
2. sysprep it
and then ur normal steps....

In your syspreped image, have you included the vmware IDE or SCSI drivers in the mass storage section? if not, it will BSOD on you anytime you try and use that image on VMWare.

Is there any way, after doing the wim image, to use WinFLP or LH installer to format and apply the wim image, as Dexter inside does?

thank you in advance

Has anyone dealt with System partitions?
I have several peices of hardware that require system partitons (older hardware but we stil use it and I have to support it)
My issue is that the System partition is a hidden partition with no drive letter assigned.
ImageX can't deal with this partition like PQIDeploy or Ghost.

Has anyone been sucessful with imagaing and deploying a system partition using imageX?

I am told I have to play with it by actually making the sys partiton active and assigning a drive letter
Then Imaging it.
And when I deply it.. doing the same in reverse. Deploy as C:... then hide it and mark as non bootable.
Thats lot of work in my book....

I'm curious if anyone has tackled this yet and if they would post the code thay used.

Chris

If the datafiles on the partition is readable by Windows/WinPE, it should be possible, remember ImageX is filebased and not disk/sector based like Ghost/PQIDeploy.

It will require some scripting/coding to handle but as you have access to VBScript and WMI from WinPE, it should be fairly easy to solve this.