[The smallest possible size of boot.sdi]

No, not except preventing an insignificant waste of resources. That's why I said only consider it as a PoC.

Joakim

Not true.

A smaller file size can help speed up PXE booting over a slow link. Sometimes I have to work with a link that takes ~30mins to boot WinPE over PXE. Any reduction is a huge boon!

In addition, a smaller boot.sdi will kick off downloading the WIM faster as well.

[WINNT32 installs from within PE 2.1]

Have you ever figured out just why certain machines take 3+ minutes to get past wpeinit while other machines do it almost instantly? it seems certain server machines such as Dells have problems with this while desktop machines that i use to test are immune.

very strange. I was thinking about trying to roll more drivers into my winpe image to see if maybe that would help.

SYSAD

Just change the registry key for wpeinit to cmd.exe. Copy procmon.exe to your WinPE image and launch procmon and set it to record registry and file monitoring. Then launch Wpeinit. That will usually point you to the culprit. I know with our HP servers it was really slow because of hardware enumeration. The amount of device ID's in the servers I was using just dwarfed your average desktop. I think it had some ~200 device ID's. This was a Proliant G5 370 (IIRC). If you install devcon.exe into your WinPE image you can verify that too.

[WINNT32 installs from within PE 2.1]

I dont use Metzen's approach because it just adds another step of complexity. And I like being able to slipstream hotfixes in to my source. In reality I don't care about the extra 5 minutes it would save. Once an install is started I'm off to the liquor store anyhow. When I get back the install is done. 20 minutes, 35 minutes, either way I end up with a beer.

Just make a script that does the following...

Imagex.exe /mountrw %PATH_TO_YOUR_SOURCE% C:\mount

%UPDATE_KB123456%.EXE /update C:\mount\$WIN_NT$.~LS

Or just update the source and remake the WIM from a virtual machine.

As always, you trade speed for complexity.

The more annoying delay for me has got to be the stupid 3 minutes winpeinit takes.

SYSAD

You can use WinPE 2005 instead. Then you won't have to use bootsect.exe but this thread asked about PE2.1.

Hm, I appreciate the new idea for an approach I always feel like i am digging new tunnels etc when i'm doing stuff like this its nice to see someone else doing the same thing.

So you're saying essentially I can make an image of the C: drive after the first 'graphical mode' where you give it the unattend file, etc.

You run winnt32.exe /switches, wait for it to finsih, then your back to your WinPE command-prompt. Now use ImageX.exe.

