Script throws error when run as recurring policy, but not on custom trigger

[jkuo]

Hi all,

I'm working on a script that will pop up a dialog using the standard AppleScript dialog box to the user to prompt for installing software updates. This script works perfectly fine if run locally (sudo ./SUSUpdate.sh) or if I run it using a custom trigger (sudo jamf policy -trigger SUSUpdate).

But when it runs in a recurring check-in trigger, the dialog box fails to display and an AppleScript error is thrown.

Here's the section of the script that's throwing the error:

prompt=`sudo osascript << EOT
            tell app "System Events" 
                Activate
                display dialog "A critical update for your computer - $ForceUpdateRequired - addresses a significant security vulnerability and needs to be installed. Do you want to install it now?"  with title "Software Update Required" buttons {"Not Now", "Install"} default button 1 with icon file "Library:Application Support:JAMF:bin:SoftwareUpdate.icns"
            end tell
EOT`

$ForceUpdateRequired was set earlier in the script to be the name of the forced software update, and I also have another section of the script that copies in the SoftwareUpdate.icns file into the path /Library/Application Support/JAMF/bin/

When it gets to that section of the script, here's the log on the JSS:

32:40: execution error: An error of type -10810 has occurred. (-10810)

I can't find a reference of that error anywhere, and there must be something in that one line of code to display the dialog that's causing the problem.

Does anyone have an idea what might be going on?

Thanks,
Jason

[nessts]

one word cocoadialog

[nessts]

Apple has secured AppleScript so that interaction with the user is nearly impossible from things that are running as root. Use CocoaDialog instead, and now with the new 10.10 flat design CocaDialog looks like it belongs.

[dwhitehead]

+1 for cocoadialog.

Applescript can be very particular with permissions. Try dropping the sudo (recurring check-in and self service will run the scripts at an elevated level anyways).

[perrycj]

Also +1. Cocoadialog is pretty great.

[mm2270]

While there are some ways to make Applescript work in this context, in all honesty, the suggestions to use cocoaDialog are spot on. Its really not worth the effort to get AS to work as the user when run in a root context. It can sometimes work and sometimes not, where as cocoaDialog almost always works. And its more flexible for messaging to boot. If you're not familiar with how to use, just enter it in a search here on the 'Nation and you will pull up dozens of threads with working script examples.

[Look · Accepted solution]

Mostly like @mm2270 is right scripts out of Casper never line having "sudo" in them and your generally sudoing the whole script anyway so it's usually redundant to include it within scripts themselves.

[jkuo]

Thanks everyone for the suggestions. Here's how I ended up getting it to work:

1. Created a policy that ran the script on a custom trigger
2. Created a second policy that executed the command sudo jamf policy -trigger CustomTrigger

Then everything seemed to behave nicely. I'll definitely take a closer look at cocoadialog - looks like there are a lot more options available in there than plain applescript!

[jkuo]

@Look - just ran another test, and indeed, it turned out that removing any sudo commands from the script repaired the error. Thanks!