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:
So then the question becomes “why”. Well, there are a few reasons:
So does that mean you never need to import full operating system files? Not quite. They are still needed in these situations:
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.
Is the $oem$ fonctionnality is maintained with the imagex wim apply process ?
>Is the $oem$ fonctionnality is maintained with the imagex wim apply process ?
I've the same question.
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.
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!
See blogs.technet.com/.../copying-oem-files-and-folders-with-mdt-2012-update-1.aspx for more about the $OEM$ folders.
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)"?
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?
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.
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.
"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.
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?
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.
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?
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.
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?