ribond

Crashing is Diskpart's way of saying "it cares". It also does this in 1.2 if it can't find any disks to muck with. If you can F6 these drivers with a full OS cd, this would be a good indication they can work in WinPE. What drivers are they?

You can save yourself a lot of time, effort, irritation, etc by: a. waiting for the Server sp1 release of WinPE which includes support for booting from UFD (aka Disk On Key) and tools to make it work b. Getting a beta build of the Server tools, the latest version of which should include the support. Using the beta tools I have been able to boot my Dell GX270+ systems from UFD. Note that the MS solution and the HP solution are completely different, polar opposites. The HP solution boots the key out of INT13 -- the MS solution will boot the key in XINT13. Both will suffer from the same issue -- if the system doesn't support boot from USB natively you won't get far.

one handy way to figure out if WinPE has installed your nic is to run: NETCFG -SA from the cmd prompt. This will give you the PNP ID's and friendly description of any NICs that have been installed. You can also run NETCFG -SN to see what protocols have been bound, etc.

ChrisBaksa: What build of Server Sp1 are you building your WinPE image from? And what build are you running winnt32 against? Br4tt3: I'm sorry to say that your Alternative Two answer is the only one that will work; txtsetup.OEM does not support multiple DEFAULT driver entries. However there is an easy way to eliminate the on-cd impact of multiple copies of this driver-package -- The tool used by WinPE (ok, MKIMG really) to create .ISO images is called OSCDIMG.EXE. Take a look inside MKIMG for an example command line when using this thing, as it is a bit archane. The fix for the CD space is to use the "-o" switch with OSCDIMG. This will do single-instancing in your ISO, so duplicate filenames won't really get added to your image, or impact the on-disk size, but will be linked to transparently.

1. Make sure that your [guirunonce] lines are quoted. 2. Open up %windir%\system32\$winnt$.inf to see what Windows did to your unattend when it parsed it... if it found bad characters/formatting in there it may have decided to remove your guirunonce line.

Thanks Chris -- you're right, I'm spouting nonsense. Version 2004 will only build against xpsp2 Version 2005 will build against Server sp1 or Xp sp2.

It's prompting for what partition to install to because your Unattend file is telling it to. Change this: [Data] AutoPartition=0 to this: [Data] AutoPartition=1 And it will stop asking you questions. Hey Edge -- Why are you manually starting services for Diskpart?

How are you installing? From CD or from a share (local/net)? Do you get it at the beginning of GUI mode setup or is it later on in the installation?

For the record, you can also substitute environment variables for settings in your diskpart.cfg file. ex: set disk=0 set part=1 :diskpart.cfg sel dis %dis% sel par %par% hth

I answered a very similiar question over here

The multiple-computername thing in setupmgr is a little obscure. If you let it generate a batch file to run your setup (option on the last page of the wizard) it will show you the syntax that you need to use. Basically it allows you to use one unattend file and modify the settings in that unattend file with another file. So you'd say winnt32 /unattend:myunattend.txt /udf:mercury,myunattend.udb ...and then instead of using the computername from your unattend it would open up "myunattend.udb" and look for a "mercury" setting. There is another way to use it (providing UFD data on a floppy) but it's more complicated and again, very obscure. Note: None of this does any checking to make sure that your computername is unique -- it just provides another method of setting it.

If my memory serves me correctly.... The default config for Unattended installations should be: <platform>\$oem$\stuff as in: \i386\$oem$\$1 And Sysprep would be: %systemdrive%\sysprep\$oem$ ... Be that as it may, you can actually change this around to use a consistent structure. Take a look at the "OEMFILESPATH" setting in the unattend documentation.

