SCCM 2007 SP1 and Windows XP/Server 2003 Mass Storage Drivers
hdc Class Drivers
One of the features in SCCM to facilitate deployment of Windows XP and Windows Server 2003 is the ability to inject mass storage controller drivers offline. Traditionally mass storage drivers had to be included in the image (present when Sysprep is run) for these operating systems.
To do this in SCCM, for each computer model to be supported for XP or Server 2003, you must do the following:
- Import all device drivers for the model.
- Create a driver package for the model from the imported drivers.
- Add an Apply Driver Package step to the deployment task sequence for each driver package, filtered by the model (typically WMI make and model).
- If the driver package contains a mass storage controller driver, check the "Select the mass storage driver..." box and then select the driver and model for the controller.
In SCCM RTM, this worked well as long as the storage drive was a SCSI adapter (Class=SCSIAdapter in the device INF file). However, if you needed to inject a storage controller with Class=hdc like the Intel Matrix Storage Manager Driver, you were not able to select the driver in the "Apply Driver Package" task sequence step. It would not appear as an option in the Driver drop down list. The SCCM product team suggested changing the class from hdc to SCSIAdapter in the driver INF file as a workaround for this bug. Unfortunately, this breaks the driver signature. My customer has a policy of not using unsigned drivers. So at that time we included the driver in the XP image.
This bug is fixed in SCCM 2007 Service Pack one. However, when we upgraded the sites to SP1 and went back to change the Apply Driver Package step we still did not see the hdc version of the driver. It turns out that you have to delete the driver from SCCM first. You must then import the driver again using the txtsetup.oem file and add it back to the driver packages. You will then be able to select hdc drivers.
Incompatible txtsetup.oem Files
While on the topic of Windows XP/Server 2003 mass storage drivers, I like to make you aware of another issue that we hit with using them with SCCM and how I worked around it. This one is not an SCCM issue, it is a driver issue.
We had one particular XP mass storage driver that we imported into SCCM. The driver INF file and txtsetup.oem file had entries for several devices. However when we went into the Apply Driver Package step to select the driver and model to inject we only saw one model. We we deployed to the computer with this controller, no driver was injected and XP blue screened with a Stop 7B error.
So I took a look at the txtsetup.oem file. The one that came with this driver was not structured the same as the txtsetup.oem files included with all the other drivers we were using. Here is a sanitized version of the original txtsetup.oem file (with the names, PNP IDs, etc. replaced to protect the guilty... and myself :-).
[Disks]
d1 = "Trey Research Storage Controller Driver for XP 32-bit",\trey.tag,\[Defaults]
scsi = TREY_32[scsi]
TREY_32 = "Trey Research Storage Controller Driver (XP 32-bit)",trey[HardwareIds.scsi.TREY_32]
id = "PCI\VEN_XXXX&DEV_0001", "trey"
id = "PCI\VEN_XXXX&DEV_0002", "trey"
id = "PCI\VEN_XXXX&DEV_0003", "trey"
id = "PCI\VEN_XXXX&DEV_0004", "trey"[Files.scsi.TREY_32]
driver = d1,trey.sys,TREY
inf = d1,trey.inf
catalog = d1,treyxp32.cat[Config.TREY]
value = Parameters\Interface,DeviceSetting,REG_DWORD,1
In most txtsetup.oem files, the scsi section contains an entry for each device with a unique ID that is then used to reference the other sections. Since we were on a tight timeline and we could not get the vendor to investigate this quickly, I took a stab a rewriting this file using working ones as example. This is what my rewrite looks like.
[Disks]
d1 = "Trey Research Storage Controller Driver for XP 32-bit",\trey.tag,\[Defaults]
scsi = Device1[scsi]
Device1 = "Trey Adapter Model 1"
Device2 = "Trey Adapter Model 2"
Device3 = "Trey Adapter Model 3"
Device4 = "Trey Adapter Model 4"[HardwareIds.scsi.Device1]
id = "PCI\VEN_XXXX&DEV_0001", "trey"[HardwareIds.scsi.Device2]
id = "PCI\VEN_XXXX&DEV_0002", "trey"[HardwareIds.scsi.Device3]
id = "PCI\VEN_XXXX&DEV_0003", "trey"[HardwareIds.scsi.Device4]
id = "PCI\VEN_XXXX&DEV_0004", "trey"[Files.scsi.Device1]
driver = d1,trey.sys,TREY
inf = d1,trey.inf
catalog = d1,treyxp32.cat[Files.scsi.Device2]
driver = d1,trey.sys,TREY
inf = d1,trey.inf
catalog = d1,treyxp32.cat[Files.scsi.Device3]
driver = d1,trey.sys,TREY
inf = d1,trey.inf
catalog = d1,treyxp32.cat[Files.scsi.Device4]
driver = d1,trey.sys,TREY
inf = d1,trey.inf
catalog = d1,treyxp32.cat[Config.TREY]
value = Parameters\Interface,DeviceSetting,REG_DWORD,1
The IDs (DeviceX) in the [scsi] section can be anything you like as long as each one is unique and the HardwareIds, Files, etc. sections use them. I got the descriptions ("Trey Adapter Model X") out of the INF file.
We deleted the driver out of SCCM, replaced the txtsetup.oem with mine and re-imported the driver. We could now see all models in the Apply Driver Package step. We selected the correct one and tested the task sequence. The driver was injected correctly and the OS booted and worked just fine. Also, the txtsetup.oem does not appear to be part of the signature catalog for this driver because SCCM did not flag this as an unsigned driver.
So if you encounter a driver like this and cannot get timely support from the vendor, this is something you can try.
Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .
This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.