System Center 2012 or Microsoft Deployment Toolkit for OS Deployment, Part 2, by Dujon Walsham
NOTE: I'd like to thank Dujon Walsham for writing this series of blogs. Please let me know if they are useful, and submit your own! Thank you! Karen Forster
This is part 2 of my blog, "OS Deployment: System Center Configuration Manager 2012, or Microsoft Deployment Toolkit, or Both," https://blogs.msdn.com/b/customer_reviews_of_stb_products/archive/2013/03/11/os-deployment-system-center-configuration-manager-2012-or-microsoft-deployment-toolkit-or-both-by-dujon-walsham.aspx? Inthis part, I will do a short (if you can call it that) analysis of the architecture of both System Center Configuration Manager and Microsoft Deployment Toolkit (MDT) deployments, so we can pick out features which we can use for the Zero Touch Installation (ZTI), as well as identify spots in which the ZTI can improve or help towards a parti
Why ZTI for Task Sequence Deployment
Whilst this ZTI method is based around the MDT side of things, I thought to base the reasoning around the SCCM side, MDT will also be explained. One thing SCCM might not necessarily focus on is the individuality of each machine. For example, the SCCM and MDT Task sequences would handle values which would be considered to set the machines individuality by providing randomized values for the following:
- Computer Name (Can be done through “Import Single Computer”)
- Network Details (IP Address, DNS, Default Gateway)
- Server Roles/Features
- Applications
Now these values can be set to your standards if you were to have conditions for naming to read from the Active Directory, and Network details if you have DHCP set appropriately.The point is that for a Task Sequence to consistently maintain your standards, it would rely on too many factors. It would be great to have this setup, but one thing you may not anticipate is when errors occur in this Task Sequence, which would be a very tough task to troubleshoot due to its complications and multiple dependencies. Of course if this Administrative effort isn’t an issue for you, then perhaps this would be the way to go, But let’s take a MDT type solution, which is where ZTI will come into play
ZTI
The whole idea of ZTI is to provide Zero Touch. I have been skeptical towards this type of approach as it makes it harder to trace errors, as well as making you unable to have overall control over the whole build life cycle. But this can be done, and the administrative effort can be a lot shorter than it would with SCCM. So
let’s look at each Task Sequence so we can analyze and then take an element of each. this will allow us to cook up an overall solution and combine the best of both worlds.
SCCM Task Sequence
Once a machine has PXE booted into the distribution point, depending on your setup it may ask you for a PXE password. If not it will just ask for you to click “Next,” and you will see the Task Sequences available to you. Of course this can be avoided if you deploy the Task Sequence as “Required” which will have a countdown of 15 minutes before it automatically builds.
To focus on the individuality of each machine, it can either be automatically configured through the Task Sequence, or it would have to prompt at particular steps for this. But this would pause deployment, which would defeat the whole objective of ZTI.
One thing we could use from this is how it doesn't ask for any additional info by default,t such as how a MDT Task Sequence would do. This would be the foundation of how we want pre-staged machines to be. But with the individual focus already applied during this form of deployment, MDT Task Sequence, this is more focused on two physical boot images listed within the PXE boot and will lead you right into the MDT build process. This will then display a Wizard for you to specify your settings, and this Is great as you get to have your input on exactly how this machine is built.
However, in terms of ZTI, this is considered to be light touch as you still have to manually input the information in order for the deployment to start. But here we still do take a dose of its actions. As we can see from its steps, vital information is needed, and this is what we to provide but in a more seamless manner.
SCCM + MDT Integrated Task Sequence
A MDT task sequence via SCCM gives you best both worlds as you can now use advancements and settings within MDT, which may not be available through SCCM. For example the biggest one would be the Wizard function. With this, you can now go through each window to specify settings to customize the machine you are looking to build, and can also create a custom deployment wizard to pre-define how it creates these settings.
Again, these advancements within the custom wizard to pre-define and set default variables aid in the assistance of standardizing how you build the machines with its individual focus. This is something we would like to use also.
How to achieve a real ZTI experience (Theoretical Design)
Within the MDT 2012 toolkit console you have several options which would build the architecture for this
1) Custom.ini Settings
Function: Here you can specify the steps in which you would want to skip in the default wizard of MDT booting into the PXE, as we will be using a different method of selecting TaskSequences.
Reason: So the aim of this step is so once every step in the wizard is silenced, it would allow us to customize the experience of how we would build machines with a ZTI focus. Once they are pre-staged, there will be no manual input required by the users
2) Task SequencesFunction:
For these task sequences to aid in the ZTI focus, we can either do Task Sequences, which would perhaps deploy either a vanilla OS build (Thin) or an image that has a Company Standard focus with apps and settings pre-loaded (Thick).But what we can do is add steps into these Task Sequences such as “New Application” and “Install Role or Features” etc.
Reason: This will be so while pre-staging. We can also pre-stage various options such as to install another application on top, whether Thin or Thick build, a new role or feature, etc.. The overall reason is to add further customization to the builds is to focus more on role based identities and having to cut administrative effort on post build related tasks.
3) DatabaseFunction:
Setting up the database within the console will allow you open up to the pre-staging of building machines and create rules and specify the order in which these rules are followed.
Reason: In order to focus on the individuality of each machine, regardless of Task Sequence used, we need its database properties, as well as the detection of the machine to the database
4) MDT Deployment Frontend
(Optional but recommended)Function:
A great add-on created by Maik Koster can be found here https://mdtwebfrontend.codeplex.com. In the Database of MDT, there is a section in where you would pre-stage machines with many settings and variables. Though it will still have ZTI working fully, it lacks in User Experience and feasibility, and this is where
the MDT Deployment Frontend comes in. With this powerful tool it adds a Webpage, which ties into the MDT database to use the same settings and variables, but it can be customized for better quality control and better focus on the user experience.
Reason: A little direction on the setup to tie into the ZTI focus can make the administrative effort very painless and efficient, and make the interpretation of advanced settings very easy. For overall control of customization I highly recommend this.
5) Specific Features from
MDT & SCCM
Earlier in the ZTI section, I went through the SCCM and MDT deployment breakdown and picked particular features that the ZTI would be based around.
SCCM for its ability to go straight into a Task Sequence without no user input
MDT for displaying the settings we can customize in order to build the machine with manual input
SCCM + MDT for providing the advancements of the settings within a wizard to predefine values and variables
Reason: These are the foundation points to build the user experience and feasibility within the MDT Deployment Frontend so all features will be used to provide the flow of the lifecycle, as well as reduce concerns of overall administrative effort.
Overall these are the building blocks to work smarter, and not harder.
I hope this part of my series was helpful. The next and final part will show visually the steps and breakdown on how this design will come together, and it outline real-world scenarios in which this can be applied to a particular way of carrying out tasks.