Let’s take a short trip back in time, shall we? A few years ago, a certain large software maker in the great state of Washington shipped an operating system we’ll lovingly call CrapOS 1.0. This OS was much anticipated by the masses as it had been in development for upwards of four years. It is rumored that the operating system’s kernel was torn-down and recoded multiple times (three? four? Accounts vary). It was the next big thing. It had native 64-bit support and a ton of other features. As I am an 8th-level beta-wonk and uber geek, I loaded up the first beta on my home PC and spent the next two days trying to get all manner of devices to work – not limited to but including my printer, my mouse and my display adapter – with only partial success (I never got the printer working) and performance only a dial-up user could love, then I tore it down and went back grudgingly to XP.
Such was the fate of Vista (nee: CrapOS 1.0). It’s perhaps the biggest blunder Microsof
t has ever made (you can’t really consider Microsoft Bob a blunder; it’s more like temporary insanity), even worse than Clippy (at least you could sort of turn Clippy off).
I wasn’t alone in this experience, and the driver and performance issues continued through the various beta releases right through to the shipping product. For my own personal use, I had long written Vista/CrapOS off based on that initial driver torture trial, but that didn’t solve the business problem I faced: XP was now an outdated operating system, and the obsolecensce clock was a-ticking away. So I spent some time at work figuring out what it would take to deploy CrapOS 1.0, once again getting paid to drive technology nails into steel rods with my forehead.
The driver issues were bad enough, but the anemic and bug-ridden enterprise deployment tools that shipped in concert with Vista were no better. For instance, there was no way to automatically join a Vista PC to a domain. Hello? Microsoft? Hello? Anybody home? The application compatibilty toolkit was a joke. And the drivers…oh the drivers… at the time, we had some 1,200 network printers where I work, representing (at the time) several hundred different print drivers (why so many network printers you ask? Well, it’s part of our strategy to have one networked printer for every employee…). Almost 2/3 of these had no Vista version; the ones that did came with the usual assortment of “helpful” printing software crud that vendors like HP love to dish out and is wonderful for crashing print servers (and for telling you to order more toner or inkjet cartridges long before you need to). So I didn’t really kill myself figuring out how to deploy Vista enterprise-wide; instead I simply calculated how many new PCs we would need to replace our underpowered 512MB RAM Pentium IV desktops, how many 
other PCs would require additional RAM and new display adapters, and rolled all that yummy goodness that into a big, scary number. Then I waited for the right moment and frightened the beejezus out of my management in a meeting one day.
Crisis averted. Having done my duty, I quickly decided that discretion is the better part of valor and headed for the relative safety of web development, where I happily spent the next three years playing with jQuery.
Fast forward a few years…to like … uh … well, let’s just say now for simplicity’s sake. Microsoft – who can still turn the battleship on a dime like no other company its size – has released Windows 7 (and the first Service Pack, with the next in beta as I write this), which is everything Vista 
should have been and more. Windows 8 is about to come rushing down on us, sending Silverlight and WPF developers into the abyss of paranoia and insanity, and promises to be a game changer to Redmond. Oh, and I’m no longer on the Web Team, and it’s kinda sorta my job again to look at things like the enterprise deployment of Operating Systems, so it was not without trepidation and sweaty palms that I began recently to look at deploying Win7, and in particular how to handle the plethora of drivers it will need to support.
Good News, Kids!
One of the things Microsoft has done most right in the Windows 7 deploymenet space is to ship the Microsoft Deployment Toolkit which is a) free and b) actually works! They have also released the abominably named System Center Configuration Manager 2007 product which isn’t free but can also play a vital role in your Win7 deployment. I’m going to limit myself to discussing just MDT here for brevity’s sake, because I do want to show you Microsoft has listened and addressed driver management with MDT, and OSD (Operating System Deployment) in SCCM is powerful, but complex.
Drivers, Drivers Everywhere…
I remember the old Steve Martin joke: “Here’s how you can have a million dollars and never pay taxes…! First, get a million dollars…”. Step one is you need all the drivers for the hardware you will be deploying to. In the MDT docs, this is summed up in one sentence. “Get all the drivers you’ll need.” Different hardware vendors have different ways of helping you to do this. Dell, for instance, gives you all their drivers in an MDT-compliant CAB file which you can download and use. Lenovo, on the other hand, makes you download each driver for each model individually, which – besides being mind-numbingly boring – is a serious waste of anyone’s time. But whatever. Once downloaded (and expanded etc. etc.), you end up with a driver store that looks something like this in the file system:
And if you want to know how many hours I spent on those Thinkpad drivers, well…I ain’t gonna tell ya!
Now you can import the drivers into MDT, and you end up with something like this:
Now, you don’t want to inject all your drivers into every PC you deploy. That’s wasteful and stupid since doubtless conflicts will occur and ugliness will ensue. You can control which drivers get injected into the OS via two MDT features: Selection Profiles and Task Sequences.
MDT comes with a number of selection profiles but you can add your own. In my case, I have added the following:
I can combine these selection profiles with MDT task sequences to ensure that only the drivers for the particular device I’m deploying to get injected. You can do this by replacing the default “Inject Drivers” Task Sequence step with a new Task Sequence group, and creating Inject Drivers steps for each model, as shown here:
Note that for each injection step, I have selected the corrsponding selection profile. But how, you ask, can I prevent the other injections from occuring? Aren’t I just really injecting all drivers, just like I said it was bad to do?
Nope, ’cause I like WMI. WMI (or Windows Management Instrumentation for anyone who cares) is Microsoft’s implementation of the WBEM specification. WMI provides a SQL-like querying syntax which can be applied to the Driver Injection steps to filter out devices which aren’t the appropriate make or model. For instance, if you look at the example above, you’ll see this driver injection should only occur on Lenovo ThinkCentre M90 desktops, since those are the only drivers we’re injecting. I can ensure that this happens as expected, to wit:
The query shown above is set in the “Options” tab of the Driver Injection step and filters the devices down to those with are M90 PCs. Each of these Driver Injection steps has a simliar query. Now I have a (more) easily managed driver store, and still only deploy the appropriate drivers to each device. This is goodness; this is coolness.
(The WMI-literate among you may be asking why I’m querying the ComputerSystemProduct class and the Version property to get the model of the device. This has to do with Lenovo’s somewhat off-kilter WMI choices. Whereas all other vendors that I’ve encountered use the Manuafacturer and Model properties of the ComputerSystem WMI class, Lenovo uses this. Whatev’, it works.)
The SCCM product is even more powerful in this regard, although you can also use WMI filtering within its tasks to get the same effect. Overall, Microsoft has gotten this right, and as a result, we probably will actually upgrade our OS this year…
Well, at least we’ll start.
Maybe. I hope so.
No promises.
