- DP replication issues
- Planets are not in alignment
- Network issues
- Someone cut the hard line.
Whatever the cause, If the error is at the beginning of the task sequence there is no major downtime but if the error is towards the end, then that 2-3 hour image deployment process could take 4-6 as they start it over again and for what, Adobe Reader didn't install because someone or something updated the DP content?
Use whatever makes sense to you and place that step in any location you might need to know about if a failure occurs. If a failure does occur, the script used by the “Create Log” step reads that variable and writes the step to a text file in the %OSDISK%\OSDLogs folder.
At the very end of the TS a VB script message box is displayed that lists some basic instructions as well as the item(s) that failed (below). The tech can then install what was missed post Task Sequence.
The TS here is an over simplified sample TS to show the basic structure.
When I first started experimenting, I placed the entire TS in a try…catch block and once I saw it worked, started grouping software into try blocks as I wasn't sure if I would hit a limit on the number of steps allowed in a TS. I had all MS software in one block, Adobe software in another but the problem with that was if a particular step failed, it would stop processing everything else in that group. The catch afterward would catch the error and proceed to the next group but any step after the failure in the “Install Microsoft Software group” would not get run.
This is a sample of the MS section. You can ignore the 'pre-stage' steps as those are for 1E Nomad (posts coming soon!). So I set out on a journey to see if I could have a try…catch block at every software install step that was important enough to catch. I wound up with a lengthy TS but so far it is consistently doing what it was built for, producing an imaged computer at the end that captures any errors and notifies the tech afterwards if there is a failure.
The imaging time is not increased due to a relatively minor failure to install a package freeing up techs to do other things. If the image is successful, the techs will notice nothing other than what they are used to, a Ctrl+Alt+DEL login screen when complete.
After that endeavor, I started thinking of other possibilities. The TS now compresses the %OSDISK%\OSDLogs folder and copies it to a network share. In the case of a failure, an email is sent to our support group Inbox advising of the failure so we can jump on the issue proactively. Depending on the step that failed I am gathering additional logs that can help determine cause such as copying the WindowsUpdate.log if there is a problem with installing any updates or the logs from the %WINDIR%\Panther folder if there is a problem applying the OS. In the screenshots below, there were several items that failed and going into Reader you can see it grabbed all the relevant logs up to that point.
Since we are gathering data on failures visa-vie the error logs, why not gather data on the successful images as well? To that end I am now gathering start and end times when an image is successful so if we ever do want to see how long an image is taking we have the data outside of reports. This can also be useful in tuning OSD or noticing that it takes 20% longer in office X vs Y.
To go one step further you can reference this post for simple cleanup of the log folders.
DownloadThis script is provided as-is, no warranty is provided or implied.The author is NOT responsible for any damages or data loss that may occur through the use of this script. Always test, test, test before rolling anything into a production environment.
You can find all the scripts referenced in this post as well as a sample TS (2012R2) here. You will need to tweak them for your environment for things like variables and log paths. The scripts should get updated to be more friendly towards distribution.