Using Native MDT to build images - then deploy using SCCM

Question

Greetings,
  I recently watched a webcast from the MS deployment guys and they were insistent that images were built using native MDT, not SCCM. This requires a separate standalone WSUS which is not a real problem.
  For people who agree with this, I was interested in your experience of the advantages of doing this.
  These are some that have been stated here (http://bit.ly/QSHqt3):
"Using MDT 2013 Lite Touch is simply faster in most cases"
  I dont understand this one - why should it be faster?
"You can use the same image for every type
of OS deployment (VDI, SCVMM, MDT, ConfigMgr, WDS, and more)"
  Can't the WIM file generated by SCCM built images be used everywhere?
"You don’t need to worry about any challenges
related to running everything in the LocalSystem context"
  What does this mean exactly (examples please)?
"You don’t need to worry about the ConfigMgr
task sequence suppressing UI interaction"
  What do they mean here?
 And are software updates really that much of a pain with SCCM built images?
Lastly - do people always build images from scratch or do they feed the output wim back into the next build process and just add the changes required (like
software updates)?
Thanks
David Z

Answer 1

"Using MDT 2013 Lite Touch is simply faster in most cases"
  I dont understand this one - why should it be faster?
You can stand up an instance of MDT, import the necessary media, and produce an image more quickly than you can do the same in ConfigMgr.  Actual image creation time can vary due to a number of factors, but in my experience the actual time to run the
Task Sequence is often also shorter.
"You can use the same image for
every type of OS deployment (VDI, SCVMM, MDT, ConfigMgr, WDS, and more)"
  Can't the WIM file generated by SCCM built images be used everywhere?
Yes, it can...though bear in mind the image built with ConfigMgr does have the ConfigMgr client installed in the image where the MDT image does not.
"You don’t need to worry about any
challenges related to running everything in the LocalSystem context"
  What does this mean exactly (examples please)?
This is not as much of an issue as it used to be. When the MDT Task Sequence runs post-Windows Setup, it is running as the local Administrator account.  When ConfigMgr runs this portion, it's running in the Local System context.  This can be problematic
with some application installs that rely on certain user environment conditions, but the bigger reason was always the CopyProfile feature in the unattend.xml (and moreso with the UpdateServerProfileDirectory entry in the unattend.txt for WinXP). This took
whatever customizations were made under the local Administrator profile and copied them (mostly) into the Default User profile.  This made for an easy way to customize the Default User.  This is *not* currently considered a best practice by
any means, even though it is still an available option in the Win8.1 unattend.xml file (Specialize pass).
"You don’t need to worry about the
ConfigMgr task sequence suppressing UI interaction"
  What do they mean here?
ConfigMgr suppresses virtually any prompts, dialogs or notifications that are not generated by the Task Sequence engine itself, whether it's intended to be shown by design or generated by an error condition from an app or command line being run. 
For example, the default max run time for apps is generally 2 hours. If the application decides to throw up a notification window for some reason, it will not be visible and the Task Sequence engine will wait the full 2 hours before timing out and finally
failing.
And are software updates really that much of a pain with SCCM built images?
No, and in fact Software Updates are one of the biggest arguments against using MDT if you're already using ConfigMgr for Software Update deployment.  Because MDT doesn't have the ConfigMgr client, it can't recognize the availability of Software Updates
deployed in ConfigMgr, and it's really a bad idea to try and use the same instance of WSUS that ConfigMgr is using to deploy updates directly from WSUS.  So you end up having to maintain Software Updates in two places: ConfigMgr and standalone WSUS. 
Lastly - do people always build images from scratch or do they feed the output wim back into the next build process and just add the changes required
(like software updates)?
I recommend doing a clean build and capture every time, whether ConfigMgr or MDT.  If you have a solid Task Sequence developed and a consistent revisioning process in place, it's just a matter of firing up a VM and kicking off the TS, then importing
the captured WIM into ConfigMgr, distributing and testing.
Hope that answers your questions!