Preinstalling IE10 on Windows 2008 R2/Windows 7 could cause issues in MDT 2012

I was updating our current Windows 2008 R2 image for MDT with all the latest security updates and ran into an annoying issue. After capturing the image and deploying it to VM (or a physical machine) I kept getting the error “Windows could not parse or process the unattend answer file for pass [specialize]”. I thought this was really odd because MDT created the Unattend.XML file for me. The same process has worked for me for over a year, why all of a sudden did it stop working?

I found my answer at this link. I must of accidently installed IE10 when doing my security updates. In the unattend.xml file there is a line for IE9 called . This does not existing in IE10 so it causes the specialize phase of Sysprep to fail. Below is a excerpt from the unattend.xml file that was causing the issue. You just need to comment out the line  <IEWelcomeMsg>  and you should be all set.

DISM GUI 3.5 Released

It’s been almost a year since the last release but I just uploaded DISM GUI 3.5 to the Codeplex site this morning.  It contains a few background bug fixes and a few new features.  For this version I have kept it compatible with the Windows 7 WAIK and DISM version.

• Added Edition Servicing tab
• Added the ability to apply and unattend file
• Added application servicing tab

It’s not a major release but adds most of the features available in the Windows 7 DISM program.  You will notice that there is no “online” functionality to allow it to operate on the running OS.  That is something I had planned to put in but was proving hard than I thought with the current version.  I’m hoping to include that in version 4.0

Speaking of version 4.0.  I don’t have a timeframe to release it yet but I do have some of the features planned.

• Online mode – Allow DISM to be used against the currently running OS.
• Windows ADK compatibility – The next version will rely on the Windows ADK and DISM version included in it.
• WinPE compatibility – I am planning on making the next version work inside WinPE.
• Powershell backend – This one is still up in the air but I may convert the backend to the new Powershell cmdlets instead of relying on DISM.exe.

There might be more features added but this is what I am planning now.  If you have a suggestion add it to the

Codeplex

site.

Codeplex DISM site

Using HP Proliant Broadcom NICs in WinPE

We recently got in a new HP Proliant BL460c Gen8 blade with the HP 530FLB NIC. It’s a great piece of hardware but using the NIC in WinPE is not much fun.  We recently started using MDT to deploy Windows servers now but no matter what I did I could not get the NIC driver to load in WinPE.

Even though the drivers were imported into MDT and I had rebuilt my boot images it would not load.  Finally I ran HP’s driver installation utility from inside WinPE and it came up.  That’s when I discovered that the NIC needs the HP Virtual Bus Device driver loaded before it can load the NIC driver.  Looking at the PnP IDs that the driver supports I noticed they all start with b06bdrv\l2nd instead of the usual pci_<VenID>.  This is because the NIC virtual sits on top of another device. 

So why not just load the HP Virtual Bus Device in MDT?  That’s what I did but the HP Virtual Bus Device is a system-class driver and by default MDT does not copy system-class drivers into the boot images. 

Sure you can configure it to add them but then your boot images will get much larger.  My solution was to instead put a copy of the HP Virtual Bus Device (evbd.inf) driver into my MDT boot image using the “Extra directory to add” feature in MDT.  I also imported the NIC drivers into MDT as I normally do. 

Once the boot image loads press F8 to open a new command window. Navigate to the folder you added to the MDT boot image (it should be right off the root) and enter drvload evbd.inf. After a few seconds the driver will load and the NIC should now be active. It’s not an ideal solution but since we don’t deploy a lot of these servers it works for me.  This same process would also apply to some of the other Broadcom NICs used in HP blades and servers like the NC373i and NC382i. 

Setup MDT 2012 to use USMT 3

I recently upgraded our MDT 2010 Deployment share to 2012 and ran into an issue with USMT 3.  We still have some scenarios where we are deploying Windows XP so USMT 3 is required.  Whenever we ran a task sequence that needed the USMT 3 files we would get an error that the files could not be found.  I thought this was odd since the USMT 3 CAB file was in the correct location.  Or at least it was for 2010. 

In MDT 2010 you just had to leave the USMT30_x86.CAB file in the DeploymentShare\Tools\X86 folder and MDT took care of the rest.  With MDT 2012 you need to create a USMT3 folder in DeploymentShare\Tools\X86 and then unpack the CAB file into this folder.  It will not unpack the CAB file for you anymore.  Now MDT will be able to find the USMT files and continue.

Hopefully this helps out anyone else that has done an upgrade from 2010 to 2012.

USMT 3.0 and Office 2010

So you are still doing Windows XP to Windows XP migrations using MDT but you have deployed Office 2010.  You realize that USMT 3.0 doesn’t support Office 2010 and user’s settings are not getting carried over.  Sure USMT 4.0 supports Office 2010 but it doesn’t support Windows XP as a target.  What do you do now?

Well it turns out you can use the XML rules files from the USMT 4.0 update with USMT 3.0.  All you need to do is put them in the correct location in the MDT Deployment Share.  Just make sure that you place the MigApp.xml file in the DeploymentShare\Tools\x86 folder and USMT 3.0 will use the updated files.

I don’t know if this is supported by Microsoft but we have been using it for the past few weeks for some XP to XP migrations and it has worked out well for us.

Using MDT Queries to Assign Applications to Specific Hardware

I was asked by a commenter (here you go Alan!) on expanding on how I use a Make and Model query to automatically assign applications to a specific hardware models.  It’s a very easy and powerful feature of MDT and it makes installing those OEM supplied utilities a lot easier.

I’m going to assume that you already have your SSM packages created in your MDT Applications.  If not refer to my post on them here.

