Home 

MDT2012 and Cross Architecture deployments / Importing images with setup files

This post will explain a limitation of cross-architecture deployments of Windows 7 using MDT2012 along with a work-around.

After receiving an email from someone who was having issues deploying a Norwegian version of Windows 7 64-Bit using the LiteTouchPE 32-Bit environment (and had no problems at all when deploying it using LiteTouchPE 64-Bit) I quickly came to the conclusion that the actual setup.exe process that was executed when running in LT-PE x86 was from a set of source files that was from a different language. This is an error that I’ve seen often enough back in MDT2010 where you’d import a new custom .wim image to the deployment share without the setup source files and the image being deployed is actually a different language from those that are already present in the deploymentshare.

Windows Setup Error

This was also one of those topics that came by on the technet forums rather often, and the simple solution was by re-importing the custom image with the setup files (in the appropriate language). However, cross-architecture deployment was not possible back with MDT2010, but now that it is, this very same subject resurfaces again due to the built-in logic of finding setup.exe.

So why does this happen? It’s simple when deploying Windows Vista/7/Server 2008/R2 this will be handled by running setup.exe along with an unattend file, but with a cross-architecture deployment (note: can only deploy x64 from x86, but cannot deploy x86 from x64 PE environments and only works for Windows 7/Server 2008R2) the 64-bit setup files are not able to be executed from a 32-bit PE environment. MDT will look in this scenario for an alternate setup anywhere in the other Operating Systems that have been imported into MDT that did include 32-Bit setup files (note: importing a x64 .wim file and providing 32-bit setup files will still report to MDT as a x64 platform).

At first when I saw this, I thought of a couple of solutions. However, after some more research I’ve came across a post regarding issues deploying Windows 7 with MDT2012 in combination with ADK (this replaces the WAIK/OPK for Windows 8). The following quote is a post of Michael Niehaus [link] (scroll down near to the bottom).

As mentioned before, this is an incompatibility between the beta ADK and Window 7 Setup.exe. This won’t be fixed in ADK or in Windows 7 Setup.exe, so in a future MDT release we will stop using Setup.exe to install Windows, which will avoid the issue.

This issue is also documented in the MDT 2012 release notes. We still suggest using Windows AIK for Windows 7 deployments, unless you are in a lab environment and are willing to put up with small issues like this.

Note that if you import your Windows 7 and Windows Server 2008 R2 images into Workbench without the full source files (just import the Install.wim), then you won’t see this popup when using ADK because MDT 2012 will automatically fall back to using ImageX to install the image instead of Setup.exe. (The change we are making in our next release is to make ImageX the default.)

Now seeing the statement regarding that the default behavior for Windows 7 and Server 2008R2 installations will be handled by ImageX instead of setup.exe, I would personally just suggest to already start planning towards this new change. There’s no drawback for using ImageX.exe vs Setup.exe since offline servicing will still be done after the image has been applied onto the disk (this adds the drivers, LP, patches and such).

I’ve already updated my deployment share that I use for development/testing to reflect this new change, I’ve re-imported all images as plain install.wim files so the entire deployment share does not include any setup files for Windows 7/2008R2 (this can be done for Vista/2008 as well if you wanted to, these do not support cross architecture deployment though). This change also gave me back about 300MB per imported Operating System in my workbench this can add up quickly if you’ve imported a lot of OS’s into the workbench. Note: I don’t even use the ADK yet for this particular share, I still use WAIK to be honest, I prefer this method over running setup, since you gain a time indicator that will tell you how long it’ll take before the image is applied onto the machine, but more importantly the install time is decreased significantly (image being applied within 5 minutes in my lab environment). This is also the method that ConfigMgr 2007 and 2012 apply custom wim images to clients, they dont use setup.exe for that either.

Kind regards,

Stephan Schwarz