I get that part, so it would essentially make text-mode ready images (which is smart, i should do that once i'm 100% happy with everything).

Microsoft has actually been recommending it to be done like that since NT.

In Windows 2000, the /syspart parameter for Winnt32.exe causes Windows 2000 Setup to copy all the necessary boot files and temporary Setup files to a drive and mark the partition as active. You can then install the drive in another computer, turn the computer on, and continue with Setup.

The changes to this tech article is that instead of installing the drive into a another computer, we're taking an image of that drive and then applying that image to another computer.

The part I don't get is how do you use imagex without WinPE, etc? Are you using WDS?

SYSAD

Just grab it out of the WinPE image. I believe that version works on XP. Or install the WAIK or the Windows OPK. They all contain ImageX among some other tools.

You don't need to use ImageX. Ghost will work as well.

The flexibility of being able to access the filesystem after applying with ImageX is nice though. We use a script that detects what type of machine you have and then it will copy over the appropriate OEMBIOS.BIN, OEMBIOS.SIG, OEMBIOS.CAT, etc. after applying the image.

We also use a script before applying the ImageX that asks a series of questions (eg What role does this machine have? X,Y or Z?) then takes those answers and modifies the hard drive afterwards (ie, copies over certain programs and sets them to auto-install, changes the unattend.txt [which is actually WINNT.SIF at this stage] for certain computer names, copies over appropriate drivers for $OEM$, etc.).

In this way, we actually modularize our install. We have the "base" which is kept pure, then a scripted layer for things that can't be auto-detected (ie, what role does the machine play?), and then add scripted layers on top which run silently. This allows us to completely image a machine in about ~15 minutes from WinPE boot to desktop.

Naturally, this didn't occur overnight but took about 5 years of evolution starting with WinPE from XPSP1. Though, I think I could implement a solution that matches it in functionality in about a week if I had to start from scratch.

[WINNT32 installs from within PE 2.1]

Use Winnt32 and "install" the OS onto the drive but don't reboot. Your harddisk should now be ready for text-mode setup so it's still hardware agnostic. Now using ImageX make an image of the drive back to the network.

Now change your flow like so:

1 Initializes net

2 network share

3 creates partitions/formats/bootsector

4 run imagex and restore the image.

If you wanted, what we would do is on step 3 we'd create two partitions, a 2GB one and one for the rest of the system. We'd copy the imagex image to the 2GB partition and expand it into the bigger partition. Then we'd use diskpart to delete the 2GB partition and expand the big partition to consume the smaller one. I think you need to re-bootsect after doing so. This would make installs lickty split quick as copying over a single large file over a network is consistently faster than lots of individual files. And copying to a HDD and expanding from there is even faster than trying to expand over the network (which is essentially reading a bunch of small files).

The advantage of the imagex image is you can mount the image and manipulate files without having to rebuild the whole thing from PE + winnt32. Adding additional drivers to $OEM$, editing the TXTSETUP.SIF files became a piece of cake.

[What happened to the SRT Package?]

Please check out this thread for an answer:

http://www.msfn.org/board/WinPE_SRT_Package_t104854.html

[WinPE-SRT-Package]

Since the WinPE SRT package was removed from the RTM build, but I still want it fully operational in my WinPE, I've had to figure out what keys worked and what files are needed. These are my findings:

Files required:

\Windows\System32
\Windows\System32\bmrui.exe
\Windows\System32\MdSched.exe
\Windows\System32\rstrui.exe
\Windows\System32\spp.dll
\Windows\System32\srcore.dll


\Program Files\Common Files
\Program Files\Internet Explorer
\Program Files\Common Files\microsoft shared
\Program Files\Common Files\System
\Program Files\Common Files\microsoft shared\ink
\Program Files\Common Files\microsoft shared\Triedit
\Program Files\Common Files\microsoft shared\ink\ar-SA
\Program Files\Common Files\microsoft shared\ink\bg-BG
\Program Files\Common Files\microsoft shared\ink\cs-CZ
\Program Files\Common Files\microsoft shared\ink\da-DK
\Program Files\Common Files\microsoft shared\ink\de-DE
\Program Files\Common Files\microsoft shared\ink\el-GR
\Program Files\Common Files\microsoft shared\ink\en-US
\Program Files\Common Files\microsoft shared\ink\es-ES
\Program Files\Common Files\microsoft shared\ink\et-EE
\Program Files\Common Files\microsoft shared\ink\fi-FI
\Program Files\Common Files\microsoft shared\ink\fr-FR
\Program Files\Common Files\microsoft shared\ink\he-IL
\Program Files\Common Files\microsoft shared\ink\hr-HR
\Program Files\Common Files\microsoft shared\ink\hu-HU
\Program Files\Common Files\microsoft shared\ink\it-IT
\Program Files\Common Files\microsoft shared\ink\ja-JP
\Program Files\Common Files\microsoft shared\ink\ko-KR
\Program Files\Common Files\microsoft shared\ink\lt-LT
\Program Files\Common Files\microsoft shared\ink\lv-LV
\Program Files\Common Files\microsoft shared\ink\nb-NO
\Program Files\Common Files\microsoft shared\ink\nl-NL
\Program Files\Common Files\microsoft shared\ink\pl-PL
\Program Files\Common Files\microsoft shared\ink\pt-BR
\Program Files\Common Files\microsoft shared\ink\pt-PT
\Program Files\Common Files\microsoft shared\ink\ro-RO
\Program Files\Common Files\microsoft shared\ink\ru-RU
\Program Files\Common Files\microsoft shared\ink\sk-SK
\Program Files\Common Files\microsoft shared\ink\sl-SI
\Program Files\Common Files\microsoft shared\ink\sr-Latn-CS
\Program Files\Common Files\microsoft shared\ink\sv-SE
\Program Files\Common Files\microsoft shared\ink\th-TH
\Program Files\Common Files\microsoft shared\ink\tr-TR
\Program Files\Common Files\microsoft shared\ink\uk-UA
\Program Files\Common Files\microsoft shared\ink\zh-CN
\Program Files\Common Files\microsoft shared\ink\zh-TW
\Program Files\Common Files\microsoft shared\ink\ar-SA\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\bg-BG\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\cs-CZ\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\da-DK\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\de-DE\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\el-GR\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\en-US\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\es-ES\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\et-EE\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\fi-FI\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\fr-FR\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\he-IL\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\hr-HR\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\hu-HU\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\it-IT\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\ja-JP\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\ko-KR\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\lt-LT\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\lv-LV\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\nb-NO\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\nl-NL\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\pl-PL\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\pt-BR\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\pt-PT\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\ro-RO\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\ru-RU\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\sk-SK\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\sl-SI\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\sr-Latn-CS\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\sv-SE\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\th-TH\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\tr-TR\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\uk-UA\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\zh-CN\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\ink\zh-TW\tipresx.dll.mui
\Program Files\Common Files\microsoft shared\Triedit\en-US
\Program Files\Common Files\System\ado
\Program Files\Common Files\System\msadc
\Program Files\Common Files\System\Ole DB
\Program Files\Common Files\System\ado\en-US
\Program Files\Common Files\System\msadc\en-US
\Program Files\Common Files\System\Ole DB\en-US
\Program Files\Internet Explorer\sqmapi.dll


\sources\en-US
\sources\recovery
\sources\recovery\en-US
\sources\recovery\PssWiz.exe
\sources\recovery\RecEnv.exe
\sources\recovery\StartRep.exe
\sources\recovery\en-US\PssWiz.exe.mui
\sources\recovery\en-US\RecEnv.exe.mui
\sources\recovery\en-US\StartRep.exe.mui

And then attached is the registry keys required. I didn't filter every single registry key that is essential, I just did a diff of the Vista PE with the WinRE environment to the registry keys of a WinPE without one.

You'll need to mount your registry hive as PE_SOFTWARE for the Software hive and PE_SYSTEM for the System hive.

DIFF.zip

[Cannot start WinPE 2.0 Build 5536 (and RC1)]

Digging into the registry I found this was because of 1 registry key. It's located here:

[HKEY_LOCAL_MACHINE\pe_software\Microsoft\Windows NT\CurrentVersion\WinPE]
"PrepStatus"=dword:00000001
[b]"InstRoot"="X:\\$Windows.~BT\\"[/b]

What is needed is to change InstRoot to the directory below your Windows directory.

So, to enable this to work you'll need to set InstRoot=X:\

Why does Microsoft do this? So you can use a WinPE install off a harddisk with all the associated expanded files as oppoesd to a large WinPE image.

At least, that's what I've figured

[Most obscure bug]

Theme files no longer retain or change My Computer and My Network icons...

[Help deploying captured image via bdd 2007]

Tried the sysprep Idea and still have the same message. "There are no Images Available" There has to be a way to deploy a captured image via bdd 2007.

Anyone have any more Ideas.

M

This happens when you have a product key different from your captured image in your Unattend.xml file. So, if you capture a Ultimate image and your Unattend.xml file has a Home Premium key you'll get that result. This can be verified by removing the product key entry in your answer file and then doing the restore and "skipping" the entry of the product key. You'll find it'll work successfully.

[Microsoft's Self-Contradicting OPK Help Files]

Anyone know what REALLY happens when you run factory -winpe?

1) Configures your WinPE environment as specified through winbom.ini (or via it's own defaults, ie, add network support).

2) If the winbom specifies the configset, Lang, etc., copy over all files necessary to run setup

3) launch winnt32 to finish staging files.

