Much time and effort goes into developing the “ultimate task sequence”. The first true test of that claim is during a pilot, as you venture into the unknown.
One such situation was during a large-scale OSD project, where the customer provided a handful machines to test with. A few of the deployments failed at the start of the pilot for various reasons. Others completed the deployment, but with non-standard configurations like multiple partitions. Additional machines were provided to continue with the pilot, but same results.
After further investigation, the failures were caused by one or more of the following conditions:
- Unsupported hardware models
- No wired network connections
- USB drive connected
- Laptops running on battery
A new set of machines were provided, trusting that the customer would provide machines which met the following requirements:
- Only supported hardware models would be provided
- Wired network connection
- No USB drives attached
- For laptops, AC power connected
Having learned from the previous pilot attempts, we wanted to “…trust but verify” the machines configurations.
Sure, visiting each machine prior to the deployment would provide some reassurance, but that labor and time intensive process would be difficult to maintain. Deployment readiness reports were also used to verify machine configurations. This was good because reports are generally a reliable source of information for these scenarios. Reports are ad-hoc in nature. However, they are primarily based on inventory cycles being executed, with increased chances for inaccuracies. Consequently, there grew a need to adopt an even more reliable verification process, having the verification process run in real-time during the deployments.
So why is this important?
If a non-standard configurations or environmental condition would ultimately doom the OS deployment to failure, the deployment should fail “safely” and before the point of no return e.g. before the disk is formatted or Apply OS image step executes. If the deployment fails after either of these steps execute, there’s very little chance – if any -, for recovery. Essentially, the computer is “bricked”, requiring a desk side visit…and possibly data loss.
Failing a deployment “safely” should be a desired goal for any deployment scenario. When deployments are failed safely, the computer can be quickly returned back to its original state before the start of the deployment.
So how do we do this? Pre-Flight Checks!!
Pre-Flight Checks are a group of task sequence steps used to detect non-standard computer configurations and environmental conditions. Their goal is simply to fail the deployment “safely” when undesired configurations and environmental conditions are detected.
Deep-Dive into the Pre-Flight Check task steps
Let’s take a look at some of task steps which make up the Pre-Flight Check group:
How do you create a Pre-Flight Check task sequence?
The long and hard way is to start from scratch…but I have something better. How about creating and perfecting it once, then making it a “template” so that it can be (re)used and shared with others?!?!
To help accelerate things for you, a Pre-Flight Check task sequence template has already been created. Just follow the instructions below to get started:
- Download the template giving it your own filename (e.g. <filename>.xml), and saving it to the location/directory where MDT is installed (e.g. <MDT install-directory>\SCCM)
- If the ConfigMgr Admin console is open, close it and then reopen e.g. this is required so that the new task sequence template can be read from the folder
- Navigate to Software Library -> Operating Systems -> Task Sequences
- Right-click Task Sequences and select Create MDT Task Sequence…you should now see the Pre-Flight Check template named Client Task Sequence – with Pre-Flight
- Continue with the wizard, configuring the remainder of the task sequence options
- You should now have a new Client Task Sequence with the Pre-Flight Check group at the top
- To integrate the Pre-Flight Check group into an existing deployment task sequence, just copy the group from the newly created Pre-Flight Check task sequence – and with your deployment task sequenceopen -, paste the group at the very top of top of the task sequence open -, paste the group at the very top of top of the task sequence
- Update the conditions on the Check if computer is a supported model action as appropriate for your environment
- Update the conditions on the Check if connected to wired network as appropriate for your environment
- Finally, select the Options tab of the Execute Task Sequence group Check (enable) Continue on error Create a Task Sequence Variable condition
- Name: PreFlightCheckGlobal
- Value: PASSED
Note: This makes it so that the Execute Task Sequence group will only execute IF all of the Pre-Flight checks passed (e.g. successful).
So that’s it!! You should now be able to edit your deployment task sequence, reviewing the Pre-Flight Check group and adding further customization with your own custom pre-flight checks.
My next blog post will explain:
- Structure and Flow of the Pre-Flight Check group
- Use of the task sequence variables in the Pre-Flight Check group