July 2010 - Posts
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!
-Chris
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.
MDT 2010 Update 1: Fixed Slow Driver Injection in Lite Touch
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.””
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.
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! 
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:
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!
-Chris
I was having trouble getting my web service to respond, or even browse to make sure it was working. If i tried to connect to the web service via the UDI Wizard Designer, then I would get the following:
If i tried to browse to the web service, then i would get the following:
I noticed after reading the release notes for Update 1, that there is a known issue with UDI and the 404.3 error. Basically stating the following:
“If you receive error 404.3 when browsing to the UDI Designer web service, this error is typically the result of the Windows Communication Foundation (WCF) multipurpose Internet mail extensions (MIME) type not being registered correctly. To register the WCF MIME type on the web server, go to %Windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation. From an elevated command prompt, run ServiceModelReg.exe –I to register the MIME type for the .svc extension, which the web service requires.”
Running this, showed a bunch of components getting installed:
Testing the web browser again, I was not able to browse to the web service:
Also, I was able to connect through the UDI Wizard Designer now as well:
Lesson learned, read the release notes :)
Great article here on TechNet about using USMT 4 with ConfigMgr, includes some direction on USMT4 with Microsoft Deployment Toolkit integration as well.
How to use USMT 4 hardlinking in a Configuration Manager 2007 Task Sequence
-Chris
This topic has come up quite a few times on the forums lately so I wanted to create a post covering how to do this. The most common requests are to make applications mandatory for all task sequences, or for specific task sequences. Be sure to also read Johan’s post here as he has previously covered setting variables per task sequence. We also can just configure applications to be selected by default, but allow them to be unchecked.
Making an application mandatory for all task sequences:
To make an application mandatory for all task sequences, we want to set the MandatoryApplications variable in customsettings.ini
First we will need the GUID of the application we want to make mandatory, this can be found on the application properties tab
Next we will add a MandatoryApplications variable to our [Default] section of the customsettings.ini
If you wanted to add more, then you would just use MandatoryApplications001, MandatoryApplications002 and so on.
If you run the LTI wizard, you will now see that Adobe Reader 9 in this example is now checked by default and grayed out:
Making applications mandatory by task sequence:
Another common request is to make applications mandatory for a specific task sequence. In order to do this, first we have to add some items to our customsettings.ini and change the way our task sequence gathers the data.
First lets add the TaskSequenceID to the Priority line:
Next we will need to find the ID of the task sequence we want to work with:
And then we need to add that to our customsettings.ini as well. Here we’ve added Office 2010 as a mandatory application for my Windows 7 build task sequence.
We also need to change the Gather step on your task sequence to “Gather local data and process rules” and specify “customsettings.ini” for the rules file.
Making an application selected by default, but allow the user to uncheck
The other common request we haven’t covered yet is making an application selected by default, however with the ability to uncheck it. The variable “Applications” will handle that request. In this example we will add .Net Framework 3.5 SP1 as a pre-selected application.
First we need our application GUID again:
Then we need to a new item called “Applications” to our customsettings.ini:
Now when we run the LTI wizard, we will see that the .Net application is selected by default, but we do have the ability to uncheck the application:
Hope that helps.
A friend of mine sent me a link to an old post on the Deployment Guys, this post talked about a Windows Update Downloader program that would go out and download all the updates post service pack for a given operating system.
Here is the post to the Deployment Guys blog.
Here is a video showing you how to build a bootable Windows 7 VHD from the Windows 7 install.wim using diskpart.exe and imagex.exe. Very cool stuff!
http://technet.microsoft.com/en-us/windows/dd758779.aspx
About this Video
This command line demonstration explains how to build a bootable Windows 7 VHD image from a Windows 7 "install.wim" file using diskpart.exe and imagex.exe. The demonstration continues with an explanation of how to configure the boot entry using bcdedit.exe and explains the limitations of VHD Boot. See the Windows 7 VHD Overview page for more information about this technology.
More Posts
Next page »