Mass Storage / SATA Driver injection during OSD HII deployment?

Michael,

of course you will have an effect, because you are going to use ONE sysprep.inf with ONE image for all of your HW. But I won't expect any issues if you do it right.

It's some time ago I used to do this and since then I got rusty, but let's see how far my knowledge still goes:

You can use the BuildMassStorageSection=YES, but it will produce a lot of stuff you won't need. I prefer to put only the drivers I need by hand into the SysprepMassStorage section. To give you an example:

[Sysprep]

[SysprepMassStorage]
; (Windows Standard) Standard IDE
primary_ide_channel=c:\windows\inf\mshdc.inf
secondary_ide_channel=c:\windows\inf\mshdc.inf
; (Windows Standard) Intel 8000xxx ...
pci\ven_8086&dev_24d1=c:\windows\inf\mshdc.inf
pci\ven_8086&dev_24db=c:\windows\inf\mshdc.inf
; Intel SATA ICH6, ICH7, ICH8
PCI\VEN_8086&DEV_282A&CC_0104=C:\Windows\inf\BRDUS\F6MassStorage\IntelSATA\iastor.inf
PCI\VEN_8086&DEV_2829&CC_0106=C:\Windows\inf\BRDUS\F6MassStorage\IntelSATA\iaahci.inf
PCI\VEN_8086&DEV_2822&CC_0104=C:\Windows\inf\BRDUS\F6MassStorage\IntelSATA\iastor.inf
PCI\VEN_8086&DEV_2821&CC_0106=C:\Windows\inf\BRDUS\F6MassStorage\IntelSATA\iaahci.inf
PCI\VEN_8086&DEV_2682&CC_0104=C:\Windows\inf\BRDUS\F6MassStorage\IntelSATA\iastor.inf
PCI\VEN_8086&DEV_2681&CC_0106=C:\Windows\inf\BRDUS\F6MassStorage\IntelSATA\iaahci.inf
PCI\VEN_8086&DEV_27C3&CC_0104=C:\Windows\inf\BRDUS\F6MassStorage\IntelSATA\iastor.inf
PCI\VEN_8086&DEV_27C6&CC_0104=C:\Windows\inf\BRDUS\F6MassStorage\IntelSATA\iastor.inf
PCI\VEN_8086&DEV_27C1&CC_0106=C:\Windows\inf\BRDUS\F6MassStorage\IntelSATA\iaahci.inf
PCI\VEN_8086&DEV_27C5&CC_0106=C:\Windows\inf\BRDUS\F6MassStorage\IntelSATA\iaahci.inf
PCI\VEN_8086&DEV_2652&CC_0104=C:\Windows\inf\BRDUS\F6MassStorage\IntelSATA\iastor.inf
PCI\VEN_8086&DEV_2652&CC_0106=C:\Windows\inf\BRDUS\F6MassStorage\IntelSATA\iaahci.inf
PCI\VEN_8086&DEV_2653&CC_0106=C:\Windows\inf\BRDUS\F6MassStorage\IntelSATA\iaahci.inf
;Start: HP SmartArray SATA
PCI\VEN_103C&DEV_3230&SUBSYS_323E103C=C:\Windows\inf\BRDUS\F6MassStorage\HP_SATA\HpCISSx2.inf
PCI\VEN_103C&DEV_3230&SUBSYS_3223103C=C:\Windows\inf\BRDUS\F6MassStorage\HP_SATA\HpCISSx2.inf
PCI\VEN_103C&DEV_3230&SUBSYS_323D103C=C:\Windows\inf\BRDUS\F6MassStorage\HP_SATA\HpCISSx2.inf
PCI\VEN_103C&DEV_3220&SUBSYS_3225103C=C:\Windows\inf\BRDUS\F6MassStorage\HP_SATA\HpCISSx2.inf
PCI\VEN_103C&DEV_3230&SUBSYS_3234103C=C:\Windows\inf\BRDUS\F6MassStorage\HP_SATA\HpCISSx2.inf
PCI\VEN_103C&DEV_3230&SUBSYS_3235103C=C:\Windows\inf\BRDUS\F6MassStorage\HP_SATA\HpCISSx2.inf
PCI\VEN_103C&DEV_3230&SUBSYS_3237103C=C:\Windows\inf\BRDUS\F6MassStorage\HP_SATA\HpCISSx2.inf
PCI\VEN_103C&DEV_3238&SUBSYS_3212103C=C:\Windows\inf\BRDUS\F6MassStorage\HP_SATA\HpCISSx2.inf
PCI\VEN_103C&DEV_3238&SUBSYS_3211103C=C:\Windows\inf\BRDUS\F6MassStorage\HP_SATA\HpCISSx2.inf
PCI\VEN_103C&DEV_3232&SUBSYS_40A00E11=C:\Windows\inf\BRDUS\F6MassStorage\HP_SATA\HpCISSx2.inf
;End: HP SmartArray SATA
; HP SmartArray SCSI 5300, 5i, 532, 5312, 6i, 641, 642, 6400, 6400EM
PCI\VEN_0E11&DEV_B060&SUBSYS_40700E11=C:\Windows\inf\BRDUS\F6MassStorage\SmartArray5i6i\cpqcissm.inf
PCI\VEN_0E11&DEV_B178&SUBSYS_40800E11=C:\Windows\inf\BRDUS\F6MassStorage\SmartArray5i6i\cpqcissm.inf
PCI\VEN_0E11&DEV_B178&SUBSYS_40820E11=C:\Windows\inf\BRDUS\F6MassStorage\SmartArray5i6i\cpqcissm.inf
PCI\VEN_0E11&DEV_B178&SUBSYS_40830E11=C:\Windows\inf\BRDUS\F6MassStorage\SmartArray5i6i\cpqcissm.inf
PCI\VEN_0E11&DEV_0046&SUBSYS_40910E11=C:\Windows\inf\BRDUS\F6MassStorage\SmartArray5i6i\cpqcissm.inf
PCI\VEN_0E11&DEV_0046&SUBSYS_409A0E11=C:\Windows\inf\BRDUS\F6MassStorage\SmartArray5i6i\cpqcissm.inf
PCI\VEN_0E11&DEV_0046&SUBSYS_409B0E11=C:\Windows\inf\BRDUS\F6MassStorage\SmartArray5i6i\cpqcissm.inf
PCI\VEN_0E11&DEV_0046&SUBSYS_409C0E11=C:\Windows\inf\BRDUS\F6MassStorage\SmartArray5i6i\cpqcissm.inf
PCI\VEN_0E11&DEV_0046&SUBSYS_409D0E11=C:\Windows\inf\BRDUS\F6MassStorage\SmartArray5i6i\cpqcissm.inf
;VMware BusLogic
PCI\VEN_104B&DEV_1040=C:\Windows\inf\BRDUS\F6MassStorage\vmBusLogic\vmscsi.inf
;VMware LSI
PCI\VEN_1000&DEV_0622=C:\Windows\inf\BRDUS\F6MassStorage\vmLSI\symmpi.inf
PCI\VEN_1000&DEV_0624=C:\Windows\inf\BRDUS\F6MassStorage\vmLSI\symmpi.inf
PCI\VEN_1000&DEV_0626=C:\Windows\inf\BRDUS\F6MassStorage\vmLSI\symmpi.inf
PCI\VEN_1000&DEV_0628=C:\Windows\inf\BRDUS\F6MassStorage\vmLSI\symmpi.inf
PCI\VEN_1000&DEV_0030=C:\Windows\inf\BRDUS\F6MassStorage\vmLSI\symmpi.inf
PCI\VEN_1000&DEV_0032=C:\Windows\inf\BRDUS\F6MassStorage\vmLSI\symmpi.inf
PCI\VEN_1000&DEV_0050=C:\Windows\inf\BRDUS\F6MassStorage\vmLSI\symmpi.inf
PCI\VEN_1000&DEV_0054=C:\Windows\inf\BRDUS\F6MassStorage\vmLSI\symmpi.inf
PCI\VEN_1000&DEV_0058=C:\Windows\inf\BRDUS\F6MassStorage\vmLSI\symmpi.inf
PCI\VEN_1000&DEV_005E=C:\Windows\inf\BRDUS\F6MassStorage\vmLSI\symmpi.inf
PCI\VEN_1000&DEV_0640=C:\Windows\inf\BRDUS\F6MassStorage\vmLSI\symmpi.inf
PCI\VEN_1000&DEV_0642=C:\Windows\inf\BRDUS\F6MassStorage\vmLSI\symmpi.inf

