Jump to content

WINNT32 installs from within PE 2.1


Recommended Posts

Howdy,

I have built somewhat of a custom install system utilizing Windows PE 2.1 and doing installs using WINNT32, etc.

It currently takes about 20 minutes to install any edition of Windows 2003 using this system and I am trying to shave this.

Here is what the system currently does:

1 Initializes net

2 network share

3 creates partitions/formats/bootsector

4 copies files over network share

5 runs the installer (winnt32.exe via the network share) then it completes an automated install using an unattend file.

If i am not mistaken the installer copies the files across the network AND i am copying the files across the network (so i'm doing it twice).

But I am trying to figure out the best way to do it.

I figured it would be much faster to copy the installer/media to the C: drive and the run the winnt32.exe file from the c:\drive but it doesnt work for some reason.

Does anyone have a good way to speed the process up?

I'm getting complaints from folks who used to like the fact that ghost was quicker but you had to maintain a ghost image for every hardware type (which was tedious).

SYSAD

Link to comment
Share on other sites


You don't need to copy any files over to your C: drive after you partition it. Simply run Winnt32.exe from your network share. Winnt32.exe will copy all the files over to the freshly formatted C: drive and presp the system to start the install after the next reboot.

Your command line should be:

WINNT32.EXE /S:<SOURCEDIR>\I386 /SYSPART:C /TEMPDRIVE:C /MAKELOCALSOURCE /COPYDIR:I386 /UNATTEND:<PATH_TO>\UNATTEND.TXT

Link to comment
Share on other sites

You don't need to copy any files over to your C: drive after you partition it. Simply run Winnt32.exe from your network share. Winnt32.exe will copy all the files over to the freshly formatted C: drive and presp the system to start the install after the next reboot.

Your command line should be:

WINNT32.EXE /S:<SOURCEDIR>\I386 /SYSPART:C /TEMPDRIVE:C /MAKELOCALSOURCE /COPYDIR:I386 /UNATTEND:<PATH_TO>\UNATTEND.TXT

well, what I have it doing now is copying the contents of $OEM$\$1 to c:\ which includes i386 and the R2 install files.

SYSAD

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

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.

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

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

SYSAD

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

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

SYSAD

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Just in playing with various bios options i've been able to speed it up tremendously, now i have to figure out which specific BIOS option did it, hah!

SYSAD

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...