MDT 2012 Update 1: Always applying images with ImageX

Another change you might notice in MDT 2012 Update 1 is that Lite Touch deployments never use SETUP.EXE.  That doesn’t result in any real change in functionality, as we still do the equivalent steps:

  • Applying the image using ImageX.exe.
  • Servicing the image using DISM, which injects drivers, software updates, language packs, etc.
  • Creating a BCD entry to boot the operating system using BCDBoot.exe.

So then the question becomes “why”.  Well, there are a few reasons:

  • Running Windows 7’s SETUP.EXE doesn’t quite work when using Windows PE 4.0 from the Windows 8 Assessment and Deployment Kit (ADK).
  • Some complex multiple disk scenarios (more common on servers) could result in errors during installation; similar errors don’t happen when using ImageX.
  • It’s no longer necessary to use SETUP.EXE.  With Windows Vista and its INSTALL.WIM, you couldn’t apply the WIM directly because the drive letter of the image (D:) was different from the drive letter of the machine (C:).
  • It’s a little faster Smile

So does that mean you never need to import full operating system files?  Not quite.  They are still needed in these situations:

  • When installing Windows XP or Windows Server 2003 from source files.
  • When installing Windows Vista or Window Server 2008 from the original source files (using INSTALL.WIM), because of the drive letter change issue described above.
  • When adding the .NET 3.5 feature to a Windows 8 or Windows Server 2012 installation (more on that in a later blog).

In MDT 2012, we used SETUP.EXE as the primary installation method, but would fall back to ImageX if SETUP.EXE wasn’t available.  Now with MDT 2012 Update 1, the default is to use ImageX.

p.s.  ConfigMgr 2012 SP1 will also prefer using image packages instead of install packages for the same basic reasons.

Comments (18)
  1. No, those changes are for Lite Touch only, not ConfigMgr.  The challenge with ConfigMgr 2012 is specifically with the SP1 beta.  We are still discussing that with the ConfigMgr team to see if that is something they can fix.

  2. In the case of Windows Vista, we will still use SETUP.EXE when we find it.  This is required when using the INSTALL.WIM directly, so always import the full source files with that.

    Otherwise, MDT will fall back to using ImageX even with Windows Vista, but this should only be attempted with custom WIMs.

  3. "Deprecated" doesn't mean unsupported.  You can continue to use ImageX with Windows 8.  MDT chose to do this just to avoid some additional testing from needing to support both DISM and ImageX in the MDT scripts.

    Future versions will likely use DISM only, as Windows AIK falls out of favor.

  4. Sorry, no, the $OEM$ logic is tied to using SETUP.EXE so it won't work when using ImageX to apply the image.  The workaround would be to add steps to the task sequence to XCOPY the content to the needed location.

  5. NeighborGeek says:

    Thanks for the response.  I did find a blog post from Johan yesterday that seems to address the issue.  By changing the OSDPreserveDriveLetter variable to True, the deployment now successfully assigns the drive letter C to the system disk.  Now the only question is what ELSE might that change affect?

  6. Julien Darakdjian says:

    Is the $oem$ fonctionnality is maintained with the imagex wim apply process ?

  7. >Is the $oem$ fonctionnality is maintained with the imagex wim apply process ?

    I've the same question.

  8. Sarah CJY says:

    Hi Michael,

    I tried the Windows 7 product CD with answer file and $oem$ folder, they all worked very well and the data in $oem$ folder were automatically copied to local HDD. (Tool: AIK; answer file and $oem$ folder were located in USB flash drive)

    Now, I try to use the Windows 8 system but I can't use $oem$ folder to copy what I want to local HDD anymore. (Tool: ADK; answer file and $oem$ folder were located in USB flash drive)

    Could you help to expain or clarify the phenomena? Thank you so much!

  9. YPae says:

    Can you explain more about "•When adding the .NET 3.5 feature to a Windows 8 or Windows Server 2012 installation (more on that in a later blog)"?


  10. Tony Dumas says:

    So if we still have to support Vista installations, should we stick to using a previous version of MDT (2010 Upd1) or should it still work normally under MDT 2012 Upd1?

  11. Todd says:

    So if we only have the ADK installed why does MDT 2012 still use imagex when it clearly states in the ADK docs that imagex is deprecated (even thought it's still there for some unknown reason)? This doesn't make things very clear.

    I've also noticed that DISM doesn't support a method of setting the "/FLAGS" of a captured image but MDT 2012 still uses this for capturing an image. This is very handy functionality too for captured images.

  12. julien says:

    Dear Michaels,

    thank you so much for the post, i have a questions, i have multiplie OEM $$ folder and i have created the step on the Task squence to copy the OEM folder to the windows, hoewver when it install, it doesn't copy the OEM file to the proper location,

    can you advise what i am doing wrong?

    thank you

  13. Derek Poon says:

    I cannot deploy Windows Server 2008 custom wim with MDT2012, as when the install OS sequence, Windows Vista's setup.exe is called and the task sequence then fails.

  14. Steve says:

    I've just built and captured a new 'base image' using MDT 2012 update 1 for deployment to our win7 workstations.  When I deploy this image from a test server running sccm 2012 sp1 beta, it assigns the system drive to D:.  

    Could this be a result of this change in mdt to not use the Windows 7 setup routine when building the base image?

  15. cosy says:

    Hi Michael,

     How do we  deploy Multi Partition ( C: & D) new image to current PC's, I mean deployment type is REFRESH?


  16. Jan Ruppert says:

    I need to apply a second .WIM file (it is present in the unattend.xml), but this does not work with imagex instead of setup.exe.

    So Q: How do I add a data.wim as second image during deployment.

Comments are closed.

Skip to main content