arwidmark

SkipBDDWelcome=YES goes into bootstrap.ini, not customsettings.ini You do have a few duplicates (like SkipComputerName) in your customsettings.ini Also, if you specify SkipTaskSequence=YES you need to set TaskSequenceID=<whateever ID you are having> If you specify OSDComputerName in cs.ini, I recommend settings to a variable so it's unique for each computer. Like OSDComputerName=PC-%SerialNumber% / Johan

It doesn't really matter if is possible or not... You are simply not allowed to sysprep and capture an OEM machine with any deployment solution, sorry... You are supposed to use a Volume License media. Enterprise deployment is one of the key benefits with the Microsoft Volume Licensing program. From the Microsoft Reimaging.docx document: "Organizations do not have the right to reimage using OEM media. An OEM image can only be preloaded on a PC by the OEM during manufacturing. An image can be individually recovered by the organization (or a service provider they choose) by using the Recovery Media. The OEM recovery media should match the product version originally preinstalled on the system; no other image may be used to restore the system to its original state." / Johan

hmm, according to the logs you are trying to run a task sequence that syspreps and captures the machine... You need to select a full standard client task sequence (with an Install Operating System action) to do a computer refresh. If it's an OEM installed machine you are not allowed to run sysprep (against the EULA). Second that you seem to be connecting to the deploymentshare with a different account than you are logged on as, but MDT works around that by using the existing credentials. / Johan

Where do get the logs? C:\MININT\SMSOSD\OSDLOGS

Ah, you want to a Refresh, that is perfectly valid scenario as well, then you don't use WinPE... my bad, I thought you were doing bare metal deployments... Please zip the new logs and post them (as attachment) / Johan

You need to update the deployment share to create new boot images (with the updated bootstrap.ini) After booting into WinPE, press F8 to get a command prompt. Review the X:\Deploy\Scripts\bootstrap.ini file and verify that you can do a net use to the same share (the deployroot value) from the command prompt. / Johan

The bootstrap.ini is incorrect, deployroot is missing, should look like something this: [settings] Priority=Default [Default] DeployRoot=\\MDT01\MDTBuildLab$ SkipBDDWelcome=YES / Johan

Check the Deployroot value in bootstrap.ini... and also make sure you are using MDT 2010 Update 1 since it has fixes for this particular issue. / Johan

The easiest option is simply to have different task sequences with different disk configurations.. You can also add multiple disk partitioning actions to a single sequence and use conditions on disk size for each of them... This example will only do the action if the disk is larger than 200 GB SELECT * FROM Win32_DiskDrive WHERE Index = "0" AND Size > 214748364800 (214748364800 bytes = 200 GB) / Johan

There is no built-in pane that ask for user account. However, you can download an editor for the wizard, MDT Wizard Editor and add a pane yourself. You can then have a script in the state restore phase to creates the user account. / Johan

In general both drivers are added to the driverstore, then the driver ranking will figure out what driver to use. You can see this ranking in the setupapi.dev.log file at deployment time / Johan

In addition to Tripredacus comment: replace the second line: <unattend> with <unattend xmlns="urn:schemas-microsoft-com:unattend"> For the Enterprise version, assuming you are using KMS, you normally don't specify a product key at all, just remove the <ProductKey>ABCDE-FGHIJ-KLMNO-PQRST-UVWXY</ProductKey> section. If you are using MAK keys, you should use that one. The keys acts as a filter for the setup, so if the key is not correct you will get a "operating system missing" error. As for the joindomain issue the answer looks quite ok at a first look, except for that you should not add computers to the computers container, it's only there for legacy reasons, use an OU... Anyway. check the c:\Windows\Debug\Netsetup.log for info on why the domain join failed. / Johan

Check the setupact.log file... You can check this working x86 sample, x64 has the same settings Back to basics - Understanding Unattend.xml automation in Windows 7 / Johan

Most people these days are using free deployment solutions like MDT 2010 from Microsoft, to have an engine that automatically updates the unattend.xml on the fly, allowing you to use multiple configurations on a single media. For media based deployment these settings are stored in a separate textfile (customsettings.ini). Other than that, if you copy the unattend.xml file to a writeable location (like X:) before starting setup, you can easily have a script that updates it with the correct values. Then setup will run with your updated answer file. Even when booting on a read-only media you have 32 MB (default, can be increased) ramdisk that can be used for updating the answer file. / Johan

I recommend using the free MDT 2010 Update 1 solution (www.microsoft.com/deployment) to generate a automated media (ISO or USB) including drivers, apps etc. The media can be as automated as much as you want it to be. MDT 2010 Lite Touch is like nlite on steroids, supports XP/2003/Vista/W7/2008/2008R2, and is supported by Microsoft. / Johan

You should use a separate wim... There is a reason Microsoft ships them this way / Johan

Correct, not any more settings than for x86, but you do need to create a new file since the architecture information is embedded in every configuration pass. / Johan

The answer file your uploaded is for a 32-bit install (x86), you need to create a new one, and before that select a catalog file for a 64-bit (x64/amd64) operating system in Image Manager. Windows 7 Setup always provide access to setupact.log, did you really press Shift-F10 to get the command prompt window? Please note that depending on when the setup fails, the setupact.log will be in different locations (X: or C:)

Well if the unattend.xml file is x64 already, you can use it directly. If it fails, check the setupact.log file to find out why. Press Shift-F10 to get a command prompt when running the Windows 7 setup. Or post the unattend.xml file (as attachment, not in the content), and I will take a look... / Johan

You need to select a 64-bit catalog file (or generate one) in Windows System Image Manager, and create a new answer file. The answer files are different between x86 and x64. / Johan

Very true, You might also want to check the Windows PE Developer’s Guidefrom Microsoft, a bit old (for WinPE 2.x) but most content is still valid / Johan

Add error handling to your code and suppress all error messages, then you can decide how to output the errors... log files, or a small HTA window etc. If you want some samples you can download MDT 2010 Update 1 from Microsoft and a take a look at their error handling routine for vbscripts in WinPE. / Johan

Another option is to boot the machine in WinPE and load the registry offline. Either via reg load or in the registry editor directly (load hive). / Johan

setup.exe understands the installfrom: switch where you can speciy a wim-file to use. It can also be specified in unattend.xml / Johan

When using plain vanilla WDS for deployments you need two different unattend.xml files. One for the WDS client (with for example partioning info), and then one for the image you are deploying. / Johan Ps. I would agree that integrate with MDT is a better option. But if you just want to dump an image to a client, without any settings, any intelligent driver injection, without updates or without applications, then WDS is quite useful... Ds.