Microsoft

System Center Configuration Manager Feedback

How can we improve Configuration Manager?

Integrate MDT by default

Instead of having us integrate MDT, why not just include the scripts in a new SCCM install by default?

250 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Glenn Turner shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Noted  · 

    12 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Thomas Bianco commented  ·   ·  Flag as inappropriate

        For many of my clients, i recommend against integrating MDT. it provides significant tools and capabilities, but at a complexity and administrative burden.

        As has been mentioned previously in this comment thread, we would be better served by recreating targeted features (such as the Gather variables or the UDI wizards) as native ConfigMgr task sequence steps. (gee i wish i could vote negative numbers)

      • David Stein commented  ·   ·  Flag as inappropriate

        I agree with Daniel and Adam, that integrating key features from MDT makes more sense than porting the entire product into ConfigMgr. In any case, it would be nice to drop one prerequisite off the crazy list that we have now.

      • Bob Panick commented  ·   ·  Flag as inappropriate

        We dumped MDT about 6 years ago because our customers couldn't support it when we left. The problem is MDT is too complex for most of them to follow it, particularly around the scripting. There are a lot of things in MDT that I've never seen anyone use either.

        Here's a dirty dark secret, most IT shops don't have anyone who can do scripting or SQL queries. The people with that aptitude generally became programmers. There are a few exceptions that you run into, most eventually move into consulting because it pays better.

      • Daniel Ratliff commented  ·   ·  Flag as inappropriate

        This was discussed in depth at MMS 2016, and what Adam Meltzer says below is correct. Admins don't want MDT integrated into SCCM, they want the features MDT provides. SLSHARE, Monitoring, TS variables such as IsVM, IsLaptop, etc.

      • deployboy commented  ·   ·  Flag as inappropriate

        Personally, I'd like to see it added as a "feature option" during the installer. The installer needs work as it is, but making MDT + WADK selected as options by default makes the most sense to me.

      • Will commented  ·   ·  Flag as inappropriate

        Native access to a build configuration database (MDT BCD) would be nice..

      • David Baur commented  ·   ·  Flag as inappropriate

        Half of ConfigMgr Admins use MDT, and Half don't. In 18 years I have maybe used it once, since I have been able to do everything asked of me using just native ConfigMgr OSD. My personal opinion is that is more complicated and has more failures due to how many pieces it incorporates.

      • Joe commented  ·   ·  Flag as inappropriate

        That is a really good point Adam. That would eliminate the need for the SCCM MDT integration.

      • AdminAdam Meltzer (ConfigMgr Product Team) (Admin, System Center Configuration Manager) commented  ·   ·  Flag as inappropriate

        I think the reason for this is the whole point of MDT is to be "OSD without Configuration Manager". With that said, there are some really neat features in MDT that aren't in Configuration Manager (deployment monitoring, the LiteTouch stuff, and so on).

        Maybe a better request here would be to have some more feature parity between MDT and Configuration Manager. In other words, at minimum Configuration Manager should have all of the functionality MDT has.

      • Leo D'Arcy commented  ·   ·  Flag as inappropriate

        I've seen the MDT integration break on several occasions requiring a simple reinstall of the integration pack, if this was integrated directly into SCCM my concern would be if the break happened a much more service affecting reinstall would be required. In theory I like the idea though

      Feedback and Knowledge Base