I wanted to write this article in order to establish the differences with two Microsoft deployment technologies, System Center Configuration Manager 2012 (SCCM) and Microsoft Deployment Toolkit (MDT), and provide scenarios of what they can do and cannot do and the benefits and drawbacks of each
Organisations always don’t tend to have the same type of requirements where that comes to migration, upgrades, and infrastructure-type additions. And also understanding the requirements of the business is one thing, but having a more in-depth scenario-based understanding of what each can do in different bespoke situations can make all the difference
So we have two Microsoft products, SCCM 2012 & MDT. One of the common denominators of these is the Windows Deployment Services (WDS) role, which lets you use image files (standard is .wim) to build bare metal machines and also provides devices with ways to connect to the server over the network being Pre-Execution environment (PXE) and a discover image, which can connect clients that cannot PXE boot to the server.
Without going into a great deal of WDS—though it’s tempting J—it provides a great capability to build machines. However, in the long run, many situations challenge how WDS would fit into your plan of a default mechanism for OS deployment.
For example, WDS isn’t a process you would use for a migration to a different OS. Though it can do this, the process isn’t seamless and leaves you to perform all of the work to make this happen
You do have the option of answer files which can control and structure how the OS will be configured after the out of box environment (OOBE) and pre-stage its boot selection, which is a great way of aiming towards the “ZTI” approach, but you’ll find with WDS as with a few technologies it does take a good amount of administrative effort, which you may or may not be motivated to do on a regular basis, and with the more advanced outer shells such as MDT or SCCM, the idea is to work smarter and not harder
We are all familiar with how SCCM works in its approach to deployment, but I think its strengths apply more around the lifecycle of how it performs, controls and maintains the deployment
For example, the security focus is great, as you can use a password to “lock” the deployment to only administrators who would know of the password. This would stop machines from being rebuilt in error.
You can control pre-staging machines outside of WDS and perform Task Sequence deployments to collections of specific machines, as well as all unknown machines that the SCCM infrastructure does not recognize.
The various monitors and logs help you pinpoint where a deployment would have failed and the scheduling of its availability.
These are a few of many points as to why SCCM is a fan favourite of deployment—not only the features of OS deployment but the lifecycle of it and the security pre-staged focus behind it.
I feel the only little drawback is that in smaller environments, a component such as SCCM could be perhaps too much to configure. I believe the minimum amount of devices would be at least 500, but since there is a lot of room for customization and advancements that you can make, the administrative effort can also hugely increase. With a smaller environment that could impact speed as well as quality of service thus making troubleshooting scenarios more of a nightmare. It just doesn’t seem to work as well if you are only using the fundamental basics of its deployment features, and you tend to get the best out of SCCM when there is a design involved into how it will fit the business.
This is a free tool for OS deployment. But I feel sometimes we can underestimate what a free tool can actually do compared to a powerhouse such as SCCM.
Similarities in comparison to SCCM are that they both initiate deployment via task sequences, which contain OS and application deployment, as well as the ability to capture customized wim images for standardised building. But what I really want to do is drill more into the Zero Touch Interface (ZTI) side of things.
ZTI implies automated deployment that would require no touch. This is something MDT can do extremely well, with its slight steps of administrative effort.
And with me knowing how powerful SCCM is, what if we could make MDT into the same powerhouse? I actually have been able to do so in a few situations and will go more into its setup with comments to show you how it will all fit together later.
Now compared to SCCM, MDT’s lifecycle and security focus are not as heavy. Although it can be built up to SCCM’s level, one feature that can be unlocked is its quickness, as well as enhancements that can be channelled more in a simpler way. However, I probably wouldn’t recommend MDT’s use within a larger environment. This is where SCCM really shine. But again, MDT can be unlocked to fit in a large environment with the right design, and it all comes from analysing the business needs and goals in order to come up with the best fitting solution.
I’ll follow this article with more details, so please let me know what you think and what questions you have.
Well done, looking forward to your next post on the subject
Part 2 of this article is now available