Michael Niehaus' Windows and Office deployment ramblings
Yes, in fact there are two different types:
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:
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.)
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 : \\PLATO\Distribution$\Out-of-box Drivers\SCSIAdapter\ahcix86 2.5.1540.35\TxtSetup.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 : \\PLATO\Distribution$\Out-of-box Drivers\System\5000XZV 188.8.131.521\TxtSetup.oem]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">
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.
When will a fix for the 32811 error/bug be released? Any ideas?
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
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?
We will be releasing an update for MDT 2008 probably in early August containing the fixes for these issues.
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.
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?
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.
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?
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.
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?