As you can see, I tell Windows that my mass storage boot-device will either be standard IDE, Intel SATA (ICH6, 7 or 8 architecture), HP SmartArray SATA, HP SmartArray SCSI 5300, 5i, 532, 5312, 6i, 641, 642, 6400, 6400EM or one of the VMware SCSI devices. And that's it  - not one of the myriad of the other devices that Windows supports right out of the box. BTW: I don't really install Windows XP on HP server class HW ;-)

Remember to put these entries into sysprep.inf before you start sysprep.exe and leave the driver files in the image. You can't inject new mass storage drivers and append them in sysprep.inf while in OSD! Windows won't recognize them and may be unable to boot into mini-setup. In this respect mass storage (better: boot mass storage) is different from PnP hardware, which isn't to be accessed to boot Windows.

bis denn dann

Carsten

I used to preach that injecting mass storage drivers can't be done. You can't inject a mass storage driver the way you inject a NIC or a video driver because the machine blue screens (code 7B, inaccessible boot device) before mini-setup gets chance to run.

Or can you? If you read the latest version of the HII whitepaper (pick it up from droppedpackets.org), you may have noticed that I'm changing my mind.

The recommendation remains to include all the mass storage drivers that are going to be needed in your image, exactly as Carsten says. But if you have to inject a mass storage driver, it can be done. The whitepaper describes 2 ways of doing it.

