36:144: execution error: An error of type -10810 has occurred. (-10810)

The problem is that the script uses a straight Applescript call (osascript) to call System Events to display a message. The error message "An error of type -10810 has occurred." means the script tried to do something as the logged in user while running from another account, like root. Back in the day on older OSes like the one this script was designed on, that was never a problem, but Apple has made it harder with each version of OS X to do this. If you look at the portion of the script that calls the message up, if you chose to background the message, it uses jamf displayMessage, which doesn't run into the same problem. Since you're choosing the interactive method, its trying to use the osascript call and its failing. The OS is stopping it from displaying the message because that osascript command isn't being run as the logged in user.

Looking at the script, I'm unclear why JAMF chose to use 2 possible messaging methods. Its not hard to call jamf displayMessage and have it wait for input before continuing. There's no need for an Applescript window for that, so I'm not sure what the original thinking was for that.

Thanks for the input, @mm2270!

It appears that the issue lies between lines 119-125 of the original script (copied below).

case $background in "true" | "TRUE" | "yes" | "YES")
        echo "Displaying backgrounded message to user..."
        /usr/sbin/jamf displayMessage -message "$message";;
    *)
        echo "Displaying message to user..."
        osascript -e 'tell application "System Events" to display dialog "'"$message" -e '"buttons {"OK"} default button 1';;
esac

If so would simply adjusting the path which is referenced fix this?

/usr/local/bin/jamf -message "$message"

@mm2270 I am thinking about ditching this approach and going with deferral messages instead.

1. OS X Installer is locally cached at recurring check-in and is scoped to a specific smart computer group--those without the specified OS X version and without the installer already cached.
2. Once cached and completed, a second smart computer group is used (those with this specific installer cached) is used to publish the below messages at next log-in.
3. The user selects a time that best fits their schedule and the installation begins.

What're your thoughts on this approach?

@sepiemoini Looks like it makes sense. At least its one of many possible approaches. I'm sure everyone here has some specific method of doing this, but I don't see any issues with the above.
In fact, we actually do something similar. as in caching the OS installer in one policy, then targeting the group with that installer cached to send up messages that their OS upgrade is ready. The main difference for us is its still user driven from Self Service, or via a button in the jamfHelper message mentioned earlier. So we don't force them to choose a time to run it. Other than that its a similar approach and it works well for us.

@mm2270 Oh nice! Do you mind going into more details about the jamfHelper approach? I think a more friendly, user-driven process would be worth investigating.

@sepiemoini There isn't a lot to detail, as far as the jamfHelper route. The images you posted above are from jamfHelper and are somewhat similar to what we display (although not with the hud window style)

What we do is split it up into 2 policies. for AM and PM. We have each one run once per day and limit the timeframes for each one to either the AM hours or the PM hours, so the clients get a message on screen 2 times per day maximum that their OS X upgrade is ready to be run. This all takes place after the installation is cached on their Macs from a separate policy.
We have a Self Service policy that the user can run that kicks off the installation, or they can click on a button in the message I mentioned that simply runs a trigger to call the install policy. Either way its running the same thing though.

Does that make sense?