What running winnt32 does (without factory -winpe):

1) Requires that you have access to local Windows setup files (either staged on CD/HDD or network share)

2) Stages the files and starts setup.

Essentially, factory -winpe was supposed to make it easy for you to image home or pro via a single file. All it accomplishes is copying over the i386 folder (and components if staged correctly) to your local drive (again, specified in winbom.ini) and launches the winnt32.exe file.

[<RESTART>NO</RESTART>]

I got the same problem, but created a work around for it;

Just edit startnet.cmd;

wpeinit

net use s: \\preloadserver\vista

diskpart /s wipe.txt

s:
cd cmd
call xcopy.cmd ;where it finds xcopy /s /e /y /i \\10.210.1.6\OPKTools\additional-utilities C:\additional-utilities 

cd \
cd 32bitDVD
setup.exe /unattend:s:\xml\basic.xml

I will post my complete script tomorrow at work!

Good luck!

[Edit] Forgot to mention I diskpart the HD with "diskpart /s wipe.txt" so I do not need the .xml answer file settings to make a partition.

I found that setup.exe has a /noreboot switch. So, setup.exe /unattend:s:\xml\basic.xml /noreboot will remove the reboot.

[Fixmbr type thing for Vista ?]

BOOTSECT.EXE is a tool available in the OPK/WAIK which does the FIXMBR thingy.

