Different types of mass storage drivers?

Yes, in fact there are two different types:

  • Class=SCSIAdapter.  Until recently, most mass storage drivers specified class "SCSIAdapter," which doesn't mean that they are actually SCSI-based.  Drivers for many IDE/ATA and RAID controllers also fall into this class.
  • Class=hdc. HDC is an abbreviation for "hard disk controller."  Many newer drivers, especially for SATA-based controllers, specify this class.

The MSDN web page at http://msdn.microsoft.com/en-us/library/ms791134.aspx talks about the different classes of drivers, but doesn't get into too much detail about the differences.  For most purposes, you really shouldn't care too much either, unless you are working with products or scripts that need to know the difference.  That brings us to Configuration Manager 2007 and Microsoft Deployment Toolkit: both care about driver classes and need to take into account that there are two different types.  Unfortunately, neither one did when they were released:

  • ConfigMgr 2007 didn't include logic for class=hdc so it only detects class=SCSIAdapter.  The fix for this will be included in ConfigMgr 2007 SP1, due out very soon.
  • Microsoft Deployment Toolkit 2008 did include logic for class=hdc, but one script was missed.  This script, ZTIStorageDriversSysprep.wsf, only inserts class=SCSIAdapter drivers into sysprep.inf.  A companion script, ZTIStorageDrivers.wsf, includes the correct logic, so if you are creative enough (hint: search for "hdc") you can figure out what needs to be fixed.  We'll release a KB with the official details as soon as we can.