GREAT Document... It sure has come a long way since the first revision... =) what would you recommend for situations where your imaging a machine using provisioning that exists in LANDesk and Active Directory. I would think since the Image is syspreped the SID will be different so the old computer account should be deleted. I was thinking of using like DSMOD and DSQuery to check for the computer account and if it exists delete it. It will be rejoined during the sysprep process...

I did notice if the binding account used in the sysprep joining process is a domain admin it will just overwrite the old computer object... In situations like this would you recommend deleting the account prior to imaging?

Thanks in advance.

I suppose you were looking at Fig 14 in the document. It shows what an OSD script using injectmsd might look like. And you noticed that the injectmsd command line in the sample script refers to a path like c:\drivers\msd. And you wondered where that came from. You seem to believe that c:\drivers\msd is stuff that came embedded in the image. It isn't. All of c:\drivers is HW dependent content that has just been copied from a server a few lines before.

I know it's a lot to ask - it's a big document - but you'll need to make an effort to understand the complete process. Look again at Fig 14 and work out what the other command lines do. It's all in the document. You can't understand any part of it in isolation.

When I try to imagine what you are doing today, you probably have a UNC share with 3 driver folders called 755s, 760s, and 960s. In your OSD script, you xcopy one of these folders to c:\drivers, depending on machine type. If you are going to use injectmsd, you just add one subfolder called msd to each of the drivers folders on your server. You populate them with the output of capturemsd. So when you xcopy an appropriate driver subtree depending on your machine type, one of the subfolders that gets copied is the correct msd subfolder dor that machine type.

So part of setting things up is you take a fully installed machine of each type, you run capturemsd on each one and you store the output in the msd subfolder for that machine type. There's nothing to do at sysprep time. No SysprepMassStorage section to set up.

In my original test setup, I took an image of an IDE machine and deployed it to one SATA and one SCSI machine. In the first real-life exercise, a partner used the process to deploy an exisitng image (again, IDE based) to 4 or 5 different types of Dell machines with a couple of different SATA controllers. But as I state in the document, consider it an experimental process. Try it before you believe it.

If you have already built a master image with all relevant mass storage drivers syspreped in it (i.e. through SysprepMassStorage), don't embark on this new process. Consider using it the first time you'll need to add yet another mass storage driver.

Ryse,

Not quite sure I get your point. I suppose we agree on the mechanics. Sysprep kills the SID so when the machine comes out of mini-setup, it has a new SID and has to join the domain again

