Michael Niehaus' Windows and Office deployment ramblings
Thanks to Rod, Chris, Reed, and others who helped encourage people to check out the driver management survey blog posting I made last night, I was quickly able to get over a hundred replies. Now that’s what I call “instant feedback”. So here’s the interpreted results based on that sampling.
For those of you using MDT 2010 Deployment Workbench and Lite Touch deployments, the breakdown looks nice:
So 21% just import all the drivers and let the system figure it which ones to use on each computer (not too bad when the number of models is smaller). 27% import all drivers and then use selection profiles to control which drivers to use (typically per OS). And the majority of you are taking it even further and leveraging driver folders (DriverGroups), effectively becoming “control freaks”.
While no one said they were using the “install drivers using applications” as their primary mechanism for handling drivers using Lite Touch, over 30% of those using Lite Touch said they were installing at least some drivers as applications once the OS was up and running – basically implementing hybrid scenarios.
For those of you using ConfigMgr 2007, the breakdown is a little different:
So 9% import all their drivers and let the “Auto Apply Drivers” step inject the best one. 24% use “Auto Apply Drivers” with categories to better control which drivers are used. The majority then use “Apply Driver Package”, with 39% importing the drivers into the driver store (the way driver packages were intended to be used) and the remaining following Johan’s approach (not importing drivers, creating driver packages pointing to the physical store).
So a lot of you are importing all of your drivers into the ConfigMgr driver store, but to make that work a significant percentage of you are purposely defeating the ConfigMgr duplicate driver detection by creating a unique file that results in a different has for every driver:
When you drill into the responses a little deeper, several of those that answered “manually handling duplicates” said that they were primarily Dell shops and were using the Dell driver CAB files. As I mentioned in the MMS session, these CAB files include a unique “release.dat” file so they defeat the duplicate detection process, so they are unknowingly in the other category. As a result, the percentages are probably flipped around, with the majority of customers preventing ConfigMgr from detecting duplicates.
So that means almost 60% of ConfigMgr OSD users are somehow working around the driver management challenges in the product (28% following Johan’s advice, and about half of the 63% that are using driver categories and driver packages and defeating duplicate detection, so 28+63*0.50=59.5). I believe the PowerShell scripts I posted can help reduce this number, at least for OSD users willing to reconsider their approach, or new users just setting up their OSD driver management strategy.
As with Lite Touch, about 30% of ConfigMgr OSD users said they were installing some drivers as applications (packages). But again this wasn’t the prevalent mechanism being used, it was being done for selected drivers as part of a hybrid scenario.
There are a variety of tools and sites being used to help with the driver acquisition/extraction process. Johan talked about some of these, like 7-Zip, WinRAR, Universal Extractor, the Windows Update Catalog, and the HP Softpaq Manager, during the MMS session we presented. Others that were mentioned in survey responses included DriverMax, Driver Magician (and the Lite version), DriverGrabber, and the Lenovo Update Retriever. But still the majority of you are still using the manual download-and-figure-out-how-to-extract-without-breaking-your-computer method (the mechanism I was struggling with before MMS).
There was a good deal of praise for the Dell driver CABs, and quite a few calls for other OEMs and vendors to start providing the same type of simple download. But many commented that the OEMs and vendors are still providing too much “junk” in their driver downloads, bloating drivers stores unnecessarily.
Many of you express frustration with mass storage drivers (probably a sign of how many of you are still using Windows XP, as these problems pretty much go away with later OSes). Some of you have run into issues running driver installers during a ConfigMgr task sequence (usually a result of the task sequence running in SYSTEM context with no user profile loaded – these probably are usually the sign of an InstallShield installer that wants to talk to a COM server, but that can’t be used as COM isn’t yet fully initialized while the task sequence is running).
A few of you would like tools to help with driver lifecycle management – helping with the driver store management, delivering driver updates to machines previously deployed, using tools like SCUP to help with driver deployment, making more OEM drivers available automatically through WSUS, etc.
Of course there were plenty of suggestions for things Microsoft could do to help and a few rather frustrated people who just want the whole problem to go away. But there is a larger group (still in the minority for sure) that says they’ve got this process mastered. Let’s hope they all start blogging with all the details of how they’re doing it
Overall, this does pretty much confirm what Johan and I were saying in our session: here are the scenarios that you can consider; here are the pros, cons, and challenges you are likely to encounter in each scenario; here are the tools that can help. Granted, even with a hundred responses this isn’t a statistically valid survey, but it at least gives you some idea of what’s going on in the real world.
As always, if you have any specific feedback or comments, you can e-mail me at mniehaus@microsoft.com or submit comments on this (or any) blog posting.
Johan and I talked about various ways to handle drivers with MDT 2010 (Lite Touch) and ConfigMgr 2007 during our MMS 2010 session. We think we’ve addressed the common options and challenges that you are likely to encounter, but without your feedback we can’t really confirm this.
Could you take a minute of your time and fill out the survey at http://www.surveymonkey.com/s/S55HFPN? It’s very short, with a total of four questions.
If you prefer, you can also add comments to this blog posting or e-mail me directly at mniehaus@microsoft.com.
In the first part of this series, I talked about the three (well, four with Johan’s) approaches for managing drivers with ConfigMgr 2007. There’s actually another method that I didn’t mention so far (one that we briefly mentioned at the end of the MMS session):
Honestly, I didn’t think anyone did this for all of their drivers, although I did expect to see this done for a few limited drivers (such as the more complicated ones I mentioned before). But I have found a couple of customers who do exactly this: every driver is installed as an application. Still, I expect that to be rare in the “real world”.
So that leads us to the topic of “hybrid scenarios” – you can mix and match these scenarios to address all of your driver needs, something I would strongly encourage. Imagine a task sequence that uses something like this:
See Chris Nacker’s blog posting at http://myitforum.com/cs2/blogs/cnackers/archive/2010/04/09/configuration-manager-2007-r2-sp2-driver-management.aspx for a real-world example of how you might set up something like this.
In the session I also showed a simple script that created driver packages pointing to existing folders in the driver store, to quickly set up “Johan’s Control Freak Method”. That script was basically the same script as attached to the previous blog posting, with all the logic for importing drivers into the driver store stripped out, since that logic isn’t used in Johan’s scenario. That script, named CreateJohanDriverPackages.ps1 (which still depends on the SCCM.psm1 module), is attached to this blog posting.
Johan has also added a new blog posting detailing the MDT 2010 Lite Touch scenarios, which you can find at http://www.deployvista.com/Blog/JohanArwidmark/tabid/78/EntryID/132/language/en-US/Default.aspx.
A few other random driver-related items that may be of interest:
In the previous posting at http://blogs.technet.com/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx, I mentioned that it should be possible to script the importing of drivers into the ConfigMgr driver store to help implement the “Added Predictability” (driver categories) and “Complete Control” scenarios by solving the duplicate driver import challenge using PowerShell. So that’s the whole purpose of this posting.
Regardless of whether you want to use driver categories or driver packages, the same logic can be used to import drivers into the ConfigMgr driver store. This assumes that you have your physical driver store arranged appropriately, using Johan’s blog at http://www.deployvista.com/Home/tabid/36/EntryID/82/language/en-US/Default.aspx as an example of how to do that. The attached scripts really take it further than just a recommendation: it’s a requirement for the script to work. The script assumes that you will have a structure that looks something like this:
\\SERVER\DriverStore\XPx86\LatitudeD610\…
\\SERVER\DriverStore\XPx86\LatitudeD630\…
\\SERVER\DriverStore\Win7x86\LatitudeE6410\…
\\SERVER\DriverStore\Win7x64\HPxw8400\…
etc.
You can extract the script file from the Zip file attachment on this blog entry. You can place the ImportAllDrivers.ps1 script wherever you like, but the SCCM.psm1 module must be placed where PowerShell can find it; see the comments at the top of that script for more details.
The ImportAllDrivers.ps1 PowerShell script needs to be modified to specify the UNC path of the physical driver store (it must be a UNC) and the UNC path where the driver packages should be placed (package source folders that should be created). You also can specify whether to create driver packages by OS platform (e.g. “XPx86”) or by OS platform and model (e.g. “XPx86-LatitudeD610”). If you want to use “Apply Driver Package” you’ll want packages per model.
So in the script, edit these three lines as appropriate:
$driverStore = "\\mdt-r2-sccm\DriverStore"
$modelPackage = $false
$packageSource = \\mdt-r2-sccm\Packages
The flow of the script is then like this:
Assuming everything works properly, when this script is complete you can then add the necessary steps to the task sequences (either “Auto Apply Drivers” steps with one specific category selected in each and conditions on each, or “Apply Driver Package” steps with a different package on each and conditions on each), distribute the new driver packages to the needed distribution points, and you’re set to go.
As I mentioned in the session, this script can be run multiple times and should be able to pick up any new folders or drivers added. But it doesn’t contain any logic to remove extra folders or drivers – that’s still going to be a separate effort.
Also, don’t expect the script to run quickly – the process of hashing all the drivers and then copying them into the driver packages takes quite a while. In my test VM which has drivers for about 20 different models of machines (which haven’t been cleaned up much at all) the script runs for hours. If you think about it, you would typically never process that many drivers at one time – you would do this incrementally, probably one model at a time. So the script is not really running that slow – it’s just doing lots of work.
That actually points out another effort that this script doesn’t help with: Cleaning up the physical store. For example, when I downloaded some “Windows 7 x86” drivers from the vendor’s web site, I also got x64 drivers that I might not have needed or already have downloaded separately. I also got Windows XP and Windows Vista drivers that I might not need. And then there’s all the other garbage (Windows Installer 2.x installers, videos, documentation, Linux drivers, MS-DOS drivers, etc.) that can also be pruned from the directory tree. The end result of the downloads and extractions was 14GB of driver files (not including another 6GB from the actual self-extracting installers, but I threw those away), even though only about 10-20% of that is really needed. Maybe someday someone will write a script or tool to help with the management of the physical store too. That’s a much more complicated task though.
I can tell just starting out on this topic that it’s going to be a long one. For those of you who attended the session that Johan and I presented at MMS 2010, we talked about various ways of managing drivers, with Johan focusing on MDT 2010 Deployment Workbench (Lite Touch) and me focusing on ConfigMgr 2007 (Zero Touch). We focused on the whole range of possibilities, ranging from “total chaos” through “complete control freak”, mapping those into the capabilities provided by the product.
Since I focused on the ConfigMgr side of things in the session, I’ll focus on the same thing here. Basically, here’s how it maps out:
As we mentioned in the session, you will probably pick one of these scenarios as the “primary” one for your organization, but these can also be combined into “hybrid” approaches.
Historically I’ve always suggested that people use one of the first three mechanisms, but because of the way ConfigMgr handles duplicate drivers the second (“Added Predictability” with categories) and third (“Complete Control” with driver packages) are challenging, especially if you want to set those up by hand. Various people have proposed solutions around that, including articles like these and various newsgroup postings over the years: http://wbracken.wordpress.com/2009/09/26/adding-duplicate-drivers-to-sccm-sp1/
http://myitforum.com/cs2/blogs/jsandys/archive/2010/04/05/duplicate-drivers-helper-script.aspx
In fact, this is the same solution that Dell has implemented in their driver CABs available for download from http://www.delltechcenter.com/page/Dell+Business+Client+Operating+System+Deployment+-+The+.CAB+Files: They put a “release.dat” file into each driver folder (with different content, to change the directory hash) so that ConfigMgr doesn’t see any of the drivers as duplicates. That certainly solves the problem, but does it by defeating ConfigMgr duplicate detection process altogether. As a result, the ConfigMgr driver store will also end up being much bigger. That “release.dat” file also defeated the duplicate detection in MDT 2010’s Deployment Workbench, so we added explicit logic to look for that file and ignore it when calculating hashes. That way we see the duplicates again (which keeps our driver store as small as possible too).
OK, so how do you implement the “Added Predictability” and “Complete Control” scenarios without either going to Johan’s approach or defeating the duplicate detection (or doing it manually, a process that’s really hard to do as finding the duplicate manually won’t be easy)? That’s where the PowerShell scripts came in. As I discovered early last year when researching this topic, ConfigMgr knows which driver is the duplicate (obviously) and will tell you which one it is when you make the request via the ConfigMgr WMI provider (not so obviously) – you just don’t see that information through the UI. But with a script, you should be able to do something like this:
So the next posting will focus on that part: Using PowerShell to import drivers while handling the duplicates along the way.
Enough “driver babble” for now.
Several people asked me after the troubleshooting session I presented at MMS 2010 how to write a script to dump out all the task sequence variables. Here are a few samples showing how to do just that. (These examples work for ConfigMgr and MDT Lite Touch task sequences.)
First, the absolute “bare bones” approach:
Save that as “DumpVar.vbs” and run it via the task sequence, redirecting the output to a text file. For example, if you saved this script in the MDT “Scripts” folder, you could use a command line like this:
cmd.exe /c cscript.exe "%ScriptRoot%\DumpVar.vbs" >> %Temp%\DumpVar.txt
If you want to get fancier, you can use MDT’s logging capabilities:
Set env = CreateObject("Microsoft.SMS.TSEnvironment") For each v in env.GetVariables oLogging.CreateEntry v & " = " & env(v), LogTypeInfo Next </script> </job>
Save that as “DumpVar.wsf” in the MDT “Scripts” folder, and run it with a simpler command line:
cscript.exe "%ScriptRoot%\DumpVar.wsf"
If you would prefer to use PowerShell, the same thing can be done with it:
# Start the logging Start-Transcript $logFile
# Write all the variables and their values $tsenv.GetVariables() | % { Write-Host "$_ = $($tsenv.Value($_))" }
# Stop logging Stop-Transcript
Save that as “DumpVar.ps1” in the MDT “Scripts” folder, and run it using PowerShell.exe (as long as execution of scripts has been enabled):
PowerShell.exe –File "%ScriptRoot%\DumpVar.ps1"
Here are some related links:
http://blogs.technet.com/deploymentguys/archive/2008/08/29/outputting-all-the-configuration-manager-task-sequence-variables.aspx
http://blogs.technet.com/mniehaus/archive/2009/09/22/running-powershell-scripts-as-part-of-a-task-sequence.aspx
A few people commented on how they could see my Administrator account and password details in the output of the script I was running, as I had specified that account for my ConfigMgr network access account. That’s definitely not a best practice – you should specify an account that has the minimum rights required, typically just enough to connect to your distribution point shares. It should never have domain admin rights. (Yes, I was lazy and just reused the only account I set up in my demo VMs.)
You might wonder why the example script above that uses ZTIUtility.vbs doesn’t log the password. That’s because we have specific logic in that script that refuses to log any line that contains the word “password” as a security feature.
MMS 2010 is bound to be a busy week for everyone attending. But while you’re there, be sure to attend the Birds of a Feather sessions in the evenings. There will be two sessions this year on Windows deployment, both on Tuesday evening. The first one I’ll be moderating:
OE01 Ask the Experts: Microsoft Deployment Toolkit (MDT) 2010 Tuesday, April 20 5:30 PM - 6:30 PM, Marco Polo 702 And if that isn’t enough for you, the session immediately following that, which will be led by Chris Nackers:
OE31 Open Forum Discussion: Microsoft Deployment Toolkit 2010 (MDT) and Configuration Manager 2007 OSD Tuesday, April 20 6:45 PM - 7:45 PM, Marco Polo 702 These sessions are designed for open discussions, so the actual topics discussed will be determined by the questions asked by the audience.
There’s going to be a bumper crop of Windows deployment experts there this year too – hopefully most of them will be able to attend the Tuesday night sessions. Even if they can’t, be sure to track them down during the week to at least say “hi”. Some of those that will be around (assuming the volcanic ash and airlines cooperate) include:
Sorry if I missed anyone, and hope to see you all there.
If you’ve done ConfigMgr OS deployments, you’ve probably seen an error dialog like this before:
Pretty simple, right? Distribute this package to a local DP and then try again. But there are often dozens (or in extreme cases, hundreds) of packages referenced by the package, so you might have to go through this cycle a few times before you get them all. Fortunately, there are some ConfigMgr WMI classes that can help figure out which packages are missing. With a little bit of PowerShell logic, we can automate the whole process, through these basic steps:
This process will take care of boot images, OS images, OS install packages, driver packages, software update packages, or any other type of packages that are referenced (because behind the scenes, packages are packages to ConfigMgr – only the UI differentiates).
The scripts needed to this are attached to this blog. You’ll need to save the SCCM.psm1 file in an appropriate PowerShell module folder (see the comments in the script for more details) so that the CheckTaskSequences.ps1 script can find it (and of course you’ll have to enable PowerShell script execution using something like “Set-ExecutionPolicy RemoteSigned”). Then, just run CheckTaskSequences.ps1 each time you create a new task sequence. It will very quickly identify the packages that need to be distributed and take care of those for you.
Note: Version 1.1 of the script is now attached (using version 1.5 of SCCM.psm1) to address a couple of bugs found in the current version. See the comments in CheckTaskSequences.ps1 for more information.