If you are using newer hardware that supports SATA disks but you've never run into either of these issues, it might be because you've configured your hardware in ATA or legacy mode, instead of using AHCI mode.  Generally, I believe you should avoid ATA/legacy mode, as you lose some of the benefits of AHCI, including hot plug support (primarily beneficial with eSATA ports, http://www.intel.com/support/chipsets/imst/sb/CS-012308.htm), native command queing (http://www.intel.com/support/chipsets/imst/sb/CS-012305.htm), and on some hardware, RAID array support. 

Keep in mind though that you can't just switch from one to the other without careful planning - because ATA/legacy and AHCI modes require different drivers, Windows has to know about the new driver before making the switch.  See http://support.microsoft.com/kb/922976 for some details on what needs to be done for Windows Vista.  Also check out http://support.microsoft.com/kb/928253 if you have SATA-based optical drives.  Both of those issues are fixed in Windows Vista SP1.

Driver support for common AHCI-based mass storage controllers is included in Windows Vista SP1.  For Windows XP, though, you need to make sure that the right drivers are included in the image.  (That's what ConfigMgr and MDT 2008 are trying to do for you.)

Comments (12)
  1. MDT 2008 Update 1 does include fixes for all the known mass storage driver issues.

    You could choose to do things the old way with $OEM$, TEXTMODE, etc.  If you do that, you can disable the step that runs ZTIStorageDrivers.wsf.

    ZTIStorageDriversSysprep.wsf isn’t dependent on ZTIStorageDrivers, so you could choose to do one and not the other.

  2. Anonymous says:

    I am still having this issue when using MDT 2008 Update 1. I have tried building an image on 2 separate machines, a Dell laptop and an HP desktop. Everything runs perfectly until it runs sysprep. After sysprep is run and the computer restarts, the machine then reboots continuously. Any suggestions?

  3. Sadly, that’s a different bug – the script tries to remove a PnP ID from the list it is tracking without first seeing if it is in the list (e.g. it’s trying to remove two different drivers with the same PnP ID).  We are still working on a fix for that one.

  4. Anonymous says:

    Just to be clear, did you insert this just before the original line 508, so that the if fOKToUse condition check on the original line 508 would fail as a result of your insertion?

  5. There are several reasons the computer could restart – all involve crashes.  So the trick is to stop the machine from rebooting so that you can see what the crash is.  

    When the computer is starting up, you should be able to quicky hit F8.  That should get you to a screen where you can choose "Disable automatic startup".  Then you should be able to see the STOP error on the screen.

    If it’s a STOP 0x7B, it’s a mass storage driver issue.  STOP 0xEA is probably related to KB 931761 (make sure you’ve enabled the Diskpart BIOS compatibility mode step).  Anything else is likely relatd to a driver.


  6. Anonymous says:

    When will a fix for the 32811 error/bug be released?  Any ideas?

  7. We will be releasing an update for MDT 2008 probably in early August containing the fixes for these issues.

  8. Anonymous says:

    Changing the script as decribed leaves me with an error 32811 and a ZTIStorageDriversSysprep.log with the following content at the end:

    <![LOG[DriverPackage is missing txtsetup.oem :  \PLATODistribution$Out-of-box DriversSCSIAdapterahcix86 2.5.1540.35TxtSetup.oem]LOG]!><time="13:51:49.000+000" date="05-20-2008" component="ZTIStorageDriversSysprep" context="" type="1" thread="" file="ZTIStorageDriversSysprep">

    <![LOG[DriverPackage is missing txtsetup.oem :  \PLATODistribution$Out-of-box DriversSystem5000XZV]LOG]!><time="13:51:50.000+000" date="05-20-2008" component="ZTIStorageDriversSysprep" context="" type="1" thread="" file="ZTIStorageDriversSysprep">

    <![LOG[DriverPackage is missing txtsetup.oem :  \PLATODistribution$Out-of-box DriversSystem5000XZV]LOG]!><time="13:51:50.000+000" date="05-20-2008" component="ZTIStorageDriversSysprep" context="" type="1" thread="" file="ZTIStorageDriversSysprep">

    <![LOG[ZTI ERROR – Unhandled error returned by ZTIStorageDriversSysprep: Element not found (32811)]LOG]!><time="13:51:50.000+000" date="05-20-2008" component="ZTIStorageDriversSysprep" context="" type="3" thread="" file="ZTIStorageDriversSysprep">

  9. Anonymous says:

    Is this fixed in MDT 2008 Update 1?

    I have a relatively small number of models. Can I skip using the $OEM$ tactic to manually insert mass storage drivers into my images, and just rely on ZTIStorageDriversSysprep.wsf to fix this for me during image creation?

    Do I also need to use StorageDriverSysPrepGroup to accomplish this?

  10. Konrad says:

    I ran into the second bug and I _think_ I’ve worked around it by inserting some code into the EnumeratePnPDrivers() function to check for the .oem file before it adds it to it’s list of devices.

    At what I think was line 508 of the original file, I inserted the following:

    if fOKToUse then

    Dim sDriver_name, oDevice_extra

    Set oDevice_extra = oDriversXML.DocumentElement.SelectSingleNode("//drivers/driver[@guid=’" & sGUID & "’]/Source")

    sDriver_name = oFSO.GetParentFolderName ( oDevice_extra.Text )

    if not oFSO.FileExists( oEnvironment.Item("ResourceRoot") & Mid(sDriver_name, 2) & "TxtSetup.oem" ) then

     oLogging.CreateEntry  "DriverPackage is missing txtsetup.oem :  " & oEnvironment.Item("ResourceRoot") & Mid(sDriver_name, 2) & "TxtSetup.oem", LogTypeInfo

     fOKToUse = False

    end if

    end if

  11. Anonymous says:

    That is good to know, but in the mean time I have a project deadline and I need to work around it.  

    On the bright side, I have had to dig deep into how MDT works, so I feel like I’m getting a pretty good handle on it now.  After I finish my immediate deliverable, I will compile a summary of the issues I have encountered and the various workarounds I had to implement to get MDT working with XP, as well as some feature suggestions which I have, and post it.

  12. Anonymous says:

    Michael, please help!

    I am using MDT 2008 Update 1. I am installing Windows XP Pro with SP3, and having issues with this right off the bat.

    I am deploying to a VMware Workstation 6.5 VM.

    First I imported the VMware drivers that are used for in VMware Tools, and added them to a driver group VMware. I set my deployment point to use this driver group and then set the WinPE tab to use this driver group. When the task sequence runs, I get a 7B stop error after the text mode reboot. I tried the Diskpart BIOS compatibility step and that did not help.

    Then I set my deployment point to use NO out-of-box drivers and updated the deployment point. Now I can run through the entire task sequence with no errors or warnings, but I get a 7B error after rebooting the reference machine or after loading the wim.

    My assumption here is that no VMware driver is actually needed since the install worked fine all the way up to the sysprep. So if it is using in-the-box drivers, why am I getting an error after the sysprep?

Comments are closed.

Skip to main content