I don't know that there is an established best practice on this, but I suppose you would always take the machine out of the domain before you sysprep it. Which kills the machine account in AD. Not sure why you need to do anything more than that. The only trouble you can get yourself into, I would imagine, is you sysprep a machine without first taking it out of the domain. The damage would be one dead machine account and nothing worse. Or am I missing something?

Sorry for the bad explanation.. Perhaps a senario will help explain my question..I have a hardware Independent Image which is syspreped and used as a base image for all imagaing we do. (The sysprep.inf file has a variable called %ldap% which is populated in the MachineOU= section of the file.) Lets say there is a classroom of 40 computers that are currently joined to the domain to an OU called Room 103. Now after a few month's we decide we want to re image these same 40 computers. The machine names are going to stay the same. During the provisioning process in WinPE a script will run which parses the computer name to determine it's Ldap information, it will then replaces the %ldap% variable.

Now when these machines reboot during the sysprep process they will join to the domain with the same computer name and OU information that already exists... So in these types of senarios where existing computers need to be reimaged and keep the same name is it best to delete the account first or does it not matter since I am joining to the domain during the sysprep process with a domain admin.. From my expereince the account is just over written and it joins to the domain fine. I bet I would not even have to have the machineOU section in the sysprep file for  machines that are being reimaged and already exist in AD. It will just take ownership of the existing account??

Since I built this imaging process I never deleted the computer account's..I started to think about it the other day and started to question why it works being that the machine now has a NEW SID from the sysprep process, but Came to the conclusion that since im joining with the domain admin account it just writes over the old object.. Do you agree?? If this is the case then I would think there is no reason to delete account's of machines that are going to be re imaged..

If my theory is not true then how are people out there handeling situations like this where they need to reimage computers that are already joined to the domain... Deleting the accounts first then dropping the image down?

Thanks! Hope I explained my self better this time!!

OK I can see your point now. I have no special insights to offer but maybe others do.

Maybe it would be better to move this discussion to a new thread because it has nothing to do with the original topic.

Will do.  I do however, have a question regarding your document. I read through it again tonight and im a bit confused on this part here.

"When using provisioning, you are not limited to these two mechanisms. As under OSD,
you probably want to use the cmdlines mechanism for drivers that must be installed at
mini-setup time, before the reboot initiated by mini-setup. But for additional drivers, you
may prefer not to use RunOnce. Instead, you would adhere to a convention whereby each
machine specific driver folder has a batch file that always exists (although it may be
empty), and that is run by provisioning action (e.g. cmd /c c:\drivers\setup\setupdrv.bat)."

Which provisioning action?? Would that batch file just run the same commands in the cmdlines.txt file?

In regards to the drivers section - A year ago I built the first drive archive by grabbing the c:\drivers folder from  new dell machines prior to doing any configuration on them. It worked great because those were the exact drivers they used for there provisioning process.I figured there was a way to inject the mass storage drivers but never actually gave it a try.. Glad you guys got it working.. Thanks for the links to the driver export utilities as well this will come in handy!

Cheers

The reason why I put this in is that I don't much like GuiRunOnce. Why? Because it requires you to configure auto-logon. If you don't, the GuiRunOnce stuff won't run until the first end-user logon - provided that user has admin rights.

Most drivers can be installed without running a setup program. Just make sure mini-setup can find the inf file and that's all it takes. But some of time, your drivers will require running a setup program. WinXP/Win2K3 provide 2 mechanisms to run driver setup programs: one (cmdlines.txt) before the initial reboot, another one (GuiRunonce) after the initial reboot. Most of the time, if you need either mechanism at all, it doesn't matter which one you chose. But it does matter often enough that you need both mechanisms. I've seen situations where things went wrong unless you run the right setup program pre or post-reboot.

The point I'm making in this particular quotation is that, if you have a driver that must be installed with a stup program, and if the setup program must run post-reboot, and if you are are using provisioning, you can avoid the issues mentioned above with GuiRunOnce. Create an execute program action in the System Configuration section of your template. Run a batch file that you have downloaded as part of the hardware dependent content. The batch file might be empty, ot it might run setup commands that you would otherwise have launched from GuiRunOnce...

Jan,

Thanks for including the Autoitscript source - good stuff.