Partager via

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

Comments

  • Anonymous
    January 01, 2003
    Update:  ntoskrnl.exe was the only file it needed to recognize the .wim as an OS.

  • Anonymous
    November 30, 2010
    Instead of looking for key OS files in a hard-coded list of directory names, why doesn't WIMGAPI.DLL check for <ActiveDrive>boot.ini or <ActiveDrive>bootbcd, and get the SystemRoot and other data from there?

  • Anonymous
    December 03, 2010
    SI FUESE INFORMATICA YA NO LES NECESITARIA

  • Anonymous
    May 16, 2012
    I was able to "trick" it to recognize the .wim as an OS even though my systemroot is WIN2K03.  I just created a Windowssystem32 folder in the .wim, containing the ntoskrnl.exe and the two other files that had the same date, win32k.sys, and ntkrnlpa.exe.