Picture this if you will, you have 20 models of hardware in your organisation that you’ve meticulously created Driver Packages for and ensured they build correctly with your managed images, thus creating a list of Supported Hardware. Sounds good, right?
So imagine the surprise and confusion when on a cold, dark Monday morning before your first cuppa, someone rings you up to say their computer won’t build, or missing certain drivers once it does!
Only, things aren’t as they seem. As you find out once you’ve delayed your first cuppa, and have come to find out that this computer is a completely different Manufacturer, let alone Model from anything anywhere near your list of Supported Hardware. So it’s not surprising it’s failing to build!
Sound familiar?
Well, this began happening a little too often for my liking, so I decided to create an Unsupported Hardware Filter. Put simply, this is a bouncer on the doors of my Task Sequence, filtering out the riff raff and making sure everyone has shoes on.
I’ve put this through a couple iterations now, and I can honestly say since implementing it, I haven’t received a single call about the scenario above, and instead I receive “If we get this model in, will we be able to build it? Or will you need it for a few days first?”…
So as you likely know, there are more then 1 ways to skin a cat Task Sequence, so I’m going to show two different ways to accomplish this. Firstly, with nothing more then you currently have, and Second, Powershell.
1) With nothing more then you currently have
Firstly, you need to ensure you have a correct set of logic in the folder groups of your Task Sequence.
It’s vital that you have a single top level folder at the very beginning with “Continue on Error” ticked. All other steps in the Task Sequence must be inside this folder.
The same must then apply for the ‘Execute Task Sequence’ folder in the image above, all Task Sequence steps should reside within, and it should be set to “Continue on Error”, but it should not be set to continue on error, and not on the same level unless you add extra filtering. If you’re unsure where this is going, keep reading and all will become clear.
Now lets create a new Set Variable step.
Name = Windows 10 – Check Supported Hardware Model
Task Sequence Variable = Win10SupportedHardwareModel
Value = True
Select the Options tab on our new Step and create two nested If Statements, If All then an If Any. – as an aside, this is the best way to start any conditions, as it allows you to be flexible for change later on.
Under the If Any, you are going to create your list of Supported Hardware. Here you add in WMI Query’s for each of your Models which you want to be able to build. You are likely familiar with these WMI queries already from your Driver steps, but if not here is an example:
Select * from Win32_ComputerSystem where Model like ‘%Vig830S%’
Now, select the ‘Execute Task Sequence’ folder in my scenarios, and set a Task Sequence variable condition to only run if Win10SupportedHardwareModel = True.
So, whats going to happen now we’ve configured this?
Well as your client, in this example an Unsupported one, begins the Task Sequence it will attempt to run our new ‘Check Supported Hardware Model’ step, but because its not on the list it simply wont run meaning it wont set the “Win10SupportedHardwareModel” variable to True.
When the ‘Execute Task Sequence’ folder then attempts to run, it can’t because the variable is not True, meaning it skips the folder all together and goes to the next item, but if you’ve followed correctly and there is no next folder in its logic, it has to go back up the chain to report to the ‘Validation’ group and say ‘Hey theres no way this way’, to which it replies “Don’t worry, I can Continue on Error in these scenarios” and it now skips the entire Task Sequence to find another folder at its root level.
So to stop it dropping out here, we need to create another root folder, but this time at the end of our Task Sequence to catch our Unsupported Hardware.
I appreciate at this point it could be hard to follow if you haven’t done something similar to this with logs before, so below is an image to example the logic:
Download the two vbs scripts from here
Make them into a Package called ‘ErrorPrompt’, with source files, but without a program, and distribute them to your DP’s.
Now create the ‘Unsupported Hardware Group’ folder at the bottom of your Task Sequence, and set the ‘Win10SupportedHardwareModel‘ variable to Not Equals True under Options. (yes not equals true instead of false)
Next up, add a Run Command Line step with the command line;
Powershell.exe -command start-sleep 2.
Now another quick step, add a Set Task Sequence Variable step:
Task Sequence Variable = ErrorReturnCode
Value = %_SMSTSLastActionRetCode%
And lastly here, add another Run Command Line step
Name = Unsupported Hardware Error
Command Line = cmd.exe /c ErrorPromptUnsupportedHardware.vbs
Package = ErrorPrompt
Save your Task Sequence and go try to build something not on your Supported Hardware list!
Easy, ay?
You could of course then scale this up slightly to support a single Task Sequence which houses numerous Operating Systems etc.. in my example below I set which OS to install via UDI, and then two steps run:
2) Powershell
What can’t be done with Powershell?
I’ve begun the process of moving the Unsupported Hardware groups check you’ve read above into Powershell, and I think it speaks for itself in how it works, and also can be easily customised to fit different scenarios, so instead of telling you what to do, I’m going to give you the link to the script and leave a few screenshots of how I’m currently seeing its future.
Two files need to be downloaded. The “SupportedHardware.txt” file needs to hold the full model name for you supported hardware models. And the “CheckSupportedHardware.ps1” will need line 20 changed to reference where the txt file is located.
As for it’s use, well:
With some tweaks you could of course use this in the Task Sequence directly instead or a multitude of other places. Let me know how you use it!
But for now, If this has helped you please do subscribe, share, or follow me on Twitter to be sure you catch future instalments.
Rich Mawdsley
Cool stuff!
LikeLike
Hi! Thanks for this Guide. So far it works for me. BUT, if the Tasksequence fails at any point, the technician won’t see an error message, as everything is set to “continue on error”. Did I miss anything or is this behaviour with this TS normal?
LikeLike
Only the top level groups are set to continue on error. All steps under Execute TS folder are in their own individual folders, all of which do not have continue on error on.. So, once it actually starts the TS, if it fails it will still fail in the normal way.
LikeLike
I cannot confirm this. In my TS I have set “continue on error” at the Group “VALIDATION”, “Execute Task Sequence” and “Unsupportet Hardware Group”. If the TS fails in a group below “Execute Task Sequence” it will skip the rest and reboot the machine. The TS Fails but it doesn’t show me an error.
LikeLike
Hi Andreas,
Export/zip the TS and email it over, I can take a look and see if I can figure out where it’s going wrong.
Rich
LikeLike
Hello Rich
Got a question on the PS script. Can I put the support models file on network file share. For example where i am running my OSD deplyment from? From the example in you file line 20 appears to be local.
LikeLike