arwidmark

Configuring DHCP is of course a valid option, but you will get a faster and more reliable connection by setting ip helpers on the production VLAN. As a bonus it will work on all PXE ROMs too...

Are the WDS and DHCP servers on the same VLAN?

If you import the video driver into the MDT driver repository MDT will do the driver injection automatically during deployment, you don't need to store in the image at all... Please note that many video drivers are larger than the 32 MB scratchspace buffer WinPE is using when unpacking the driver. I recommend you to set it to 128 MB for your boot images (done in the deployment share properties. MDT has many different methods that you can inject drivers with, based on pnpid detection, based on models etc... You can read more here: MDT 2010 Lite Touch Driver Management http://www.deployvista.com/Home/tabid/36/EntryID/132/language/sv-SE/Default.aspx

You need to run sysprep when creating images to deploy to multiple computers. Sysprep prepares the machine for cloning, removes the identifiers, sets permissions, cleans out event viewer and a bunch more of additional house-cleaning. In the past (Windows 2000 days) there have been many attempts to run all sorts of hacks to achieve the same thing, don't do that... it's not supported by Microsoft and will just result in pain in the end.

Microsoft Deployment Toolkit (MDT) 2010, www.microsoft.com/deployment / Johan

Windows 7 is hardware indendent by default, and most modern deployment solution will give you the option to add addtional drivers from a central repository during deployment as well, rather than storing them inside the image. / Johan

The above task sequence actually does that... after intalling all the apps and patching the machine, it runs sysprep and captures the OS to a wim-file. All fully automated. That allow you to re-produce the image at any given time knowing it will be equally good as the last time. You can also add in a suspend in the middle (if you need to do something manually), and then resume and continue.

Well, it depends. If you are using setup to deploy the wim it makes perfect sense to store it outside the wim... fortunately you don't need to run setup.exe, you can use imagex to apply an image to disk as well...

You can do that too, simply put the unattend.xml inside the wim.... the root of the DVD is just one of many locations where setup looks for an unattend.xml file Check the Implicit Answer File Search Order section http://technet.microsoft.com/en-us/library/dd744269(WS.10).aspx

Correct, you cannot, not by using the /apply-unattend switch However you can still achieve what you want - Simply rename the unattend.xml to AutoUnattend.xml and store it in the root of the DVD (or a USB Stick)

The /apply-unattend is only for the offlineServicing configuration pass (for servicing windows like adding drivers etc). You still need to run setup.exe + unattend.xml with the other passes configured for a fully unattended setup. / Johan

A very rich and powerful way of adding applications is to deploy Windows 7 using the free Microsoft Deployment Toolkit (MDT) 2010. With MDT you get a task sequencer that will allow you to custom actions before applying the image, and after applying the image. Including handling reboots etc. MDT 2010 is becoming a de facto standard on how to deploy Windows. You can download it from www.microsoft.com/deployment This a sample MDT task sequence, this sequence will deploy Windows 7 (setup + unattend.xml), patch the machine (via windows update), install a few apps, reboot, install more apps, patch the machine again. At all time there is a nice progress bar displayed. / Johan

Windows Embedded 7 is a componentized version of Windows 7. You select what components (feature packages) you need and it will build a new Windows 7 image for you. Allows you to build a really small or completely customizerd Windows 7 image...

Only supported for Windows Embedded 7... not the normal editions / Johan

Absolutely MDT 2010 is the best way to deploy Windows 7 (by far)... The default configuration is network based deployment, offline deployment (like running around with a DVD or USB device) is optional. I have written a bunch of free step-by-step guides and video tutorials that will get you up and running quickly. / Johan

Here is a site for a bunch of free step-by-step guides and video tutorials for MDT 2010. http://www.deploymentcd.com

You can also set the input locale using DISM (offline)

A few registry entries will do the trick Skip and Bypass Windows Media Player Initial Settings Wizard on First Run http://www.mydigitallife.info/2009/02/19/skip-and-bypass-windows-media-player-initial-settings-wizard-on-first-run / Johan

In general all HP models supporting Windows 7 have signed drivers, but you can create a certificate and sign the driver(s) your self... problem solved

Adding video drivers will increase the size with at least 30 - 40 MB... I tried on a few physical machines, and 1400 x 1050 worked fine on them (using the standard VGA driver), maybe you can use that instead of 1366 x 768?

I tested with the posted unattend.xml in a vmware guest, and setting the screen resolution to 1366 x 768 using unattend.xml worked just fine. As you found out you do need to start wpeinit.exe after updating/creating the unattend.xml file. I also tested the unattend.xml you generate via the script you posted and it works fine too.... It set's the screen resolution nicely to 1366 x 768. Did you try importing the video driver for the card into WinPE?

Well, you can inject video drivers into WinPE even though it's not that common. As for using the unattend.xml, if you have startnet.cmd calling your script to found out the hardware model, you can use it to generate the unattend.xml file on the fly (X: is writable, scratchspace), and then when you call wpeinit it will parse unattenx.xml and set the screen resolution.

You can use unattend.xml to set the screen resultion in WinPE, it's still up to the driver. Here is a sample, just name the file unattend.xml and store it in the root of the WinPE image, <?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="windowsPE"> <component name="Microsoft-Windows-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"> <Display> <ColorDepth>16</ColorDepth> <HorizontalResolution>1024</HorizontalResolution> <RefreshRate>60</RefreshRate> <VerticalResolution>768</VerticalResolution> </Display> </component> </settings> </unattend>

The following unattend.xml will start a vscript in the WinPE pass (assuming wpeinit is run). You can call diskpart from within that script (or directly). <?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="windowsPE"> <component name="Microsoft-Windows-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"> <RunSynchronous> <RunSynchronousCommand wcm:action="add"> <Description>Lite Touch PE</Description> <Order>1</Order> <Path>wscript.exe X:\Deploy\Scripts\LiteTouch.wsf</Path> </RunSynchronousCommand> </RunSynchronous> </component> </settings> </unattend> / Johan

First, you can actually use the standard Microsoft Deployment Toolkit (MDT) 2010, even when using Linux as the deployment server. The only thing is that it's easiest to administer the SMB share via a windows workstation. MDT has builtin realtime serverside monitoring of the deployment, even from WinPE, and even when running the solution from a Linux server. Second, windows pe talks web services natively so if you create a web service on your linux machine, winpe can talk to that one.