[mdt] [MDT 2010] Driver Inject: Control Freak method

[PiqueABoo]

Used MDT 2008 for a long time and now slowly playing with 2010 for Win7 etc. and thought "Hmm.. why not play with DriverGroups while they're still there (have seen a suggestion or two the Update 1 might disappear them).

 

So for an initial XPSP3 install I arranged a few by WinXPSP3\%make%\%model% and added a corresponding DriverGroup001 var in the task sequence and so far, unlike a driver selection profile that eventually trawls through the same (virtual in MDT) folder, it doesn't work.

 

Has anyone used DriverGroups? Does it work? If so what did you do differently?

[PiqueABoo]

One of these days I'll post a question someone knows an answer to..

 

Anyway ::screams:: fixed this, it was a sneaky typo in the OOTB drivers structure I'd made (arranged by OS\Make\Model). As a test I tried simplifying it to just OS\Model and that worked, so by-and-by I spotted the difference between what 'wmic csproduct get vendor' said the make was on the test machine and the name I'd typed into the OOTB driver structure.

[Thunderbird311]

One of these days I'll post a question someone knows an answer to..

 

Anyway ::screams:: fixed this, it was a sneaky typo in the OOTB drivers structure I'd made (arranged by OS\Make\Model). As a test I tried simplifying it to just OS\Model and that worked, so by-and-by I spotted the difference between what 'wmic csproduct get vendor' said the make was on the test machine and the name I'd typed into the OOTB driver structure.

 

I know this thread is old, but have run into a similar situation.

 

With my MDT 2010 setup, I had a SQL Express database setup to dynamically determine the make and model. Based on the make and model, my task sequence would inject specific drivers as well as specific applications. This worked really well until I noticed differences in the make and model information in the bios. I have HP EliteBook 8540p laptops. These machines were the same bios revision shipped on the same order from HP, but had differences in the model in the bios. Some of them were 'HP EliteBook 8540p' and some of them were 'HP EliteBook 8540p (VD446AV)'. Caused some of them to get the correct driver and applications, while others didn't.

 

I ended up abandoning the 'single task sequence for all models' approach. I now just have a separate task sequence for each model we use, which ended up being about a dozen. A little more work when updating applications, but easier in the long run than dealing with multiple models in the bios.

[Arthur]

These machines were the same bios revision shipped on the same order from HP, but had differences in the model in the bios. Some of them were 'HP EliteBook 8540p' and some of them were 'HP EliteBook 8540p (VD446AV)'. Caused some of them to get the correct driver and applications, while others didn't.

You may want to look at using model aliases. This would enable you to go back to using a single task sequence for all models.

 

http://blogs.technet.com/b/deploymentguys/archive/2009/09/10/using-and-extending-model-aliases-for-hardware-specific-application-installation.aspx

http://blogs.technet.com/b/benhunter/archive/2007/03/28/bdd-2007-tips-creating-model-aliases.aspx

[PiqueABoo]

but had differences in the model in the bios.

 

Suspect everyone with anything besides Dells has had that problem.. there's a thread somewhere on here where I explained how I worked around it by directly editing ZTIGather.wsf (the script that get the make + model) - essentially just mapping wrong or tricky (e.g. with slashes in them) names to the name I want.

[Arthur]

I forgot about your post re: editing ZTIGather.wsf.

 

My only concern with using this method is that you have to remember to edit the script again when Microsoft overwrites it with a newer version in a future MDT update.