Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.
X

Archive for July, 2010

Aside

Moving sucks…

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 Sad smile

Back at the lists and forums starting next week.  I’m taking the weekend off!

-Chris

Aside

Desktop Image Management: Build a Better Desktop Image

http://technet.microsoft.com/en-us/magazine/ff721826.aspx

Great TechNet article on building your image.

Aside

ConfigMgr – Installing Software Based Drivers

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.

image

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.

image

 

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.

image

On the driver package itself, we use model queries to tell it what models that step will apply to.

image

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. 

image

Then for Bad Driver 1, we’ll set a single HardwareID for an example.

image

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.

image

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.

Aside

MDT 2010 Update 1: Fixed Slow Driver Injection in Lite Touch

Another post by Michael Niehaus on changes in MDT 2010 Update 1.

MDT 2010 Update 1: Fixed Slow Driver Injection in Lite Touch

Aside

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.””

Aside

MDT 2010 Update 1: Added Support for ConfigMgr R3 Prestaged Media

Another post by Michael Niehaus on changes in MDT 2010 Update 1

MDT 2010 Update 1: Added Support for ConfigMgr R3 Prestaged Media

Aside

MDT 2010 Update 1: New Posts By Michael Niehaus On Changes In 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.

MDT 2010 Update 1: Scripts Changed

MDT 2010 Update 1: Task Sequences Changed

MDT 2010 Update 1: Fixes to ConfigMgr Task Sequence Template Error Handling

MDT 2010 Update 1: Fixes to ConfigMgr State Migration Point Scenarios

Aside

Customizing Default Users Profile Using CopyProfile In Unattend.xml

Here is a great post over on TechNet by Jeff Hugh on how to properly use the CopyProfile feature:

http://blogs.technet.com/b/askcore/archive/2010/07/19/customizing-default-users-profile-using-copyprofile.aspx

This is a great read and covers both ConfigMgr and MDT usage. 

Aside

Understanding Site to Site Communication in SMS/SCCM

Steve Rachui has put together a fantastic post on SMS/ConfigMgr site to site communication located here:

http://blogs.msdn.com/b/steverac/archive/2010/07/16/understanding-site-to-site-communication-in-sms-sccm.aspx

It’s long, but a good read. And you thought I posted long posts! Smile

Aside

MDT/ConfigMgr – UDI – Having Multiple Configurations For the UDI Wizard (UDIWizard_Config.xml)

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.”

To override the configuration file that the Operating System Deployment (OSD) Setup Wizard uses

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:

image

Next, we will want to edit our task sequence:

image

First, we need to to go the first UDI Wizard step located under the State Capture phase:

image

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:

image

Perform the same actions for the UDI Wizard step under Preinstall/New Computer Only:

image

Perform this on any other custom step you might have added that calls the UDI Wizard, then click OK to save your changes:

image

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.

image

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”.

image

image

image

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.

image

Here is a bone stock customsettings.ini file:

image

Here we’ve added a custom property of “UDIXMLFile”, and we’ve configured a value of UDIXMLFile=UDIWizard_Config_2.xml

image

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.

image

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.

image

Just a quick example to show you some of the possibilities. 

Hope this helps!

-Chris