MS made it to enable switching between NT5 boot sector and NT6.

It's attached.

bootsect {/help|/nt60|/nt52} {SYS|ALL|<DriveLetter> [/force]

Boot sector restoration tool

Bootsect.exe updates the master boot code for hard disk partitions in order to

switch between BOOTMGR and NTLDR. You can use this tool to restore the boot

sector on your computer.

/help Displays these usage instructions.

/nt52 Applies the master boot code that is compatible with NTLDR to SYS,

ALL, or <DriveLetter>. The operating system installed on SYS, ALL, or

<DriveLetter> must be older than Windows Vista.

/nt60 Applies the master boot code that is compatible with BOOTMGR to SYS,

ALL, or <DriveLetter>. The operating system installed on SYS, ALL, or

<DriveLetter> must be Windows Vista or WindowsServer "Longhorn".

SYS Updates the master boot code on the system partition used to boot

Windows.

ALL Updates the master boot code on all partitions. ALL does not

necessarily update the boot code for each volume. Instead, this

option updates the boot code on volumes that could be used as Windows

boot volumes, which excludes any dynamic volumes that are not

connected with an underlying disk partition. This restriction is

present because boot code must be located at the beginning of a disk

partition.

<DriveLetter> Updates the master boot code on the volume associated with this

drive letter. Boot code will not be updated if either 1)

<DriveLetter> is not associated with a volume or 2) <DriveLetter> is

associated with a volume not connected to an underlying disk

partition.

/force Forcibly dismounts the volume(s) during the boot code update. You

should use this option with caution.

If Bootsect.exe cannot gain exclusive volume access then the file

system may overwrite the boot code before the next reboot.

Bootsect.exe always attempts to lock and dismount the volume before

each update. When /force is specified, a forced dismount is attempted

if the initial lock attempt fails. A lock can fail, for example, if

files on the target volume are currently opened by other programs.

When successful, a forced dismount allows exclusive volume access and

a reliable boot code update even though the initial lock failed. At

the same time, a forced dismount invalidates all open handles to files

on the target volume. This could result in unexpected behavior from

the programs that opened these files. Therefore, you should use this

option with caution.

Example:

To apply the master boot code that is compatible with NTLDR to the volume

labeled E:, use the following command:

bootsect /nt52 E:

BOOTSECT.zip

[ATI Vista Catalyst Drivers silent install]

C:<driver path>\Bin\ATISetup.exe -NoUI -Install -Use C:<driver path>\Packages

You extract the single binary you download from AMD's website and then in there you navigate into the Bin folder and ATIsetup.exe /? will give you more options including the silent install listed above.

Sorry if this is a dupe, I didn't see it here nor find it when I searched for it.

[Nvidia go 7600 silent install switches]

Hello All,

i am triyng to install my nvidia drivers silent on my machine. but i don't want the machine to reboot and i can't seem to find the right switch(es).

i use the setup.exe /s (that works)

setuo.exe /k does not work

and now i don't now it anymore. (i tried the switches with the .iss file but still the machine reboots).

can anyone help me?

thanks in advance

Record an answer file first by going setup.exe -r -f1C:\nvidia.iss

and do a install with all the options you want.

then save the answer file and you can silently install every time thereafter with:

setup.exe -s -f1C:\PATHTO.ISS

Note, there is NO space between f1 and the path.

[[help] registry tweaks, desktop icons]

It does work, but you need to kill explorer and relaunch it for it to take:

regedit /s REGTWEAK.REG

taskkill /im "explorer.exe" /F

start explorer.exe