The first thing you need to do is configure the MDT Configuration Database.  There are many articles on the internet that already cover this (including the MDT Documentation) so I won’t rehash that information.  One I found particularly good was this one.  After you have configured that database and the rules make sure you update your WinPE boot images.  If you don’t they will not be able to take advantage of the make and model queries.

Now that your database is configured and you have configured your rules (all explained in the previous link) you can use MDT to dynamically assign applications based on model.  In the Deployment Workbench go to Advanced Configuration > Database > Make and Model.

Right click Make and Model and choose New.  On the first screen you need to define your Make and Model as is represented in WMI.  It’s important that the Make and Model fields exactly match the Name (Model) and Vendor (Make) attributes store in the WMI database.  For those that don’t know how to find this information you can use the WMIC tool to display it.  The below command returns the Make and Model information from WMI.  Note that Name = Model and Vendor = Make.

wmic csproduct get /value

After you enter in the Make and Model information click on the Applications tab.  Click Add and choose the SSM application that you want to assign to this model.  You can assign as many as you want.  Each application that you add to this make and model will be automatically assigned when you choose a deployment task sequence.

Boot from you WinPE image and choose your deployment task sequence.  When you get to the screen to choose your applications the ones you previously added to the Applications tab should already be checked.

This is a great way to deploy OEM specific applications in an automated process but you can also do this with any application in MDT.

Deploying A Customized Power Plan in Windows 7 with MDT

During our Windows 7 deployment we needed to deploy a customized power plan to our clients.  Windows provides an easy way to import and export power plans using the powercfg.exe utility.  With a little VB scripting automating the import of the plan through MDT is easy.

Here is the script I was using to import our customized plan and set it to active.

strPowerPlanFile = "c:\Folder\PowerPlan.pow"

Set objShell = CreateObject("WScript.Shell")

Set objWshScriptExec = objShell.exec("powercfg.exe -import " & strPowerPlanFile)

Set objStdOut = objWshScriptExec.stdOut

While Not objStdOut.AtEndOfStream

   strLine = objStdOut.ReadLine

   If InStr(strLine,"GUID:") Then

    strGuid = Right(strLine,36)     

   End If   

Wend

objShell.run "powercfg -setactive " & strGuid

Not much to it really.  First we run the powercfg.exe utility with the –import command line to import the file that contains the customized plan.  Each time you import a plan it gets a new GUID every time.  Powercfg outputs the GUID when the import completes.  We capture this line from the output, parse it, and then run the powercfg.exe utility again with the –setactive option to activate our new plan.

Now all you need to do is add a new step to your MDT TS to execute this script in the State Restore phase. 

DISM GUI 2.0

**Update** There is a new version of the DISM GUI that can be found in this post

Version 2.0 of my DISM GUI is ready for download.  I’ve made many changes to the interface and internal workings of this version.  Some highlights of the changes.

• You can now open the DISM.log file from the tools menu
• The DISM Command line that was run is also shown in the output window
• DISM now runs in the background thread and a progress bar is displayed while it runs.  This prevents the application from displaying a blank command prompt while it runs.
• Added the ability to inject drivers into a mounted WinPE WIM files. DISM GUI will read all INF files in the folder and inject them into the WIM.  I did not give the option to choose a single INF file.  Also the /recurse switch is always used.
• Added the ability to run Cleanup WIM and Get Mounted WIM information from the GUI.
• You can now display the WIM information in the output window before mounting a WIM.

These are just a few of the improvements.  Most of my work involves working with WinPE images so I focused on the features of DISM that support that.  If you have a suggestion or feedback leave a comment below or contact me through the About tab up top.

Setting Mandatory Applications by Task Sequence in MDT 2010

Hopefully this helps someone else out there and I’m not the only one that caught by this.

I recently had the need to set mandatory applications based on Task Sequences in our deployments.  Even though I had not done that before I expected it would not be that difficult and after some Googling Binging I found Chris Nacker’s article on this.

It looked pretty straightforward but one thing threw me off.  When you get to the screen to select your applications the applications you specify as mandatory will not be checked in the wizard screens.  This is because the CustomSettings.ini file is processed by the ZTIGather script before the wizard screens are displayed. Since your Task Sequence has not been chosen yet that variable is not set and the ZTIGather script does not process that section of the CustomSettings.ini.  Once you begin your Task Sequence the CustomSettings.ini file is processed again and the applications are made mandatory.

If you place your applications in a section of the CustomSettings.ini (such as Model or Default)  that gets processed before the wizard runs they will show as checked with no option to uncheck them. 

So just remember just because they aren’t checked doesn’t mean they won’t be made mandatory.

VMware Workstation network drivers for WinPE

I’ve recently begun using VMware Workstation to test image deployments with MDT 2010 and immediately ran into an issue with the default NIC that VMware Workstation 7 uses. 

When you create a new VM and use the XP profile it defaults to using an emulated AMD PCNet NIC.  If you choose a Windows Vista or 7 profile it defaults to using an emulated Intel e1000 NIC.  None of my MDT LiteTouch images included the AMD driver so I had to go searching for it.  I didn’t find the drivers on VMware’s site but I did find it on AMD’s site here.

Once you download the extract the drivers open up your Deployment Workbench.  Import them into your Out-of-Box drivers into the correct folder (You are using folders in MDT 2010 right?).

Don’t forget to rebuild your Deployment Share to regenerate your WinPE images.

Now just import the WinPE images into your PXE server or update your boot CD.  You can now boot your LiteTouch image on a VMware Workstation 7 VM.