Altirigos - View Single Post - Dynamic Mass Storage Device Driver Injection during Mini Setup Failing

James McGoodwin · 11-05-2008, 01:04 PM

Thanks guys for taking the time here. I appreciate your help.

First, I'll talk to Brandon's response to me last post:

Quote:

What happens if you leave it all the same but turn off SATA Native mode in the bios. Allow it to image then try to update the drivers once the machine is booting into Windows. Basically from bullet #5 on .... My Tech Blog: Enabling SATA Native Mode after XP Install
This will tell you if the OemPnpDriversPath is working and also if the correct driver is being used.
If that works then you have narrowed it down to the original or injected sysprep.inf file.

Ok, so I set the laptop to compatibility mode. Got into the desktop after sysprep ran and changed the "Standard Dual Chanel PCI IDE Controller"s driver to use the driver set hosted in C:\drivers\sata.

I set it to use the specific model that's found in the T500's ("Intel(R) ICH9M-E/M SATA AHCI Controller") and restarted it. At POST I entered the bios, reconfigured the controller for ACHI mode and then allowed the computer to boot up into windows.

It's happy and humms along. So that confirms that I have the right SATA driver being injected into the image prior to sysprep time.

This lends more credence to the statement that sysprep isn't pulling these drivers in as it does other PNP drivers.

Ok, so now to Network32

Quote:

My expirience on this is:
BEFORE you run Sysprep -quiet -mini -reseal -reboot your MassStorage Device Drivers must resist on your the destination computer and the sysprep.inf file must have the correct entries in the [SysprepMassStorage] Section otherwise MassStorage injection will not. MassStorage Driver injection does not work like other non MASSStorage Device Drivers injection.
Hope this helps!

Sigh...I have to reach the same conclusion here. The Mass Storage Device Drivers for a target have to be included in the HII prototype image at shrink-wrap time in order for the captured image to be deployed to the supported target. Wow...that's a complete absolute drag.

Ok, consider this. Let's pretend I have a shop with a multitude of product families: Lenovo, HP, Toshiba, what not. Praise the deity of your choice that I don’t, but if that scenario really was my personal hell, how could I create a HII image to support all those targets?

Let's assume each target utilized a different MSD driver for it's SATA controller. For example:

Lenovo's got the Intel Matrix Drivers.
HP's EliteBook 2530P uses the Intel Matrix drivers...ok, bad example...
Toshiba's Tecra M10-ST9110 uses the Intel Matri..what? So..hang on...what DOESN't use the Intel Matrix drivers now??

Let's start over. Pretend the Lenovo, HP and Toshiba products DIDN't all share the same controller.
Would the following work to support the diverse targets with a single HII image:
From Unattended.txt

Code:

[MassStorageDrivers]
 ;Lenovo Driver Definitions for the ICH9 Intel Matrix Drivers (V 8.2.4.1005)
 "Intel(R) ESB2 SATA AHCI Controller" = OEM
 "Intel(R) ICH9R/DO/DH SATA AHCI Controller" = OEM
 "Intel(R) ICH9M-E/M SATA AHCI Controller" = OEM


  ;Toshiba Driver Definitions for <pretend MSD Driver A> (V 1.2.3.4.500)
  "Pretend Co. (R) HappySata 12CX Controller" = OEM

  ;HP Driver Definitions for <pretend MSD Driver B> (V 6.7.8.9.000)
  "Fake Systems Inc. (R) SATAMaster 5567B Controller" = OEM

[OEMBootFiles]
 ;Driver Definitions for the ICH9 Intel Matrix Drivers (V 8.2.4.1005)
 iaStor.inf
 iaahci.inf
 iaStor.cat
 iaahci.cat
 iaStor.sys
 Txtsetup.oem

  ;Toshiba Driver Definitions for <pretend MSD Driver A> (V 1.2.3.4.500)
  hapsta.inf
  hapsta.cab
  hapsta.sys  
  Txtsetp1.oem

 ;HP Driver Definitions for <pretend MSD Driver B> (V 6.7.8.9.000)
 fkestamr.inf
 fkestamr.cab
 fkestamr.sys
 Txtsetp2.oem

and every referenced file in the OEMBootFiles list is stored in the %systemdrive%\I386\$OEM$\TEXTMODE folder on the computer at Windows setup time.

Given that setup, do you think this HII image would be deployable to all it's intended targets?

To be honest, *I* don’t, but I'm grasping here. It seems ludicrous to me to provide a mechanism (aka sysprep) that will allow for a driver agnostic image to be deployed any where...with the exception of the #1 most important driver.

It's seems sort of like a house of cards. You get one image as long as every thing uses the same hardware. You're forced to use two or more images as soon as the MSD controllers diverge. That doesn't feel right to me.

It's inconsistent, and annoying as the folks at Microsoft are, automated deployment is an area I have a feeling a lot of time, effort and thought has been focused on being consistent.