Unattend.txt 1. the TargetPath parameter doesn't accept "\"'s -- you should change it to "windows" 2. An easy way to get a look at how Setup will parse your unattend file is to run it under Winnt32 and see what gets spat out. run Winnt32 /unattend:<pathto>:\winnt.sif /tempdrive:%systemdrive% /noreboot then Notepad %systemdrive%\$win_nt$.~bt\winnt.sif This copy of winnt.sif has been parsed by setup and you can see some changes... but the only one we really care about is the computername setting. What does it say it's set to here? Another option: If you've already run this winnt.sif file through setup on a system that's still hanging around, take a look at "%windir%\system32\$winnt$.inf" Again, this is your unattend file after Setup gets through parsing it. If you dont' see a computername setting in this file then you'll have to backup and try the winnt32 option. 3. Why are you trying to set the %profilesdir% to the default setting? Just curious... USERACCOUNTS.CMD You don't make it clear -- are you running this file as a runonce item or from cmdlines.txt? Either way: The easiest method of figuring this out is going to be by replacing your batch file call with: "%windir%\system32\cmd.exe /k" This will launch a cmd.exe window that waits for you to close it before moving on. Try running your batch file manually from this window and see what happens. Since it's erroring on some weird group-related errors, try running: "net localgroup" to get a look at the valid groups that your system believes in and compare that to your script. Hope that helps.

The $OEM$ structure is used by both Unattended setup and Sysprep, but the file copy part only happens during Unattended setup. I don't think this is going to work for you.

I think that you've got the versions confused (or I'm reading this wrong): -Version 2004 is Windows PE built from XPSP2, and it's also known as 1.5 -Version 2005 is Windows PE built from Server Sp1, AKA 1.6 -Version 2004 will only build against XP SP2 and Server "gold" releases -Version 2005 will only build against Server sp1 and XP SP2

Well the good news is that your driver package has been found and WinPE is trying to load it. The bad news is that there's a formatting problem with the TXTSETUP.OEM file. Did you make any modifications?

For the record: Microsoft has announced that they're going to officially support booting from USB Disk On Key things in the Server 2003 SP1 release.

@Vann: If you move to a Windows XP SP2 based WinPE your problem should go away... The problem you're hitting occurs when WinPE is installed on the HD and you're running a Winnt32 installation with non-standard drive letter assignments. Winnt32 tries to migrate your drive letters which ends up confusing everyone. They fixed this in "version 2004" (the sp2 release of winpe). Metzen is right about WinPE not saving drive letter assignments in any other scenario. You should probably skip the /makelocalsource switch -- using it is telling Winnt32 that the file source it's copying from is going to disappear in textmode setup (like a net connection, or a cd that you plan on removing). Since your source files are on the HD you can save some time by not using this flag. @Voltaic: Winnt32 always lays down textmode setup. The only way to start further through setup is to use imaging... If you're just dumping out installations of the OS then you can also just use the OS cd and an unattend file on a floppy (no winpe involved here) to throw down the OS. This skips the Winnt32 phase -- so you just get Textmode and Gui mode... and a lot less file copying.

<sigh> Typed too fast. the foo.txt should read: <foo.txt> sel dis 0 cre par pri active assign </foo.txt> If the syntax looks weird, note: Diskpart accepts the first three letters of most commands in place of the full command. select disk 0 == "sel dis 0" create partition primary == "cre par pri" etc..

If you want something that's already integrated with WINPE then you can use Diskpart's CLEAN command. Diskpart /s foo.txt <foo.txt> sel dis 0 clean ce par pri active assign </foo.txt> Upside: known good state to start your deployment/install Downside: It destroys all partitions/data on the drive, so keeping existing data won't work. ...Further upside: No additional tools required.

Sweet. Glad you got it running.

The pagefile gets created by Factory.exe. You can disable the pagefile creation by setting [winpe] pagefilesize=0 in the winbom.ini file that lives on the root of your CD. Note: Bad things may happen in low memory situations when we can't create a pagefile, so you'll need to test & make sure all is well. If you have another place to put the pagefile you can force the placement using the pagefilepath key (also under [winpe]), as in pagefilepath=x:\mypagefile.sys hth.

Hey twindude. Make sure: -that your INI file is called winpeshl.ini -that it lives in the system32 directory of your winpe image -that it has just one [launchapp] header -that it has just one key -- AppPath = "%pathto%\myshell.exe" Also make sure that you're running winpe 2004 (the ini file method won't work with older winpe images.)