Whilst most organisations will already have a robust build process in place, the task sequence error handling is not always considered when creating the operating system deployment (OSD).
Although Configuration Manager will display an on screen error if the OSD has failed, this will only be displayed for 15 minuets by default and if the failure does not immediately impact the functionality of the computer it may go unnoticed.
In this post we will create additional steps in the task sequence to achieve the following
- Provide a visual change to the computer so we know it has failed.
- Get logs from the failed machine so we can trouble shoot the issue.
Part 1: Initial Setup
To enable our error handling we first need to group all of our original task sequence steps into a new sub folder called “Task Sequence” we also need to ensure this group is set to “Continue on error”
This will allow us to detect a failure with any of our current steps and use this to kick off our error handling group.
Next we need to create another new group that will contain the steps for our error handling. We will also enable a condition on the group to only run if the previous group failed.
The Task Sequence Variable to use here is “_SMSTSLastActionSucceeded” equals “False”.
Part 2: Log Files
Now we have the basics setup its time to move on to our first action, getting the logs from the failed computer.
To make our lives easier when troubleshooting a failed machine wouldn’t it be nice if we could have the log files easily accessible instead of logging on locally or connecting to each machine remotely?
Well with a few steps we can copy all the logs we need to a shared network folder and make life a whole lot easier.
To start we need to create a shared folder on the network so we have a place to copy all of our log files, once thats created add another group to the task sequence called “Log Capture”
Connect to the network share
To copy our logs to the share we need to mount the network location, add a Connect to Network folder step and configure the details of the shared folder that was created. Add account details used to map the share and give it a drive letter.
Clear the previous log files
Now we have our network location mapped we will need to clear out any previously copied logs for the machine.
Add a new ‘Run Command Line’ step named ‘Clear Previous Logs’ and add the following code
cmd.exe /c IF EXISTS Z:\%_SMSTSMachineName% rd /s /q z:\%_SMSTSMachineName%
This will check if there is a pre existing folder with the same machine name and if there is will delete it for us.
Create a new log file folder
Once the network location has been mapped and the previous logs cleared its time to create a new folder for the current log files.
Add a new ‘Run Command Line’ step named ‘Create Folder for Computer’ and add the following code
cmd.exe /c md z:\%OSDComputerName%
Copy the log files
The final step to complete the log files section is to copy the latest logs to the newly created logs folder.
Add a new ‘Run Command Line’ step named Copy Logs and add the following code
cmd.exe /c copy %_SMSTSLogPath%\*.* z:\%OSDComputerName%
Part 3: Customisation
The log files have now been successfully copied to a network so its time to configure the visual appearance of the computer so its easy to say the build has failed.
There are many different ways to do this including custom backgrounds and user profile images. We will look at just one of the options below.
To begin we will first create another new group named ‘Customise Screens’ this will allow a logical grouping of the next few steps.
Disable the logon background
The task sequence we have here uses the default Windows 10 logon background, as such disabling this and presenting a solid coloured background will alert us to a problem in the build.
Add a run command line step with the name ‘Disable Logon background’ and add the following code.
reg.exe ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows\System" v/ DisableLogonBackgroundImage /t REG_DWORD /d 00000001 /f
This outline for error handling should provide a good base for additional steps and customisation and most importantly should help us troubleshoot potential problems and prevent failed builds getting into the hands of the end users.