After MMS 2010, I had posted a series of blog postings talking about different mechanisms for managing drivers with ConfigMgr 2007.  You can read through that at http://blogs.technet.com/b/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx.

Then a hotfix was released that changed the way ConfigMgr 2007 handled duplicate drivers when importing.  I talked about that in the post at http://blogs.technet.com/b/mniehaus/archive/2010/10/15/configmgr-driver-management-a-new-development.aspx.  One point called out in that posting:  driver categories would be overwritten when a duplicate driver was imported specifying a different category.  That made the “Added Predictability” model described in the first posting very difficult to implement (without using something like the PowerShell script I posted in the first series).

Now, there is a new development:  Another hotfix that affects driver importing:

Category is incorrectly overwritten when you import the same driver on to a System Center Configuration Manager 2007 SP2 site server
http://support.microsoft.com/kb/2513499

From the title, you can probably guess what it fixes:  Now, when importing duplicate drivers, if you specify a different category, it will be added to the list of categories instead of overwriting the list that is already there.  As a result, the “Added Predictability” model is fairly simple to implement (without the need for scripting).  Look at this basic scenario:

• Download all the drivers for a Dell Latitude E6410 and import those, specifying a category of “Latitude E6410”.
• Download all the drivers for a Dell Latitude E6510 and import those, specifying a category of “Latitude E6510”.

Without the hotfix, all the common drivers would end up with a category of “Latitude E6510”.  With the hotfix, they would have both categories specified.

In my previous post titled Issue with MDT 2010 Update 1 and Windows AIK for Windows 7 SP1 Supplement, I mentioned some challenges if you wanted to use Windows PE 3.1 and still use Windows RE from a Windows 7 SP1 BOOT.WIM file.  One possibility proposed for dealing with this is to manually modify the Windows AIK version so that MDT knows a new version has been installed.  That sounds easy enough, renaming HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ComponentStudio\6.1.7600.16385 to instead be HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ComponentStudio\6.1.7601.17514.

I did try this out, and encountered two issues to note:

• Deployment Workbench doesn’t really like the change.  After changing this key, you’ll get warnings from Deployment Workbench saying that the version of WIMGAPI (6.1.7600.16386) is different than the version of Windows AIK (6.1.7601.17514).  There’s no workaround for this – you would just need to live with the annoyance of the warning, which will be displayed any time Deployment Workbench needs to use Windows AIK components.
• The Windows AIK team can’t support the change, primarily because it’s not something they have tested to see if there are any other unexpected side effects.

So while the workaround of editing the registry key may work, we can’t really recommend it.

