Troubleshooting OSD with-out being there

I can’t take any claim for this idea but it is one that I think is handy enough, and not very well known, that I am trying to spread the word.  One of my co-workers has a great way to capture OSD logs when a failure occurs so they can be easily read and not lost simply because you weren’t in front of the machine to hit the function key and sniff around via a command prompt.

The simple concept is this…. you take your entire task sequence and place it under a new high level folder.  If any step in your TS should fail control will be returned up to this top level folder.  You set this top level folder to continue on error, leading to the next part.

Also at the top level, but below the folder you previously created you create a log capturing folder.  Under this folder you have some tasks which capture the SMSTS log and other related files and copy them to a file share on your network.

The end result of all this is that if any task in your TS fails, no matter which stage, you don’t have to hunt for the logs and you don’t loose them when the machine re-boots into a failed deployment.  You just go to the file share and take a look at what failed then go fix it.

All the details are on Steve Rachui’s blog at https://blogs.msdn.com/steverac/archive/2008/07/15/capturing-logs-during-failed-task-sequence-execution.aspx