Jump to content

ribond

Member
  • Posts

    51
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

Posts posted by ribond

  1. 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.

  2. 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.

  3. 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.

  4. 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

  5. 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.

  6. I also find it odd that with unattended installs you are supposed to put the $OEM$ at the same level at i386 but for sysprep you are supposed to put the $OEM$ inside the i386.

    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.

  7. 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.

  8. So far I have not seen much on PE 1.6 (2004) but i do know that you cannot build a Server 2003 SP1 PE based disk with 2004. As stated in the .chm, fyi it will not pass the media test in the initial build.

    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

  9. @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.

  10. <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..

  11. 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. :)

  12. 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.

  13. 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.)

×
×
  • Create New...