Microsoft Deployment Toolkit (MDT) 2008 – Why so many tools? Why not just one?
By Michael Pietroforte | 13 Comments | Permalink | Trackback | Previous | Next
I wonder how many different names this tool kit already had. Just some months ago, Microsoft renamed Business Desktop Deployment (BDD) 2007 into Microsoft Deployment 4. The name of the new version, which was released today, is Microsoft Deployment Toolkit (MDT) 2008. I guess many got confused by the former name because they thought it would be another deployment tool which is not the case. MDT is indeed just a tool kit, but one that is delivered without the tools. That means you have to download the tools you need for your work. The new version has quite a few new features.
Certainly most important is its support for Windows Vista SP1 and Windows Server 2008. There is also an update for BDD 2007 which allows you to deploy Vista SP1, but it doesn’t seem to support Windows Server 2008. The Microsoft Deployment Tool Kit Team blog (which was renamed as well) lists some more new features. The complete list of enhancements is much longer and can be found in the release notes which are on the download page of MDT 2008.
I only played a little with this tool kit, but every time I look at it I start to doubt again if it makes sense to work with it. Since you can use those deployment tools without MDT also, the question is if things get even more complicated if you have to use a tool to manage tools. Microsoft has neglected OS deployment for a long time, but now it seems to me that they are exaggerating it a little. There are so many different tools involved that it is hard to keep track of all of them.
The very idea of MDT certainly is to integrate all these utilities in one suite. However, I rather prefer just one tool which comes with all the necessary functionality regarding deployment. Yes, there is Configuration Manager, which is certainly a very powerful tool. But then why do I need MDT for it? Why didn’t they integrate everything needed in Configuration Manager in the first place?
You might say because Configuration Manager is only for bigger companies. Smaller organizations are supposed to use Windows Deployment Services (WDS) plus MDT. With this modular assembly concept, everyone can just put together a personal tool box. This concept comes from the Linux world and I must admit I never liked it. You are always busy keeping your toolbox update-to-date, and usually there are frictions between the different tools if the versions don’t fit together. Things might be more flexible this way, but it also make things more complicated than necessary.
So wouldn’t it be easier if Microsoft offered just one tool that comes with all the functionality for deploying operating systems and software? What is your view? Are you working with BDD 2007 or MDT? What are your experiences?
Update: I found some useful articles about the MDT:
- Upgrading to Microsoft Deployment Toolkit (MDT) 2008 – Zero Touch with ConfigMgr 2007
- Upgrading to Microsoft Deployment Toolkit (MDT) 2008 – Zero Touch with SMS 2003
- Upgrading to Microsoft Deployment Toolkit (MDT) 2008 – Lite Touch
- Microsoft Deployment Toolkit – Lite Touch Video Walkthrough
Leave a Comment | 
Subscribe RSS
| 
Newsletter
I was going to do the BDD MCP, now I don’t know if I should do it or not. Agreed, they need to pick a lane and we all know where the are and where they are going. And most importantly, what to call it!
I wasn’t aware that there is a MCP for BDD, but don’t let my article stop you to take this exam. Deployment is an important field and quite complicated. Many things changed with Vista and Server 2008. So I am sure that learning more about MDT will improve your career prospects.
I agree that they should provide one download that already has all the tools. They’re trying to make it so that you only add the tools you need but sometimes it’s better to just include everything. I would say wait until the next version of the MCP for BDD comes out that has the new terminology. Might be less confusing.
Aaron, the problem is not only that one has to download the tools separately. That wouldn’t be such a big deal. My point is that MDT can’t conceal the fact that they are still independent tools with different user interfaces, versioning, etc.
I said it about 2 years ago. Microsoft Deployment Team tries to tie all these different tools that used to be scripts and put pretty nice GUI to them now and then try to make it all look like an intergrated tool. No offense, but if M.Neuhaus is still part of this development team, that’s the problem. Highly technical and knowledgeable people, but they forget that the admins they are focusing on are not developer/admin mindsets. Work on a true tool, and not a set of adhoc thrown together tools/scripts. I can’t believe 2 years later this still exists in this fashion. Have they actually created a team for this also, instead of pulling developers here and there?
I somehow doubt they have a team for the MDT. That would mean that it would be a real product and they would probably sell it then. I rather prefer to pay something than using tool collection that was just slapped together.
Attitudes like these are big problem with the IT industry today. Nobody wants to put forth any effort into understanding or developing solutions. I applaud MS for creating MDT the way it is. Deployment/configuration is a complicated issue and I think the only real way to conquer it is to create an extensible/scriptable framework ala MDT. Keep your “true tools”, I’ll be over here using MDT to create and deploy more dynamic images and configurations.
John, deployment can be complicated, but it doesn’t have to be. What exactly are the advantages of dynamic images? Don’t you think it makes more sense to just create multiple images for different scenarios and forget about all this scripting?
Mike,
The solution you describe is exactly the kind of thing MDT can help you automate. Lets say you have multiple images for different scenarios in production. Lets also say you need to upgrade an application that is common to some or all of these images.
Here’s what I see as your choices:
A) Deploy all of your affected images to build machines, upgrade the app, re-sysprep and re-package.
B) Rebuild all of your affected images from scratch with the new application, sysprep, package.
C) Change the application in one place in MDT, have it rebuild all your images for you.
A is painful and results in a slightly dirtier image. B is REALLY painful, results in a clean image but there is more of a chance something has been forgotten or left out of the image. C gives you a clean, consistent image with only the changes you want.
Better yet, if you set up your MDT /app repository structure with change control and versioning built in, you can automatically create testing and production images with little more than dragging and dropping application packages in the right place. Maybe I’m not seeing the whole picture, but in the environment I’m in, this is pretty exciting stuff.
John, may I ask for which operating systems you mainly use MDT? And how many different images do you have? I am asking because my reply to your comment was about Vista. I am wondering under which conditions it might make sense to use MDT to rebuild images.
The problem with BDD is that it is only really for small organisations.
Anyone with multiple OUs, Core Applications, extra lock-downs are far better off scripting their own WINPE/HTA and associated UNATTEND.XML file with associated VBScripts with a good old-fashioned Network Share called VistaBuild or something like that.
XML processing is pretty simple in VBS and you would be suprised how easy it is to edit an XML file on the fly.
Another thing is the shoddiness of the documentation and the inability to provide coherent discussion of creating a standard Domain based SYSPREP Deployed Image.
Michael,
I’m using MDT for Vista/Server 2008 builds and deployments, with limited XP usage (refresh/upgrade and post deployment configuration). Right now we have one “thick” image that serves 80% of our users needs and customization post-deployment to serve the other 20%.
IMHO, it should almost always make sense to find an automated way to rebuild your images. Automation is the key to productivity. There are different methods/products to do this but I’ve found MDT to be the most compelling, feature/flexibility/support wise. Of course, if you make a very small number of changes, the time it takes to set up the automation may not make sense.
jools86,
I don’t see what a custom app that duplicates MDT’s functionality adds the table besides extra cost and time. MDT already provides you with a framework to do what you will. While it’s not perfect, (we’ve had to add a few custom VBScripts/HTAs to add functionality) it’s pretty close. At this point, writing a custom app to do this kind of stuff is reinventing the wheel.
As for the documentation, I have to agree with you there. There is a lot more that could be done in that area and I find myself gleaning more from the Deployment Guys blog than the official documentation.
The Deployment Workbench has an option to add OS images from a WDS server. However there is no option in the wizard to create a new WDS deployment point.
I want to use the Deployment Workbench to create OS images that will be deployed from multiple WDS servers using the PXE boot process.
It seems like support for this kind of functionality is a glaring omission in the Deployment Workbench.