Archive for July, 2010
Little bit of a hiatus from the forums and lists for me for the past week. I had to pack up everything I own into my truck and trailer, drive 21 hours across the country and then unpack it.
Turns out that isn’t so fun
Back at the lists and forums starting next week. I’m taking the weekend off!
Great TechNet article on building your image.
In addition to the driver management methods that I’ve blogged about before, I wanted to create a post showing how I typically handle “bad” drivers, or drivers that are software based. These would be drivers we can’t manage through normal PNP detection (auto-apply) or through driver groups (“forced” injection), usually they are MSI based or setup.exe based as well.
So what I’d like to do here, is show you a few common approaches to handling how to install the software, sort of a good, better, best approach. All of these methods do work, so feel free to use the approach that works best for you. I’m using a bunch of generic names and models instead of specific vendors as I don’t want to give the impression that one vendor is “better” than others.
Installing drivers on a per manufacturer and/or model basis (good)
The first method involves creating a structure in your task sequence for each manufacturer and model you might have. This gives you some very good organization, and it’s nicely laid out. However the negative here is that you could be listing the same drivers for multiple models. If you add a new model, then you would need to create new steps and match up the appropriate drivers. If you have a large organization with a lot of models and manufacturers, your task sequence could get very large.
We use a model query on the model steps to limit those to only run on a per-model basis. Anything under that step will then run on the given model.
Installing drivers on a per driver basis with model detection (better)
One way to improve upon the previous method is to create steps for the various drivers themselves, and then add queries for the models they support. This allows for more flexibility. If you add a new model that uses the same driver, you just have to add another query for it work. This method has fewer steps in your task sequence than the previous method.
On the driver package itself, we use model queries to tell it what models that step will apply to.
Installing drivers based upon the HardwareID (best)
The method I prefer for installing these types of drivers is based upon the HardwareID. Just like we do for mass storage drivers. This allows the most flexibility you don’t have to worry about new model support, as long as the HardwareID matches, the driver will install successfully on your systems. This is the cleanest method and allows for the fewest steps in your task sequence.
Then for Bad Driver 1, we’ll set a single HardwareID for an example.
For Bad Driver 2, here’s an example when the driver could apply to multiple HardwareID’s. We’ve set a “If any conditions are true”, so it’ll run as long as there is a single match.
So, just like we can use the HardwareID to detect and inject the correct mass storage driver for Windows XP, we can also use it to install “software”.
Hope that helps.
Another post by Michael Niehaus on changes in MDT 2010 Update 1.
Improving Your Image: Sector-Based, File-Based, and Sysprep – What Makes the Most Sense? Part 1: Terms and Windows Tools Primer
Jeremy Chapman has created the first blog in a series on the benefits of using package based imaging tools.
Read the first post here.
“Welcome to blog number one in the series of imaging and image composition. Last week, Stephen kicked off the series in the Springboard Series Insider Newsletter and I’ll try to get through this in three or four blog posts, but the nature of this discussion can almost be constituted as a religion. In that sense, there is never a perfectly correct answer. Like any good IT pro, when someone asks a question like what is the best way to do imaging, manage drivers, etc. – you’ll typically want to respond with “it depends.””
Another post by Michael Niehaus on changes in MDT 2010 Update 1
Michael has been putting up a series of posts on some of the changes incorporated in the Microsoft Deployment Toolkit Update 1. Here are a few he’s posted so far.
Here is a great post over on TechNet by Jeff Hugh on how to properly use the CopyProfile feature:
This is a great read and covers both ConfigMgr and MDT usage.
Steve Rachui has put together a fantastic post on SMS/ConfigMgr site to site communication located here:
It’s long, but a good read. And you thought I posted long posts!
By default the UDI based task sequence will use the UDIWizard_Config.xml contained in your MDT 2010 Update 1 toolkit package. What if you want to use the same toolkit package for multiple task sequences, but provided different versions of the UDI wizard? For example, if you have different domains you want to join, or possible different applications to be presented to the user, or even skip screens for some task sequences. Well that is possible, but it’s buried in the documentation!
Reading The Documentation
First, here are the steps outlined in the MDT documentation under the section “Configure the OSD Setup Wizard Behavior.”
1. In the Configuration Manager Console, go to Computer Management/Task Sequence.
2. Right-click task_sequence (where task_sequence is the name of the task sequence you want to edit), and then click Edit.
3. Beneath the State Capture phase, click the UDI Wizard task sequence step.
4. On the Properties tab for the UDI Wizard task sequence step in Command line, modify the text as follows (where path is the path to the configuration file which is relative to the Scripts folder and file_name is the name of the configuration file)
(If you put the xml files in the \scripts folder of your toolkit package, you don’t need to specify a path value, just as you will see I didn’t specify a path in my example below):
cscript.exe “%DeployRoot%\Scripts\UDIWizard.wsf” /definition:path\file_name.xml.
Note The above text appears on one line. The line wrap seen here is the result of document formatting constraints.
5. Repeat steps 3 and 4, substituting State Capture with Preinstall/New Computer Only.
6. Repeat steps 3 and 4 for any custom task sequence steps that run UDIWizard.wsf.
7. Click OK.
Performing The Steps
Now, lets show you how to actally do that.
First, in my toolkit package, you can see i have 2 definition xml’s:
Next, we will want to edit our task sequence:
First, we need to to go the first UDI Wizard step located under the State Capture phase:
Then we need to update our command line to add the /definition command and tell it what file to use, if you put the XML in the \scripts folder of the toolkit package then you won’t have to specify a path value here, you can just specify the file:
Perform the same actions for the UDI Wizard step under Preinstall/New Computer Only:
Perform this on any other custom step you might have added that calls the UDI Wizard, then click OK to save your changes:
Now, when we run the task sequence on our client, we’ll see the new welcome page i created to ensure that I’m using the new configuration instead of the default UDIWizard_Config.xml.
Using A Custom Variable To Define The XML
Now another interesting way to set a different XML is to take advantage of the MDT integration and use a custom variable. This would allow you have a single task sequence that could call any number of UDI config xml’s. You could take that a step further and use any number of MDT rules to define how that XML gets set, like based upon the location, or chassis type, or a plethora of other things, way cool! I think this is a fantastic idea and was proposed to me by Michael Niehaus in an email exchange we had. So lets show you how to do that.
First lets change our task sequence to use a custom variable we’ll call “UDIXMLFile”.
Next we will need to configure the customsettings.ini file for our settings package for this task sequence. So here is the package I am going to modify.
Here is a bone stock customsettings.ini file:
Here we’ve added a custom property of “UDIXMLFile”, and we’ve configured a value of UDIXMLFile=UDIWizard_Config_2.xml
Next, save your changes and make sure to update the distribution point for your settings package. Again we launch the task sequence on our client to verify it’s using the XML file we want.
So how about an example were we set different XML’s based upon the DefaultGateway. Here we’ll set a UDI config XML based upon whether you are in London or the United States. Maybe it’s something as simple as having a different welcome page message, or you’ve configured different OU’s to be selectable. Here is an example customsettings.ini where we’ve configured either a UDIWizard_Config_2 or UDIWizard_Config_3 file to be used depending on where you are located.
Just a quick example to show you some of the possibilities.
Hope this helps!