The Microsoft Deployment Toolkit (MDT) is a popular free collection of tools, processes, and guidance available from Microsoft that can be used to customize and automate Windows client and server deployments.
I recently talked with Michael Niehaus, Director of Product Marketing for the Windows Commercial team at Microsoft and the chief brains behind the creation and continuing development of MDT about his plans to rebuild MDT entirely from scratch using Windows PowerShell.
TechGenix: Michael thank you for taking some time out from your busy schedule to let us interview you for TechGenix.
MICHAEL NIEHAUS: Thanks for having me, always happy to talk about Windows deployment in any form.
TECHGENIX: I heard recently from Tim Mintner that you're spearheading the effort for rebuilding the Microsoft Deployment Toolkit (MDT) from the ground up using Windows PowerShell. Tim has also blogged about this. What's the reason or motivation behind this planned effort?
MICHAEL: When MDT was originally created (back when it was still called the Business Desktop Deployment Solution Accelerator), the "state of the art" technology for automating Windows tasks was VBScript, a little ActiveX, and lots of command line tools, all glued together into an end-to-end deployment process. But that was well over a decade ago -- technology has moved on. PowerShell is now the tool of choice, so it makes sense to use that for Windows deployment too.
TECHGENIX: MDT has included some PowerShell functionality for several years now. For instance, a while back Matt Hester demonstrated in this post on the Hey, Scripting Guy! blog on how you can use PowerShell and MDT to automate Windows deployment. And Andrew Barnes, who has contributed some guest editorials for our own WServerNews Weekly Newsletter, published a series of blog posts several years ago about using PowerShell in Task Sequences. What can rewriting MDT completely in PowerShell add in the way of usefulness for deployment geeks that beefing up the PowerShell support in the current MDT codebase could provide?
MICHAEL: Today, the PowerShell support is mostly a "bolt-on" to MDT (in some cases using VBScript to run the PowerShell scripts, which is kind of entertaining). Moving completely to PowerShell has a variety of benefits, including simplification overall, since PowerShell has much more functionality available via cmdlets. The part that I like the most though: Moving the MDT deployment wizard from Hypertext Applications (HTAs) to XAML. The existing MDT deployment wizard is the most complicated HTA I've ever encountered, and there aren't many people that truly understand how it works, much less how to tweak it. Moving to standard .NET capabilities with XAML opens it up to all the .NET developers that exist in an organization.
As far as the deployment geeks go, the hope is that once you have a solid PowerShell and XAML framework you can then start iterating, to add more functionality through volunteer open-source contributions. See an issue, fix an issue. Dream up a feature, add a feature.
TECHGENIX: OK, what's going to be involved in actually rewriting MDT from scratch in PowerShell? How will you be approaching this project? Will you start by developing the basic PowerShell modules? How much work do you think this is all going to be?
MICHAEL: Well, you have to start somewhere, and that somewhere needs to be useful enough to get people to try it. That's a significant amount of work though: Having a simple XAML wizard, functional task sequences, etc., just to show that yes indeed, this can be done in PowerShell. It took a few weeks to get to that point, and even then there are still significant chunks of missing functionality, so it's more like playing with "version 0.1" than "version 2017."
TECHGENIX: That sounds like a heck of a lot of work! Have you got any sort of timeline planned for when you think you might be finished this project? Not that MDT is ever going to be finished, it seems from its past history.
MICHAEL: This is most definitely an "in your spare time" project. We're talking about hundreds, if not thousands, of hours of effort before you reach (and then hopefully exceed) feature parity with what MDT can do today. So timelines are hard to measure -- "real jobs" get in the way.
TECHGENIX: Will there be a series of beta or interim releases for deployment pros to try out and test? How will these be released? I'm assuming that you're going to want the new MDT tested as much as possible in the wild since there are so many different possible deployment scenarios in the real world.
MICHAEL: Yes, definitely. The hope is that as significant changes are made, those can be validated (after all, people want something that works) and then packaged up for anyone to try. If any issues are found, those can be resolved in days (if not quicker). Contrast that to how MDT works today: Generally if an issue is reported, it can be reproduced and a fix is generally done quickly. But when people can get their hands on that fix is a different discussion -- MDT releases happen somewhat infrequently, maybe once per year.
As part of the development effort, we should be able to automate the testing of key scenarios to ensure some basic level of quality. But more extensive testing will require community help.
I would like to clarify one thing though: Don't think of this as "the new MDT." Think of this as an add-on to the existing MDT. This isn't about replacing the Deployment Workbench, it's about providing new task sequences and scripts to use within the existing framework. It's an extension, not a replacement.
TECHGENIX: Who's going to be working on this project to assist you?
MICHAEL: Anyone who wants to help. That's the fun part of open source projects hosted on GitHub. Anyone can create their own clone of the "PowerShell Deployment for MDT" (abbreviated as PSD) repository and submit pull requests with their changes.
TECHGENIX: When can we expect the first glimpse or build of the new MDT built from PowerShell?
MICHAEL: Well, you can try it today -- just be aware that it's not useful for much beyond a simple bare-metal deployment in a virtual machine. I need to find time (or helpers) to fix that.
TECHGENIX: Will the re-architected MDT still be able to do everything that the current version MDT 2013 Update 2 can do? For example, will it support all existing functionality and supported operating systems? Or will some legacy functionality and OS support be dropped in this next release?
MICHAEL: Again, think of it as an add-on to MDT (with the newest version being MDT build 8443, dropping the year from the name), so you get the same Deployment Workbench functionality, just different task sequences. Eventually it should support everything MDT does -- at least everything that people care about. There's certainly an opportunity to drop unused features, just as new features can be added. Eventually, the goal would be to get a prioritized list of things to work on, then just keep working on the shortening that list.
TECHGENIX: Will all our existing task sequences and OS images and other bits and pieces still work properly with the new version of MDT? Will we be able to simply port everything over from our deployment shares and keep on rolling?
MICHAEL: The goal is that you can continue to use your existing MDT installation and deployment shares, completely untouched, with the PowerShell Deployment pieces existing in a separate deployment share. It's not "rip and replace," it's all about coexistence.
TECHGENIX: Will we be able to upgrade our existing MDT version to the new one once it's released?
MICHAEL: In theory, yes. And that updated MDT installation will happily update the contents of a PSD deployment share -- with a whole bunch of scripts that aren't used by the PowerShell-based task sequences. So effectively, the PSD deployment share, scripts, and task sequences are designed to be completely independent of the equivalent VBScript scripts and task sequences.
TECHGENIX: How about integration with System Center Configuration Manager [SCCM]? Will we be able to use the new MDT version in SCCM Operating System Deployment [OSD] as with the current version of MDT?
MICHAEL: That's not presently high on the priority list. The first step is to get Lite Touch task sequences working. Integrating with ConfigMgr is something to look at in the future.
TECHGENIX: What else is new and exciting about the upcoming PowerShell-built version of MDT?
MICHAEL: At this point, nothing that you can see. But the best part from my perspective is that there have always been these "if we had an opportunity to do it again, we'd do it differently" discussions, so as the work going on, you'll start to see these sorts of things show up.
TECHGENIX: Michael thanks a ton for taking the time to allow us to understand where MDT is heading in the future. So many IT pros rely on MDT for imaging and deployment that it's good to hear the toolkit continues to evolve and be improved.
MICHAEL: MDT is in this for the long run -- having a simple, free tool to drive the Windows deployment process is key for us. We'll support and update the existing functionality, VBScript, HTAs, etc., to respond to changes in Windows. And we see things like PSD as new opportunities to build on the framework that MDT provides. Long live MDT!
Photo credit: FreeRange Stock