If you would like to read the next part of this article series please go to Advanced Deployment (Part 2) – MDT and SCCM!.
Introduciton
In my editorial Best Practices for Deployment in the January 16, 2012 issue of WServerNews, I raised the question of using MDT vs. SCCM for deploying Windows and offered a few suggestions as follows:
If you’re a large shop with thousands of systems you need to deploy Windows onto, which tool or approach should you use for this:
- Zero Touch Installation (ZTI) using System Center Configuration Manager (SCCM) Operating System Deployment (OSD)?
- Lite Touch Installation (LTI) using Microsoft Deployment Toolkit (MDT)?
Use both. Use MDT for building your master images, then deploy these images ZTI using SCCM OSD integrated with MDT. There are several advantages of this approach:
- Integrating MDT with SCCM OSD makes deploying Windows easier.
- ZTI is more secure because there’s no auto admin logon on target systems the way there is with MDT LTI.
- ZTI is simpler for large environments–just build out your SCCM infrastructure and distribute your packages to your deployment points and if you’ve properly configured your boundaries the target systems can easily find the deployment points.
- And with SCCM you can not only deploy systems but also manage them afterwards!
- Plus you can use MDT LTI for special cases such as isolated systems that need to be installed from media, though you can also do this with SCCM OSD as this blog post explains.
In this present article I want to dig a bit deeper into the matter of using MDT and/or SCCM for Windows deployment.
Tip:
If you haven’t subscribed yet to WServerNews you should do so today!
When you SHOULD use MDT
First, you should ALWAYS use MDT for building and capturing the master images of Windows operating systems that you plan on deploying to computers in your environment. The main reason for this is that with MDT you can preconfigure the default user profile to customize the desktop of the user who will be using the computer you’re deploying Windows onto. That’s because with MDT you can configure user settings for the built-in Administrator account and then use the CopyProfile setting during deployment to make these the Default User settings on the target computer.
Why does CopyProfile work with MDT but not with SCCM? Because during Lite Touch Installation (LTI) MDT runs its task sequence in the context of the built-in Administrator account while SCCM runs its task sequence in the context of the LocalSystem account. Now you could actually make CopyProfile work with SCCM deployments if you wanted to, but it takes a lot of painful scripting to do this, so why bother if MDT already does it so easily?
There are some other reasons why you should use MDT and not SCCM for building and capturing your master images. For one thing, since SCCM is usually only deployed in a production environment, you don’t really want to mess around there by building and capturing images and deploying them to test machines in your production environment. You should do your image building/testing in a safe test environment, not production, and most organizations won’t want to go to the trouble of setting up a whole separate instance of SCCM just for testing purposes.
Finally, don’t forget that if you build your images using SCCM then those images will have the SCCM Client software incorporated into them, which may not be desirable in certain scenarios.
Conclusion #1
You should ALWAYS use MDT for building, capturing and testing your reference images.
Tip:
See my series of articles Customizing the Default User Profile in Windows 7 here on WindowsNetworking.com for a beginner’s guide on how to do this. Also see my article Desktop Image Management: Build a Better Desktop Image in Microsoft TechNet Magazine for some expert guidance in planning your reference images. Finally, see Setting up an image factory, part 1: Using MDT 2010 Lite Touch with SCVMM 2008 R2 on Michael Niehaus’ blog for a simple way to automate the process of building and capturing reference images.
When you SHOULD NOT use MDT
Not only can you build your reference images using MDT but you can even use MDT to perform all your Windows deployments in your production environment if you so desire. Why would you do this instead of setting up an SCCM infrastructure? Well, for one thing, MDT is free–you can download it here. And second, it’s easy to use–see my series of articles Deploying Windows 7 for a basic walkthrough of some different deployment scenarios.
So then, can you use MDT to deploy Windows to 100 computers in your company? Sure! What about 1000 computers? Uh-huh. OK what about 10,000 computers? Yes you can do that, or even to 100,000 or a million computers, but I’m not sure you’ll want to. Why not? Well, for two reasons. First, remember that MDT alone only supports Lite Touch Installation (LTI) which means some keystrokes will need to be perform on the target computers. If you want to perform Zero Touch Installation (ZTI) where no user input is required during the deployment, you must use SCCM instead of (or together with) MDT since MDT by itself doesn’t enable you to do ZTI deployments. So with MDT alone, the more computers you want to deploy Windows to, the more walking around pressing keys you’ll need to do. You can almost completely automate LTI but not quite, and the more you try to automate it the more work you will probably need to put into planning and setting up your deployment, for example by pre-populating the MDT database with the asset tags, MAC addresses and/or make/model of your target computers.
Second, if you really want to use MDT to deploy Windows to more than a few hundred computers, you’ll probably want to use MDT together with Windows Deployment Services (WDS), which enables client computers to boot from the network, download a Windows image, and install the image. In that case, all you would basically need to do is walk around to each target computer and turn it on to launch the deployment process. Well, it’s a bit more complicated than that for example if you have multiple subnets to deploy to, or multiple master images or multiple task sequences to choose from. But the basic idea is you take the LiteTouch.wim image file that you built using MDT and add it as a boot image using your WDS admin console. Then you PXE boot your target computers and once Windows PE loads onto them it connects to your MDT deployment share and installs the selected image using the selected task sequence. So all WDS is really being used for here is to PXE boot the target computers in order to kickstart the LTI deployment process. Microsoft calls this the Lite-Touch, High-Volume Deployment approach. Here’s a good video explaining how it works.
Finally, using MDT alone (even with WDS) poses the challenge of distributing the content MDT deployment shares across your organization. This is especially important to consider when your organization has multiple sites at different locations and you need to replicate your deployment share to each site (you generally don’t want to perform your deployments directly over the WAN because of possible bandwidth issues). The latest version MDT 2010 includes a new feature called Linked Deployment Points, so it has some built-in replication capabilities, plus it also supports DFS-R standalone roots. But this kind of scenario can be complicated to set up and maintain. Note also that a linked deployment share isn’t necessarily a full replica of your original or “parent” deployment share, and there’s no replication engine built into MDT for keeping your linked deployment shares synced with your parent share. Instead, you need to use a replication engine like DFS-R to handle the synchronization of the linked shares with the parent share, and if you look at the topic “Creating a Highly Scalable LTI Deployment Infrastructure” in the “Toolkit Samples Guide” section of the MDT help file you’ll find more information on how to set this up. As an alternative you could of course use PowerShell & a simple scheduled task from the parent share to kick off an update of a linked share on some desired frequency, but if your infrastructure supports it DFS-S is generally your preferred choice.
It’s much simpler however to just use SCCM in such multi-site scenarios since SCCM shines in the area of distributing content.
Conclusion #2
You should PROBABLY NOT use MDT ALONE if you have more than a couple of sites you need to deploy Windows to. And you should ALSO use WDS if you have more than a few hundred computers to deploy Windows to. And finally, while you COULD use MDT WITH WDS to deploy Windows to thousands or more computers, you PROBABLY want to consider using SCCM instead for such scenarios especially when your organization spans multiple geographical locations.
Coming Up Next
In my next article in this series, I’ll describe why if you DO decide to use SCCM for your Windows deployments, you SHOULD ALSO use MDT. I’ll also provide you with a high-level overview of how to use SCCM together with MDT.
If you would like to read the next part of this article series please go to Advanced Deployment (Part 2) – MDT and SCCM!.