For a longer-term solution, we have modified the Deployment Workbench code in MDT 2012 Beta 1 (see http://blogs.technet.com/b/msdeployment/archive/2011/06/01/microsoft-deployment-toolkit-2012-beta-1-now-available.aspx if you missed that announcement) so that it checks the version of the Windows AIK WINPE.WIM file, rather than checking the Windows AIK version in the registry.  As a result, MDT 2012’s behavior is:

• Windows PE 3.0 WINPE.WIM present in the Windows AIK folder and Windows 7 RTM or Server 2008 R2 RTM source files in the deployment share?  MDT will create a boot image from the Windows 7 RTM BOOT.WIM and it will include Windows RE.
• Windows PE 3.1 WINPE.WIM present in the Windows AIK folder and Windows 7 SP1 or Server 2008 R2 SP1 source files in the deployment share?  MDT will create a boot image from the Windows 7 SP1 BOOT.WIM and it will include Windows RE.
• Any other combination?  MDT will create a boot image from the Windows AIK WINPE.WIM file and it won’t contain Windows RE.

I’ve always been a fan of the thinnest image possible.  Taking that to an extreme, that means using the original image straight off the Microsoft media.  But over time if you did this you’d find that the time required to apply patches to that image becomes unmanageable.  (Case in point:  I started up a new laptop for the first time with an OEM-installed image that had hooks to require all patches be applied before first logon.  It took three hours for that to happen.)

I’ve also been a fan of doing “just in time” patching, which is something that MDT can do too:  Instead of patching the image in advance, you can inject updates offline after the image has been applied to the disk but before it boots for the first time.  That does often improve the time required, but it doesn’t eliminate it – it adds time when initially injecting the updates offline, and then more time on first boot as the “online actions” for those “offline patches” are completed (you’ll see the messages on the screen during the first boot showing a percentage complete while this is happening).

So reading between the lines, that means I would suggest always creating your own master image containing at least all the current service packs and patches.  (Don’t try to install the OS service pack yourself – just download “slipstreamed” media from the Microsoft licensing website, as that’s the ultimate time-saving technique.)  So how should you do this?  Well, there are a few ways:

• Mount the existing WIM image and just inject the updates offline with DISM.  This is certainly doable, but there are three challenges:
• The online actions for these updates will still take some time
• It introduces a “human touch” into the process, unless you go through the effort of automating this to make it a repeatable process.
• It only works for operating system updates.
• Build a new image and install all the updates into that image before sysprepping and capturing the image using a completely automated process.  This is my preferred approach, because it’s a consistent process for any other type of update being made to the image.

Not surprisingly, MDT 2010 Lite Touch provides a way to implement my preferred method above – and actually multiple methods that can be used.  Let’s go through those methods.

Install all updates from Microsoft Update directly

This is the easy way, as long as you have good internet bandwidth (all updates are downloaded from the internet) and a direct path to these downloads (as we don’t really support proxy servers in the MDT task sequence), and always want to install all critical updates.  (We skip language packs, drivers, and service packs by default, and you can exclude additional updates, but the exclusion process requires a little work.)

To use this method, all you need to do is search your task sequence for the following steps:

• Windows Update (Pre-Application Installation)
• Windows Update (Post-Application Installation)

Enable both of them, and then build a new image – that’s all there is to it.  (Why are there two steps you ask?  Well, the first might be required in order for the subsequent application installs to complete; the second might be required to patch the applications, e.g. Office, after it’s installed.  If the second step doesn’t need to install any additional patches, it won’t take very long.)

Install all updates approved on your WSUS server

To give you better control over patched put into your image, you may only want to install approved updates.  If you are using Windows Server Update Services (WSUS), then you already have such an approval mechanism in place, all you need to do is tell the task sequence to talk to WSUS instead of going to the internet.  This is pretty simple too:

• Enable the same “Windows Update” task sequence steps listed in the previous section (two of them).
• Add an entry into the [Default] section of CustomSettings.ini that says:
  WsusServer=http://SERVERNAME:PORT
  where “SERVERNAME” is the fully-qualified name of your WSUS server and “PORT” is the port number that WSUS was configured to use (only needed if that is something other than port 80).

Make sure that you have configured WSUS to install updates on unknown computers, because when building a reference computer it is indeed unknown to WSUS at the point the task sequence is executing.

Download all updates and import into your deployment share

This one is probably the most work, primarily because you need to manually download all the updates that you want to install, and it only works for OS updates (as they are the only ones that can be injected offline). The steps required:

• From the monthly security bulletin, or using a site such as http://catalog.update.microsoft.com, download all the updates which are typically packaged as MSU files.  (If they come down as executables, you’ll need to extract the MSU files from the executable.)
• Import the MSU files into Deployment Workbench from the “OS Packages” node.  (This will extract a CAB file that is contained in the MSU file, since that’s the piece that gets installed offline.)

When the task sequence runs, the “Apply Patches” will identify all the updates for the OS and platform being deployed, download them to the client, and update the unattend.xml to inject them.  (SETUP.EXE will later call DISM.EXE to do the actual injection after the image has been extracted and applied to the hard drive.)  If you want to apply a particular set of patches, you can configure a selection profile with one or more folders containing those updates, then configure the “Apply Patches” step to use that selection profile.

How often should I do this, and what should I do in between?

Well, that’s a completely different discussion.  Some people do a new image monthly (and probably don’t do much testing on that image each time they recreate it).  Some do it every few months.  Some do it once a year.  You just need to balance the efforts required to build it (easy), test it (not quite so easy), and distribute it (can be really painful) against the added time of applying some updates later.

You can actually use any (or all) of the above methods in that “later” deployment task sequence too:

• Enable the “Windows Update” steps in the deployment task sequence to download and install any updates released since the last image was created (from Microsoft Update or from WSUS if you set the WsusServer variable).
• Download and import any new MSU files into Workbench (but keep these separate from all the ones in the image as MDT won’t know which are installed and which aren’t so it will download all of them and let DISM figure it out).

For more information

Some additional links that might be useful:

Windows Update in MDT 2010 « Xtreme Deployment

Approving Windows Updates in an MDT 2010 Standalone Environment

This one goes back several years to when I was routinely writing code that used the ConfigMgr SDK (although in an odd coincidence, I was writing such code again yesterday).  It was pretty easy to run some buggy code that didn’t quite do what was intended, and as a result ConfigMgr might be left in an odd state.

One example of this: orphaned collections.  These exist in ConfigMgr, and if you look via WMI you can see them.  But they don’t exist in the console anywhere – they are invisible.  This would happen because those collections were not “rooted” to the top-level collection called “COLLROOT” (or any other collection, if you build collection hierarchies).

Other than “buggy code”, how else could these orphaned collections happen?  Good question, hard to say.

So how do you fix these?  Well, simple:  You “re-root” them by creating a new SMS_CollectToSubCollect WMI instance that says “this collection is a subcollection of COLLROOT”.  A long time ago, I wrote a script to do this.  After enough digging around, I found it again, so I’ll provide it here:

Set services = Getobject("winmgmts://YOURSERVER/root/sms/site_XXX")

' Just in case we need to re-root a collection, get the class instance
Set theClass = services.Get("SMS_CollectToSubCollect")

' Get a list of collections.  Make sure each one has a parent.  If not, connect it to COLLROOT.
Set collList = services.ExecQuery("select * from SMS_Collection where CollectionID <> 'COLLROOT' ")
For each c in collList

    ' WScript.Echo "Checking " & c.CollectionID

    ' See if this collection is already associated with the root collection.  If not, fix it.
    Set result = services.ExecQuery("select * from SMS_CollectToSubCollect where subCollectionID = """ & c.CollectionID & """")
    If result.Count = 0 Then
        WScript.Echo "No parent found for " & c.CollectionID

        Set theRelationship = theClass.SpawnInstance_()
        theRelationship.parentCollectionID = "COLLROOT"
        theRelationship.subCollectionID = c.CollectionID
        Set path = theRelationship.Put_
        Set path = Nothing
        Set theRelationship = Nothing

    WScript.Echo "Added " & c.CollectionID & " (" & c.Name & ") to the root collection"

    End If
    Set result = Nothing

Next

Paste this into a text file, change the server name (from “YOURSERVER”) and site code (from “XXX”), save it as “ReRoot.vbs”, and run it using “cscript.exe ReRoot.vbs”.  It will check every collection, and if it finds one that is orphaned, it will “re-root” it to to the root collection, telling you what collection (ID and name) was fixed.  After the script is finished, you can find the “re-rooted” collections in the admin console, and you can decide what to do with them from there.

With the release of the Windows AIK for Windows 7 SP1 supplement (see http://blogs.technet.com/b/mniehaus/archive/2011/02/17/windows-aik-for-windows-7-sp1-released.aspx for details), there is a new version 3.1 version of Windows PE available.  If you plan to install this update, you need to be aware of an issue when using this with MDT 2010 Update 1.

To explain the issue, first you need to understand the way the MDT boot image creation process works.  Fortunately, I explained that almost two years ago (http://blogs.technet.com/b/mniehaus/archive/2009/06/27/mdt-2010-new-feature-7-boot-image-creation-optimized.aspx):

With MDT 2010, Deployment Workbench will look for a “boot.wim” file from one of the imported operating systems that has the same build number as Windows AIK (e.g. “boot.wim” from a Windows 7 RC, build 7100, operating system to go with the Windows AIK for Windows 7 RC). If it finds a match, it will use that WIM instead. Why do we do this? Because the “boot.wim” contains the Windows Recovery Environment (Windows RE), a component that isn’t available in Windows AIK. 

That’s kind of high level, so let’s get a little more specific.  First, some background details:

• The build number for the RTM version of Windows 7 is 6.1.7600.16385.
• The build number for Windows AIK for Windows 7, released with Windows 7 RTM, is also 6.1.7600.16385.  This is stored in the registry.
• The build number for Windows 7 SP1 is 6.1.7601.17514.
• The build number for the files included in the Windows 7 AIK for Windows 7 SP1 supplement, including Windows PE 3.1 and all the Windows PE feature packs, is also 6.1.7601.17514.  But since this supplement is installed by replacing files in the Windows AIK installation directory using XCOPY, the registry isn’t updated so MDT still thinks the Windows 7 RTM version (6.1.7600.16385) of Windows AIK is installed.

Now, let’s assume that you have Windows 7 RTM x86 installation files present in your deployment share, and you haven’t installed the Windows 7 AIK for Windows 7 SP1 supplement.  MDT’s processing when creating a boot image will look like this:

• Is there a boot.wim available with the same version number as Windows AIK (6.1.7600.16385 = 6.1.7600.13685)?  Yes, copy it to a temporary folder and mount it.
• Inject the required Windows PE optional components from the Windows AIK installation directory into this mounted boot image.
• Inject the needed MDT scripts.
• Commit the changes to the WIM file and copy it to the deployment share.

Now, install the Windows 7 AIK for Windows 7 SP1 supplement and update the deployment share:

• Is there a boot.wim available with the same version number as Windows AIK (6.1.7600.16385 = 6.1.7600.13685)? Yes (because MDT doesn’t know that Windows AIK has been updated, the registry still says it is version 6.1.7600.16385), copy it to a temporary folder and mount it.
• Try to Inject the required Windows PE feature packs from the Windows AIK installation directory into this mounted boot image.  All fail, because they are for Windows PE 3.1 and won’t work with the Windows PE 3.0 boot image copied from the Windows 7 RTM files.
• Stop.

The actual error will look something like this (repeated for each Windows PE feature pack):

Deployment Image Servicing and Management tool
Version: 6.1.7600.16385
Image Version: 6.1.7600.16385
Processing 1 of 1 - Adding package WinPE-HTA-Package~31bf3856ad364e35~x86~~6.1.7601.17514
Error: 0x800f081e
The specified package is not applicable to this image.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
Exit code = –2146498530
DISM /Add-Package failed for component C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-hta.cab, rc = -2146498530.

Uh oh – you can’t get past this error to generate boot images.  So what should you do?  There are two options:

• Reinstall Windows AIK for Windows 7 RTM (version 6.1.7600.16385) so that the Windows PE 3.0 feature packs are again used.
• Modify the Settings.xml file in the deployment share’s “Control” folder to tell MDT to never use the boot.wim.  The settings look like this:
  
  <Boot.x86.UseBootWim>True</Boot.x86.UseBootWim>
  <Boot.x64.UseBootWim>True</Boot.x64.UseBootWim>
  
  They should be changed to instead say:
  
  <Boot.x86.UseBootWim>False</Boot.x86.UseBootWim>
  <Boot.x64.UseBootWim>False</Boot.x64.UseBootWim>
  
  As a result of this change, MDT will no longer use the boot.wim from the Windows 7 RTM installation files.  Instead, it will always use the winpe.wim from Windows AIK.  And since the Windows PE feature packs in Windows AIK should always match the winpe.wim in Windows AIK, this will always work.

There is one downside to the second option, which goes back to why MDT attempts to use the boot.wim in the first place:  The winpe.wim doesn’t contain Windows RE.  Since there’s no way to add Windows RE to a Windows PE image built from the Windows AIK winpe.wim, that means the resulting Lite Touch boot WIM won’t have Windows RE.  If you aren’t using Windows RE, that doesn’t matter.

Let’s look at some other scenarios too to see what will happen:

• You have installed the Windows AIK for Windows 7 SP1 supplement, added Windows 7 SP1 source files to your deployment share, and removed the Windows 7 RTM source files from your deployment share.
  • In this case, MDT won’t find a boot.wim whose version matches the registry version for Windows AIK (6.1.7600.16385).  So everything will work, using winpe.wim and feature packs from the Windows AIK supplement.
• You have generated Lite Touch boot images in the past without issue.  Now you install the Windows AIK for Windows 7 SP1 supplement, but you don’t see any issues – you can still update your boot images.
  • This is because MDT sees that all the needed Windows PE feature packs are already present in the Lite Touch boot images on the deployment share.  It’s a temporary success though:  The next time MDT completely regenerates the boot images (which happens when MDT is upgraded or when you check the box in the “Update Deployment Share” boot image), the process will fail.
• You have installed the Windows AIK for Windows 7 SP1 supplement.  You have Windows Server 2008 R2 RTM installation files in your deployment share, but no Windows 7 installation files.
  • This will result in the same error as above.  The boot image generation process will try to use the boot.wim from Windows Server 2008 R2, just like it tries to use one from Windows 7 RTM.
• You have installed the Windows AIK for Windows 7 SP1 supplement.  You have Windows Server 2008 R2 SP1 installation files in your deployment, but no Windows Server 2008 R2 RTM installation files.
  • This is just like the Windows 7 SP1 scenario above:  the update process will work fine, using the Windows AIK SP1 Windows PE 3.1 WIM and corresponding feature packs.

Note that this will never be an issue with MDT-generated boot images used with ConfigMgr 2007, as MDT will always use the winpe.wim from Windows AIK when generating these.  (ConfigMgr 2007 doesn’t yet support Windows PE 3.1, so don’t install the Windows AIK for Windows 7 SP1 supplement yet if you are using ConfigMgr.)

If there are any additional questions about this, let me know (mniehaus@microsoft.com).

If you are a Microsoft partner in the US interested in helping customers deploy the latest version of Windows Server, you might be interested in the new Windows Server Platform Modernization program.  But reply quickly, spots are limited and first-come, first-serve.  The full details:

The Windows Server Platform Modernization program offers free, instructor-led technical training, tools, readiness and sales resources, and technical support so you can help customers move to Windows Server 2008 R2, virtualization, and cloud-based solutions.  This invitation-only program is open to all US-based Gold, Silver and Subscription Design and Development Partners; space is limited to 50 partners.  If you’re interested in joining, contact ServerModernization@microsoft.com.

The WSPM program supports Partners throughout a Windows Server sales and development cycle, from pre-sales, through deployment, to management of a Windows Server 2008 R2 migration.  The program also offering the same free training, tools, and support for virtualization and private cloud engagements.  If you’re interested in learning more about this program, send an email to the program manager at ServerModernization@microsoft.com for more information. 

I’ll be in Texas this week for two user group meetings, first in Houston (HASMUG) and then in Austin (CTSMUG):

HASMUG Presents a MMS Sneak Peek - March 10, 2011
http://events.r20.constantcontact.com/register/event?llr=7dkvxteab&oeidk=a07e3e2p2g807a5c714
I have 60 minutes to talk about MDT v.Next, giving you a preview of what I’ll be discussing at MMS 2011.

CTSMUG – March 11, 2011
http://myitforum.com/cs2/blogs/ctsmug/archive/2011/02/22/central-texas-user-group-meeting-11-march-2011.aspx
Here I have two hours to talk about MDT v.Next and related projects.

It’s not too late to register, hope to see you there.

If you aren’t able to make it to either of those, then I hope to see you at MMS where I will have four sessions (with a Birds-of-a-Feather session likely to be added still):

BC07 What’s New and What’s Coming from the Microsoft Deployment Toolkit
Speaker(s): Jeremy Chapman, Keith Garner, Michael Niehaus, Mike Lewis

Although MDT 2010 Update 1 shipped last summer, our developers have not been resting. Last Nov we released an MDT add-in to convert the starting computer into a virtual machine as part of an automated deployment called “P2V Migration for Software Assurance.” We are working on up-leveling the story to manage end-to-end desktop migration projects with something currently called “Deployment Manager.” This demo and architecture-packed session is presented by the solution architects and developers.

BE01 Troubleshooting Windows 7 Deployments: In Depth
Speaker(s): Michael Niehaus

In this session, we will explore a set of common issues encountered during the Windows 7 deployment process, digging as deeply as possible into the root causes and understanding how to troubleshoot similar issues.

BE31 MDT 2010 Update 1 Integration with ConfigMgr: Quick Start
Speaker(s): Chris Nackers, Michael Niehaus

This session will cover the setup and configuration of MDT 2010 Update 1 with ConfigMgr.  We'll cover the installation, creation of your first MDT integrated Task Sequence and creation of your first MDT boot image.  We'll also cover the necessary changes to successfully deploy Windows 7 and how to modify your boot images to add extra files.  This session will also compare a MDT integrated Task Sequence to a default ConfigMgr Task Sequence and explain the differences and why you need all those Task Sequence steps.

BC06 Windows Deployment Live Game Show
Speaker(s): Chris Jackson, Jeremy Chapman, Johan Arwidmark, Keith Garner, Michael Niehaus

MMS can be a long week of technical sessions. This year we're looking to shake things up with a 400-level game show session with deployment experts from Microsoft and leading deployment partners. All questions will be new and submitted without the knowledge of the contestants in the low-to-high 400-level range, and put to our panel of deployment experts.

Take a break from textbook technical content and experience fun technical content - join us to be a member of our live studio audience - and maybe enjoy a beer to celebrate the end of the show!

Some of you probably noticed a new download showed up today:

The Windows® Automated Installation Kit (AIK) for Windows® 7 SP1
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0aee2b4b-494b-4adc-b174-33bc62f02c5d

Be sure to read the “readme” that goes along with this at:

Windows Automated Installation Kit for Windows 7 Readme
http://technet.microsoft.com/en-us/library/dd349350(WS.10).aspx

A quick Q&A that I assembled from information in this readme and our own MDT testing:

Q:  Do I have to use this to deploy Windows 7 SP1 and Windows Server 2008 SP1?

This supplement is optional. If you do not need to modify the SP1 boot.wim and winre.wim files, you can continue to use the Windows 7 RTM tools, including WinPE 3.0, without installing this supplement.  (So MDT and ConfigMgr can deploy WIndows 7 SP1 just fine using Windows PE 3.0.)

Q:  How do I install this on a machine currently running the Windows 7 RTM version of Window AIK?

There’s no installer provided with this.  You need to extract the contents of the download and then XCOPY the files over the top of your existing Windows AIK installation.  See the details in the readme.

Q:  What’s changed in this Windows AIK supplement?

• The number in the Version registry value is 3.1 to reflect the new Windows PE version.
• The Windows PE 3.1 base image contains Remote Network Driver Interface Specification (RNDIS) binaries. These binaries are also available for Windows PE 3.0 as a hotfix. For more information, see Knowledge Base Article ID: 979265 (http://go.microsoft.com/fwlink/?LinkId=206678).
• Windows PE 3.1 includes 802.1x binaries as an optional component. The file name of this package is WinPE-Dot3Svc.cab. This optional component is also available for Windows PE 3.0 as a hotfix. For more information, see Knowledge Base Article ID 972831(http://go.microsoft.com/fwlink/?LinkId=206072).
• The Windows PE 3.1 base image contains fixes that are related to 4k/512e drive support. These fixes are also available for Windows PE 3.0 as a hotfix. For more information, see Knowledge Base Article ID: 982018 (http://go.microsoft.com/fwlink/?LinkId=206679).
• Windows PE 3.1 includes bug fixes that are related to the Windows PE version that is included with Windows 7 SP1.

Q:  Does Windows 7 SP1 and Windows PE 3.1 work with MDT 2010 Update 1?

Yes, this is fully supported.  (There is one small issue involving Windows 7 SP1, Windows PE 3.1, and having Windows RE included in your MDT-generated Lite Touch boot images, but if you don’t mind Windows RE not being there, you don’t need to worry about this.)

Q:  Does Configuration Manager 2007 SP2 support Windows 7 SP1 and Windows PE 3.1?

The Configuration Manager team is still testing Windows 7 SP1 and Windows PE 3.1, so this is unsupported until that testing is completed.

Q:  Does this supplement include the recently-released USMT 4 update for Office 2010 support?

No, you need to download and apply that one (http://blogs.technet.com/b/mniehaus/archive/2011/02/02/usmt-4-0-support-for-office-2010.aspx) separately.

A new hotfix for USMT 4.0 was released today to support migrating Office 2010 settings.  (It includes other fixes too.)  You may want to download this and integrate it into your deployment processes.  The full instructions for doing this (including what needs to be done with MDT and ConfigMgr) are included in the KB:

http://support.microsoft.com/kb/2023591

There is one complication that you should be aware of if you are using ConfigMgr and moving from Windows XP or deploying Windows XP.  USMT 4.0 uses a set of manifest files to determine what needs to be migrated from Windows XP.  These manifest files are stored in the “DLManifests” folder, which is part of your USMT package in ConfigMgr.  There is an issue though where Scanstate.exe can’t find this DLManifests folder when run from ConfigMgr.  In MDT 2010 Update 1, we included a workaround for this with some logic in ZTIUserState.wsf, copying the folder where Scanstate can find it:

' Workaround for USMT bug in Windows 7 AIK
If oEnvironment.Item("DeploymentMethod") = "SCCM" and oEnvironment.Item("OSVersion") = "XP" and oFSO.GetFileVersion(sFoundScanState) = "6.1.7600.16385" then
    oUtility.RunWithHeartbeat "cmd.exe /c xcopy /iesryhd """ & sUSMTPath &"\DlManifests"" """ & oEnv("SystemRoot") & "\system32\DlManifests" &""" 1>> " & oLogging.LogPath &"\zticopyUSMT.txt 2>>&1 "
End if

Notice that this checks specifically for build 6.1.7600.16385 of Scanstate.exe, the version released in the Windows 7 version of Windows AIK, as we expected this problem to be fixed in the next version of USMT.  Well, it wasn’t.  But once you install the KB 2023591 hotfix, the version changes to 6.1.7601.21645 and our fix stops working.

You can work around this by fixing the fix in ZTIUserState.wsf to read like this:

If oEnvironment.Item("DeploymentMethod") = "SCCM" and oEnvironment.Item("OSVersion") = "XP" and (oFSO.GetFileVersion(sFoundScanState) = "6.1.7600.16385" or oFSO.GetFileVersion(sFoundScanState) = "6.1.7601.21645")  then

If you aren’t using ConfigMgr or don’t have Windows XP around any more, you won’t need to worry about this.

I’ve talked to a few people that have mentioned that when they import a new operating system into the MDT 2010 Deployment Workbench, it never shows up – it’s in the deployment share, but it never shows up in Workbench.  So what happened?

Well, if you are the geeky type, you can watch the import process using the Sysinternals DebugView tool and see any errors (exceptions) that occur during the import process.  In this particular case, you’re likely to see an error that says there is no “Build” parameter in the WIM metadata.  So what does that mean?  First, let’s look at the metadata from a “typical” OS image (generated using “ImageX /info /xml FILENAME.WIM”):

<WINDOWS>
  <ARCH>0</ARCH>
  <PRODUCTNAME>Microsoft® Windows® Operating System</PRODUCTNAME>
  <HAL>acpiapic_up</HAL>
  <PRODUCTTYPE>WinNT</PRODUCTTYPE>
  <PRODUCTSUITE></PRODUCTSUITE>
  <LANGUAGES>
    <LANGUAGE>en-US</LANGUAGE>
    <DEFAULT>en-US</DEFAULT>
  </LANGUAGES>
  <VERSION>
    <MAJOR>5</MAJOR>
    <MINOR>1</MINOR>
    <BUILD>2600</BUILD>
    <SPBUILD>5512</SPBUILD>
    <SPLEVEL>2</SPLEVEL>
  </VERSION>
  <SYSTEMROOT>WINDOWS</SYSTEMROOT>
</WINDOWS>

You can tell from looking at this that this WIM image contains a Windows XP (version 5.1) operating system that’s installed in the WINDOWS folder.  It’s an x86 image (architecture 0), and it’s English.  Great, that’s all the information that MDT needs.

Now, compare that with a problematic WIM:  It won’t have that <WINDOWS> node at all – it’s missing from the output altogether.  So how does it get there in the first place?  That’s the job of the WIMGAPI.DLL library:  When capturing the OS, it looks at the OS files to determine what kind of OS it is.  (It can’t ask the OS, as the OS isn’t running at that point – you normally run ImageX while in Windows PE.)

There are a few locations that WIMGAPI will look to find a Windows installation:

\WINDOWS
\WINNT
\I386
\AMD64

It will check each of those folders looking for a few key files (e.g. NTOSKRNL.DLL) and get the information it needs from those files directly.  But what if those folders don’t exist?  That could happen if you have installed Windows XP into a different folder.  In that case, it won’t find the files and therefore will assume that this is just a data WIM, not an OS WIM, and you’ll get no <WINDOWS> metadata.  That’s the problem that MDT is running into.

So what’s the lesson learned here?  Don’t install Windows XP into anything but WINDOWS or WINNT.  (The I386 and AMD64 checks aren’t really for full OSes.)  Once you move past Windows XP, you don’t get a choice any more – you must use WINDOWS.  So make that change now.  (Remember that the App Compat Toolkit can fix applications that have hard-coded paths in them, e.g. “C:\WINNT”, so you don’t need to make code changes for path issues like this.)