Open Self Service from Policy

[ctangora]

Trying to open Self Service.app from a policy. Essentially have SS open in the background and have a window displayed telling people they should really update their system.

Half the systems it works on, the other half it doesn't. Using the "run command" in advanced policy field...

open /Applications/Self Service.app

Does anybody open an application from a policy, and if so, how are you doing it?

[mm2270]

You can try calling it by its bundle identifier with the open command. Sometimes that works more reliably.

open -b com.jamfsoftware.selfservice

Another option would be an osascript to open it instead of a pure bash command

/usr/bin/osascript -e 'tell application "Se;f Service" to activate'

[ctangora]

Tried both. Same intermittent results. Trying this next...

find /Applications -name "Self Service.app" -maxdepth 2 -exec open {} +

... will let you know if that works any better.

[mm2270]

That's strange. Any discernible difference between the Macs that work and those that don't? Difference OS versions? Difference versions of the jamf binary?
You really should not need to scour the Mac for the application with the find command just to launch it. Something's not right. Maybe the LaunchServices.plist is corrupt on the Macs that its not working on.

[ctangora]

We keep on getting this error, no matter how we open it (open, osa, find, etc)

LSOpenURLsWithRole() failed for the application /Applications/Self Service.app with error -10810.

Researching it says the process table is full, but it seems unlikely that is the case. More likely there is an issue with opening the GUI from the root, though it works just fine from the command line.

I'll take a look at our LS.plist and see if that helps. Thanks for the lead.

[Bukira]

hmmmm surely as its a policy launching the SS App and polices run as root, then SS would be launched by root and not the logged in user?

[tlarkin]

Hey Everyone,

Have you simply tried this?

open -a Self Service

Works for me from terminal.

[agirardi]

Just tried this in a new policy, and it worked for me.

[ctangora]

Works for me in a policy when I run it in Terminal. But when I run it through LaunchD it doesn't, as you can't have a non-Aqua Session launch an Aqua Session.

[agirardi]

That is what i am seeing as well. I called the policy in terminal and it succeeded, but not when I let the every 15 trigger run it, it failed.

[agirardi]

I suppose you could just run the display message

/usr/sbin/jamf displayMessage -message "There are updates available, please open self service"

[ctangora]

I have the message popping up (and even have a hero beep to get their attention).

The alternative is to have the process launch, but then the policy doesn't complete until Self Service has quit. Trying to run it in the background makes SS jump for a second then go away.

Tried nohup, tried screen. Running out of ideas here.

[mm2270 · Accepted solution]

I just tested a policy using the following syntax in the Run Command and it worked for me from a policy that ran from the everyX minutes trigger. I let it run naturally and Self Service launched and came up on my screen.

sudo -u $(ls -l /dev/console | awk '{print $3}') /usr/bin/osascript -e 'tell application "Self Service" to activate'

You can try that and see it works any better.

[agirardi]

That worked in my environment. Thanks!

[ctangora]

Worked here, but did an open -a /Applications/Self Service.app instead.

Went off an old Jarod script that did a cut instead.

[jennifer]

@ctangora, I've been trying to do the same thing, have the users click on an Install message to open self service and update their machines. I've tried all of these, and they are fine via terminal or ARD, but once I put them in Casper I get the same "An error of type -10810 has occurred. (-10810)" every time. When you got it to work, how did you end up calling the script?

[yellow]

The errors we're all seeing is because the script is being invoked thru Casper as root, not as the user who is currently logged into the console. This appears to be how Apple designed security into the GUI to protect it from having scripts throw pop-ups and windows at the logged in user. I suspect all the folks who got results from "open -a /Path/blah" were invoke this with the same user as on the console. Those of us who try to use open or osascript and it is run as root via a policy, we get the (-10810) error. I have had very mixed results from using the method of finding out who owns /dev/console. For some, it will work in the command line, but not as a policy. For me, this does NOT work if you ssh in remotely, switch to root as the user, and try and run the command.

