MDT doesn’t recognize your WIM file? Well, ImageX didn’t either.

  • Article

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