Hi guys.

I've been commissioned to take all of our separate hardware images (3
for laptops and 4 for PC hardware) and combine it into one master
image.

The model of the PC I started with was a PDS Infinity BR-2. I took
the standard image for this model and extracted all drivers into C:
\install\driver\br2\audio, C:\install\driver\br2\video, etc. I then
added these paths to the OEMPnpDriversPath statement of my
sysprep.inf file. I also added the appropriate entry for the BR-2's
IDE controller to the [SysprepMassStoreage] section. I then ran
"sysprep -pnp" and it came back up. It went great except for the
video driver. For some reason during the mini-setup it's looking for
a ialmnt5.sys file in C:\winnt\drivers\intel\graphics. However, if I
hit the drop down box the first entry is "C:\install\driver\br2
\video". If I select this path and hit OK it goes through! So I
tried to find this path statement through all the files on the hard
drive and the registry, but the only entry I could really find was
"<WINDIR>\drivers\intel\graphics" in some data1.hdr file in C:
\install\driver\br2\video. I took a hex editor and edited the
statement to my driver path, but it still refuses to look in my video
directory!

I could of course copy the video drivers into the C:\winnt\drivers
\intel\graphics, but other pieces of hardware also use Intel chipsets
for their video display and cramming those drivers into the same
directory would not be ideal.

I also could not see how to extract the chipset driver for the
motherboard. I assume that if I run chipset setup's for 7 pieces of
hardware on the same image Windows just loads the appropriate INFs
based on the hardware?

I read that Windows will also load all the of the mass storage
drivers in the [SysprepMassStorage] section and that you should run
"sysprep -clean" in a cmdlines.txt file during the syspre to clean
those out. Is this for real? Isn't the whole point of placing the
unique PCI device id in this section to show Windows which driver to
load for each piece of hardware? Does it really load a IDE driver
for EVERY driver listed in this section on hardware that might only
need one of these drivers?

I did a little Google searching on sysprep and the OemPNPDriversPath
statement, but if anyone has a guide on someone doing this "in the
trenches" that would be great.

Adam

Adam Leinss <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

Hello again!

I made some progress today. After reading
http://myitforum.techtarget.com/arti...ew.asp?id=6733 I found
out that the devices were looking at C:\winnt\inf\oem*.inf for their
information instead of C:\install\driver\br2\device. I also checked
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\DevicePath
and it was quite long! It appears every time you run sysprep a
computer it appends the path from OEMPnPDriversPath in sysprep.inf to
this key. So I cleaned out this key. And now it works without
prompting for the drivers during the mini-setup.

So I tried the image on an Omnitech 8100-733 MHz machine and I get a
total freeze up at mup.sys. I disabled mup.sys and ndis.sys from the
recovery console, but it still won't boot. I even renamed the C:\winnt
\system32\drivers directory and then added drivers in back one by one
when it was complained about missing drivers, but it still freezes
hard. Maybe a HAL issue? I think I may try with a newer Omnitech.

Thanks,
Adam

Adam Leinss <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> So I tried the image on an Omnitech 8100-733 MHz machine and I get
> a total freeze up at mup.sys. I disabled mup.sys and ndis.sys
> from the recovery console, but it still won't boot. I even
> renamed the C:\winnt \system32\drivers directory and then added
> drivers in back one by one when it was complained about missing
> drivers, but it still freezes hard. Maybe a HAL issue? I think I
> may try with a newer Omnitech.

Answering my own questions!

After stumbling upon someone's blog talking about sysprep (and I
thought I was geeky!), I found out it was a HAL issue. Aftering adding
this line to my sysprep.inf file it now works on the 733 MHz model:

UpdateUPHAL=ACPIPIC_UP,C:\WINNT\Inf\Hal.inf

This forces it from the "ACPI Uniprocessor" HAL to to be "Advanced
Configuration and Power Interface (ACPI) PC" HAL.

Even if you change the HAL to be "Advanced Configuration and Power
Interface (ACPI) PC" and then sysprep the image it resets it back to
the ACPI Uniprocessor HAL. That threw me off for a bit.

Adam

Good find! Thanks for posting back.

Oli


"Adam Leinss" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Adam Leinss <(E-Mail Removed)> wrote in
> news:(E-Mail Removed):
>
>> So I tried the image on an Omnitech 8100-733 MHz machine and I get
>> a total freeze up at mup.sys. I disabled mup.sys and ndis.sys
>> from the recovery console, but it still won't boot. I even
>> renamed the C:\winnt \system32\drivers directory and then added
>> drivers in back one by one when it was complained about missing
>> drivers, but it still freezes hard. Maybe a HAL issue? I think I
>> may try with a newer Omnitech.
>
> Answering my own questions!
>
> After stumbling upon someone's blog talking about sysprep (and I
> thought I was geeky!), I found out it was a HAL issue. Aftering adding
> this line to my sysprep.inf file it now works on the 733 MHz model:
>
> UpdateUPHAL=ACPIPIC_UP,C:\WINNT\Inf\Hal.inf
>
> This forces it from the "ACPI Uniprocessor" HAL to to be "Advanced
> Configuration and Power Interface (ACPI) PC" HAL.
>
> Even if you change the HAL to be "Advanced Configuration and Power
> Interface (ACPI) PC" and then sysprep the image it resets it back to
> the ACPI Uniprocessor HAL. That threw me off for a bit.
>
> Adam