If you would like to be notified when Mitch Tulloch releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
If you would like to read the first part in this article series please go to Advanced Deployment: (Part 1) – MDT or SCCM .
Introduction
In the first article “Advanced Deployment (Part 1) – MDT or SCCM?” in this series, we considered the following questions concerning Windows deployment:
- When should you use only MDT (as opposed to using SCCM)?
- When should you NOT use MDT (and should therefore use SCCM instead)?
This present article will continue the discussion begun in the previous article and will provide a high-level overview of how to use SCCM together with MDT.
Why Use Both MDT and SCCM?
The four conclusions arrived at in the previous article were as follows:
- You should ALWAYS use MDT (not SCCM!) for building, capturing and testing your reference images.
- You should PROBABLY NOT use MDT ALONE if you have more than a couple of sites you need to deploy Windows to (that is, you should ALSO use SCCM in this scenario).
- You should ALSO use WDS if you have more than a few hundred computers to deploy Windows to (that is, you could use MDT and WDS together in this scenario).
- 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 (that is, you should use MDT, WDS and SCCM in this scenario).
What do you get if you use SCCM (i.e. ZTI) for deploying Windows instead of MDT (i.e. LTI)? This table on TechNet gives you a good summary for comparison purposes.
As you can see from inspecting the table, some of the key things that SCCM gives you right out of the box that MDT doesn’t provide without some additional features or tools being used are:
- Replication (MDT requires DFSR)
- Multicast deployment (MDT requires WDS)
- Bandwidth management of image transfer (not available with MDT but available with SCCM for pre-staging)
- Reporting on driver availability for devices across an organization (not available with MDT)
- Complex repartitioning and formatting of disks (requires custom diskpart scripting with MDT)
- Network connectivity assumptions (MDT requires well-connected network while SCCM tolerates poor/intermittent connections)
- Client OS initiated deployment and fully unattended option (not available with MDT)
- Push/pull model (MDT supports pull only while SCCM supports both push and pull deployments)
- Offline deployment from media (SCCM also supports CD/DVD spanning)
- Security (SCCM supports encryption and password protection)
But that doesn’t really answer the question of WHY you should use MDT and SCCM TOGETHER for your Windows deployments. The fact is, besides using MDT for building your reference images, integrating MDT together with SCCM provides a whole lot of benefits not present if you just use SCCM alone for deploying Windows across your organization. Someone who really knows about this is Michael Niehaus, the Senior Program Manager at Microsoft who oversees the development of MDT, who has compiled his own list of value-adds that MDT provides when integrated on top of SCCM. Michael posted this list Rod Trent’s site myITforum.com way back in 2009 but his points are still valid for the current releases (MDT 2010 and SCCM 2007) and he’s given me permission to reprint his email here:
My quick summary:
- Wizard to create all needed packages (USMT, scripts, client, OS, etc.) and task sequences from MDT templates.
- Wizard to create new boot images (adding optional components, fonts, fixes, etc.).
- Ability to dynamically determine user state location (local or network) based on estimate of USMT capture size.
- Ability to modify any unattend.xml/sysprep.inf/unattend.txt value using task sequence variable values.
- Task sequence templates that cover all scenarios from a single template: new computers, refreshes, replacements, with any OSes.
- Ability to back up the computer as a WIM during backup (local or network based on available disk space).
- Additional validation, prerequisite, and BIOS compatibility checks (e.g. don’t deploy Vista to a domain controller; make sure machines have more than 512MB RAM; etc.).
- Capture and restore local group memberships.
- Tattoo task sequence details into the registry and capture via ConfigMgr inventory for reporting purposes.
- Move state store to a safe location before the task sequence ends.
- Copy logs to a network location.
- Scripting framework to make it easier to add additional scripts into a task sequence (“toolkit package”).
- Action to install software updates offline for Vista and Server 2008.
- Action to install language packs offline or online for Vista and Server 2008.
- Action to install OS roles and features on Server 2003 and Server 2008.
- Action to configure ADDS (DCPROMO) on Server 2003 and Server 2008.
- Action to configure DHCP on Server 2003 and Server 2008.
- Action to configure DNS on Server 2003 and Server 2008.
- Unknown computer support for pre-ConfigMgr R2 installations.
- Gathering process to set various variables based on information about the machine, retrieved from WMI and other sources.
- Rules engine to set variables from databases, web services, etc.
- A database for configuring location, make/model, role, and computer-based settings.
- Stored procedure for reinstalling software packages that were installed in the old OS, based on ConfigMgr inventory details.
- Script to merge disconnected lists (ZTICoalesce) to solve some issues with using collection and computer variables.
- Script to enable all programs for dynamic installation via “install software” task sequence step.
My general comment to anyone who asks the question: Feel free to start without MDT, but before trying to customize your task sequences to do what you need, ask yourself if maybe MDT already does what you are looking to do. That’s really the value that MDT is trying to add: doing things for you that you didn’t initially know you needed.
And of course, perhaps the biggest value of all of using SCCM together with MDT is that not only can you easily deploy Windows across your organization with no user interaction needed but you can also manage your computers using SCCM once you’ve deployed Windows onto them.
Of course, the downside is that the initial setup and configuration of your SCCM infrastructure takes some time, planning and expertise (plus licensing costs). But once you’ve got this up-front investment finished, deploying and managing Windows-based computers is straightforward.
High-level roadmap for integrating MDT with SCCM
Assuming you’re using the latest versions of MDT 2010 and SCCM 2007 you would implement your deployment infrastructure by performing the following general steps:
- Prepare your Active Directory, DNS and DHCP infrastructures as needed and create the necessary service accounts.
- Configure Group Policy for pushing out the SCCM client to your target computers.
- Install and configure Windows Deployment Services on a server.
- Install and configure SQL Server 2008 on a server.
- Install SCCM 2007 on a server and create the Packages share and other necessary shares, then configure site boundaries, discovery method, client installation method, and perform any other tasks needed to configure your SCCM environment according to the needs and topology of your organization.
- Install MDT 2010 on your SCCM server and select Configure ConfigMgr Integration under Microsoft Deployment Toolkit from the Start menu, then use the ConfigMgr console to create client packages, boot images, and so on.
- Use MDT to build and customize your reference (master) images for Windows deployment and test your images before deploying them in production, then import them as operating system images into SCCM.
- Use the ConfigMgr console to add your reference image to the Packages share, create your deployment task sequence, assign distribution points, and create advertisements to target computers for deployment. SCCM will distribute your packages to your distribution points according to the site boundaries you’ve set up, and you’re ready to go.
At this point you should be able to install Windows on your target computers, get them joined to your domain, and get the SCCM client automatically installed on them so you can manage them afterwards. If you’ve also set up Windows Server Update Services (WSUS) in your environment then you can also get them fully patched from the start.
Rather than go into all these steps in detail, I’ll just refer you to the following books which every IT pro who does deployment should have on his or her bookshelf:
- Deployment Fundamentals, Vol. 1: Migrating to Windows 7 using MDT 2010 Lite Touch and WDS
- Deployment Fundamentals, Vol. 2: Deploying Physical and Virtual Servers Using MDT 2010 and SCVMM 2008 R2
Both of these books were written by two well-known experts in the field, Johan Arwidmark and Mikael Nystrom, and I highly recommend them. The first one deals with Lite-Touch Installation (LTI) using MDT 2010 and WDS while the second one adds SCCM 2007 R2 into the mix for performing Zero-Touch Installation (ZTI).
Things to watch out for
Finally, here are a few things you need to be aware of when integrating MDT with SCCM:
- If you have been using MDT alone and have decided to start using MDT with SCCM, you’ll need to re-create all your task sequences in SCCM. You can’t export a task sequence from MDT and use it in SCCM because there are too many differences between the products.
- MDT 2010 won’t support SCCM 2012 when it’s released, you’ll need to use MDT 2012 instead once that product is released. You will however be able to integrate MDT 2012 with SCCM 2007 if you want to, but any task sequences you create using this combination won’t include SCCM 2012-specific capabilities if you decide to use them later with SCCM 2012.
- Any SCCM 2007 task sequences you create with MDT 2010 will need to be re-created if you upgrade your environment to MDT 2012.
Conclusion
Investing in an SCCM infrastructure can make your Windows deployment easier especially for large organizations spanning multiple locations. And integrating MDT into SCCM to use them together provides the best of both worlds.
If you would like to be notified when Mitch Tulloch releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
If you would like to read the first part in this article series please go to Advanced Deployment (Part 1) – MDT or SCCM.