sudo -u $(ls -l /dev/console | awk '{print $3}') /usr/bin/osascript -e 'tell application "Self Service" to activate'

Hell, try it this way ssh'd into a remote machine as a different user (or switched to root)..

sudo -u YourUserName open -a Safari

Betcha it'll fail.

I'm more or less pulling my hair out now trying to find a way around this.

[yellow]

Hmm...
So I happened upon this strangeness... if I use the Finder to open Self Service.. it works.

sudo -u $(ls -l /dev/console | awk '{print $3}') open -a Finder /Applications/Self Service.app

And more strangely, I want to open a particular file (an html doc) an force Safari to the front using a pipe thru to exec.

sudo -u $(ls -l /dev/console | awk '{print $3}') open -a Finder /Users/Shared/PGP/Notification/PGPNotification.html | exec /Applications/Safari.app/Contents/MacOS/Safari &

[tlarkin]

Sorry for my late response, but I am just now having the time to test this out. I was able to accomplish this on a JSS version 8.71 (yes I know I need to update my test VMs) with a policy. I just created a manual trigger policy to test this with, and in the advanced tab, under the run command box, I simply put this:

open -a "Self Service"

Here is the result of the policy log:

/usr/sbin/jamf is version 8.71
Executing Policy open self service...
Running command open -a "Self Service"...
Result of command:

Self Service opened at the end of the policy and it worked fine for me. I did not have to tell the binary to open the app as the current user. Is anyone else, not getting the results I got? Please let me know and I can try to test this further.

Thanks,
Tom

[bentoms]

@tlarkin once it's opened, can you complete the installer?

I found it would launch but you would not be able to complete the install as the authentication prompt never appears when after selecting the volume.

@yellow's steps seemed to work.

[tlarkin]

Hey Ben,

So, the work flow is as follows?

1 - policy kicks off a message to the end user that they need to run updates
2 - if they click yes, it opens self service
3 - end user clicks policy and updates run

I guess rereading this whole thread I am not sure exactly what is the overall end goal. Sorry for any confusion.

-Tom

[bentoms]

Sorry my fault. I misread & replied to the wrong thread. Doh!

@yellow's steps helped me run the Install OS X Mavericks.app.

Sorry for the confusion.

[tlarkin]

@bentoms, no worries mate. Hope you had a good trip back to England after the JNUC, and it was good to finally meet the man behind the Mac Mule!

-Tom

[krichterjr]

Interesting post here...

I too am now seeing this LSOpenURLsWithRole() failed for the application error when trying to push this script through and "every15" policy.

# Close Cisco AnyConnect Security Mobility Client
killall "ciscod"
killall "Cisco AnyConnect Secure Mobility Client"

RUNNING SOME THINGS HERE BEFORE STARTING IT AGAIN

# Open Cisco AnyConnect Secure Mobility Client
open /Applications/Cisco/Cisco AnyConnect Secure Mobility Client.app

The interesting part about this is I've had this available for sometime in Self Service without any issues. Today, I changed it to "push" to the remainder of our computers via the "every15" trigger and immediately started logging this error at about 90%.

So I disabled it and started testing locally through Terminal, then via Self Service, and also pushing it to a few test machines individually. All these worked fine!

I tried changing my script to use the open -a and tested both "pushing" it to some test machines and that worked fine.

open -a "Cisco AnyConnect Secure Mobility Client"

However, once I enabled it for a larger group I started filling the policy logs with the LSOpenURLsWithRole() failed for the application error.

Any of you geniuses have any thoughts on this?

Thanks in advance!

[Retrac]

I too was having issues when trying to open the Self Service application from a script that was triggered via a policy.

I got it to work using
LoggedInUser=who | grep console | awk '{print $1}'
su - $LoggedInUser -c "open -a Self Service.app"

This worked on 10.10.5 and 10.11.2