[Current_User Regtweaks doesn't work ?]

reg load HKLM\DEFAULTUSER C:\users\default\ntuser.dat

And then apply reg tweaks to the:

HKLM\DEFAULTUSER

?

[Unattended Gothca's]

*Themes won't set the background through OOBE because OOBE prompts you for one.

*My Network Places and My Documents folders won't apply custom icons even if specified in a theme file

*You can registry hack the icons above but then the icons won't change even when switching back to standard Windows themes. The only way to change them back is to go to where you can manually change the icon and "Restore Default".

[Unattended Gothca's]

FixNTFS is now called BOOTSECT.exe and is found in the BOOT folder of the Windows Vista DVD.

[Unattended Gothca's]

It appears the majority of the WindowsPE stage refers to starting off a full DVD with an answer file... Starting off an actual Windows PE CD starts you at "Phase 2" and lots of the options for the WinPE stage does not work (running Synchronous commands, setting a log file, etc.)

Poor to call it WindowsPE stage...

[Unattended Gothca's]

Hey everyone,

Thought I'd start a little list on all the gotcha's I've encountered when playing with Vista right now...

Distribution share -- What the heck are these? Configuration sets with a different name?

It seems that distribution share are a complete waste of a name. Just because you have the Distribution share mapped up in your Windows System Imaging tool doesn't mean ANYTHING! Nothing is copied over -- ever. All it seems to do it create a folder structure -- Whoop dee doo!

Yeah, you can right click and add drivers, and they do appear to be added to the distribution share, I haven't had success in getting anything copied over via the $OEM$ folders folder.

In order for $OEM$ to be copied from the "distribution" share, it appears you need the AutoUnattend.xml to reside in the root of that folder...

Like so:

$OEM$ folders
		   |-$OEM$
		   |-$$
packages
Autounattend.xml

The WinPE Disk Configuration section is extremely finicky. If the disk isn't setup EXACTLY in a manner that it can execute all of it's commands, it throws up an error and fails as opposed to continuing. This is a PITA when extending partitions, formating different partitions, etc.

Either you'll need a way to detect how a disk is setup beforehand, ensure a disk is setup in an exact configuration all the time, etc.

Naturally, I may be different than everyone else because I do all my installs from "scratch" not the Microsoft recommended, install, configure, backup to an image, redeploy image, tweak, etc.

It appears the $OEM$ folders that is created by the distribution share is incorrect! You need to rename it to $oem$ for it to be correctly placed on the destination system....

[How to change the active partition...]

You can change the active disk by using diskpart...

Copy and paste the following to a batch.cmd file.

echo select disk 0			 >> %SYSTEMDRIVE%\diskpart-script.txt
echo select partition 1		>> %SYSTEMDRIVE%\diskpart-script.txt
echo active					>> %SYSTEMDRIVE%\diskpart-script.txt
diskpart /s %SYSTEMDRIVE%\diskpart-script.txt

Just change "select partition" number if you want to change the active partition within a disk, or the "select disk" number to change the disk you want with the active partition.

[<RESTART>NO</RESTART>]

In the old WinPE/winnt32 it was not required to reboot the computer *immediantely* after setup completes. With that, you could WinPE OPK a image over and once it was done manipulate the image if required.

As an example, you could utilize the Winbom.ini as follows:

[Version]
signature=$CHICAGO$

[Factory]
Logging=YES
LogFile=%WINDIR%\winbom.log
Username=guest
Password=


[ComputerSettings]
AuditAdminAutoLogon=Yes
SourcePath=%windir%
FontSmoothing=ClearType
DisplayResolution=1024x768x32
Hibernation=No
ExtendPartition=1

[NetCards]

[WinPE]
Restart=No
Lang=ENG
Sku=pro.sp2
ConfigSet=XP PRO SP2
SourceRoot=\\10.210.1.6\OPKTools
Username=guest
Password=

[WinPE.net]
StartNet=Yes

[StartMenuMFUlist]
Link0=
Link1=
Link2=

(notice the RESTART=No)

As you can see, this would install pro then continue on in a batch script. So you'd have your startnet.cmd look like so:

factory -winpe
mkdir C:\additional-utilities
xcopy /s /e /y /i \\10.210.1.6\OPKTools\additional-utilities C:\additional-utilities

Now... it appears you cannot do that according to MS's documentation...

RestartRestart specifies whether to restart or shut down the system after the windowsPE configuration pass. This setting is specific to Windows PE scenarios. Once image-based installation begins, this setting is ignored.

ValuesRestart 
 Specifies that the computer immediately restarts after the windowsPE configuration pass. End users cannot disable the restart. This is the default value.

Shutdown 
 Specifies that the computer immediately shuts down after the windowsPE configuration pass. End users cannot disable the shutdown.


This string type does not support empty elements. Do not create an empty value for this setting. 
Valid PasseswindowsPE 
Parent HierarchyMicrosoft-Windows-Setup | Restart
Applies ToThis element is available in the following editions and architectures.

Editions  Architectures  
the Windows Vista family 
 All

XML ExampleThe following XML output shows how to set the computer to shut down after the windowsPE configuration pass.

<Restart>Shutdown</Restart>

See Also Microsoft-Windows-Setup

Has anyone out there been more successful than myself at this?

[PXELinux Boot WinPE 2.0]

Just going over some WinPE 2.0 stuff... I haven't tried anything out yet.

It appears WinPE 2.0 can reboot to the memtest...? It's included in the default image under:

mount\Windows\Boot\PCAT

Anyways... Just doing some idle thinking about this problem. I use PXELinux for a menu based system at work for floppy diagnostic utilities and such. We use WinPE as well. PXELinux has been great thus far as a solution. PXE boot files for WinPE 2.0 are located here:

mount\Windows\Boot\PXE

Notice the .12 files are similiar to startrom.12 files that we'd rename for the PXELinux kernel?

Here's an image detailing the boot procedure in technical (see attached).

PXEBoot.com (startrom.com) is the loader, then passes off to bootmgr for a menu system (is my understanding?).

Will experiment and post results tomorrow.

Nevermind. All information is found in the WAIK.

http://www.msfn.org/board/index.php?showtopic=84688

[Single Image Hardware Independent Operating System Independent Deploym]

I do this to deploy windows occasionally as well..mainly for windows 2000. Only difference being is that I kick off unattended installs from within BartPe and then ghost them from within the same session. I mainly do 2000 as hotfixes aren't really being released as frequently and are quickly picked up with windows update. Also, most drivers are already as new as they're going to get for 2K.

The only disadvantage of this method (toe me) is the above. The builds become"dated" when new service packs and drivers arrive . No way to update svcpack.inf or slipsteam new fixes\drivers when they arrive without creating a new image. If the builds could somehow be "peeled apart" and new hotfixes\drivers applied it would be THE way of deploying windows...much the way that WIM files work.

You could continue to use WinPE to "winbom.ini" the configuration set over, thus you wouldn't need to remake the image for each Windows or driver update. The advantage to the above is the speed of imaging is faster than using winbom.ini from within WinPE to copy the image over (about 5mins for the image vs. 15mins for copying the configuration set).

[Single Image Hardware Independent Operating System Independent Deploym]

Forget hardware independent imaging, this is hardware / OS independent imaging. Want to image XP Pro to a dual, dual-core AND a single core from a single image? What about the same with Tablet and Media Center? From a single image?!

It's possible!

HOW TO:

1) Make a OPK share (usually OPKTOOLS)

2) Make a CFGSET and set it to be able to do Media Center / Tablet (use a Media Center 2005 CD's and combine the two CD's) IF possible. (optionalsources=YES under [WINPE] in Winbom.ini)

3) Boot a VM into WinPE and use the Winbom.ini created by the CFGSET to copy all the necessary files over. Once that's done the system should reboot, go back into WinPE immediantely.

4) Kill FACTORY.EXE upon entering WinPE *IF* it's going to "Install Configuration Set"

5) Make an IMAGE of the hard disk and call this "VIRGIN" (or clean or blank or whatever).

6) Copy out winnt.sif located in the $WIN_NT.~BT$ folder to a network share. Within this one single file is the product key that determines what version of Windows you are going to have (Pro, Tablet or Media Center --> as far as I know [but haven't tried] this will not work for HOME).

7) You can now image a machine with the VIRGIN image and then copy over a WINNT.SIF to $WIN_NT$.~BT that has the proper product key using WinPE and FIRM. Since this is before the blue text-mode setup it is hardware independent and Windows will automatically configure itself for the number of processors it can support automatically. As well, because it's before the GUI mode configures itself via the product key, changing the WINNT.SIF file will change the type of Windows it will install itself as!

Single Image Hardware Independent Operating System Independent Deployment (SIHIOSID)

Boom baby!

One Image to Rule them All!