Running Management Action fails on 10.10 (and 10.11)

[johandahl]

Hi

I have this script which calls Management Action to display a notification. The real script is used to notify users of successfull backup. But this is the minimal barebones example.

#!/bin/sh
'/Library/Application Support/JAMF/bin/Management Action.app/Contents/MacOS/Management Action' -title 'Test of Notification' -message 'It worked'
echo "Management Action exit code = " $?

I also made a policy to run this script as ongoing on my testcomputer. It succefully shows an notification if I do the following:

1. Run it from self service
2. Provoke the policy by: sudo jamf policy

but it fails to show an notification when invoked by

1. the computer checking in and running the policy
2. running it with Casper Remote

and the script just logs:

Management Action exit code = 0

All this works on 10.9.

Note: on 10.11 which isn't really supported yet (we still run 9.8 and not 9.81) it also output this:

[82004:2106277] CFPasteboardRef CFPasteboardCreate(CFAllocatorRef, CFStringRef) : failed to create global data
2015-10-06 11:22:56.350 Management Action[82004:2106277] CFPasteboardRef CFPasteboardCreate(CFAllocatorRef, CFStringRef) : failed to create global data
2015-10-06 11:22:56.350 Management Action[82004:2106277] CFPasteboardRef CFPasteboardCreate(CFAllocatorRef, CFStringRef) : failed to create global data
2015-10-06 11:22:56.352 Management Action[82004:2106277] CFPasteboardRef CFPasteboardCreate(CFAllocatorRef, CFStringRef) : failed to create global data

[mm2270]

Hey, just wanted to chime in that I can reproduce this error exactly, and this is under a dev JSS running 9.81 so i can't blame it on not being compatible with El Capitan. If I run the policy manually from Terminal (forcing a check-in) it works. If I run a script locally, even if using root, it displays the message. But if I let the same policy run naturally from the normal check-in process, I see the same errors in the policy log. Seems like JAMF will need to figure out what the deal is here. Management Action.app just became a little less useful as of 10.11 until this can be fixed. :(

[mm2270]

Following up again on this, I did some more testing, and this seems squarely related to not being able to run a call to Management Action.app unless its done as the logged in user. We see this kind of stuff more and more with each version of OS X, so I'm not at all surprised but its still very disappointing that this keeps happening.

The testing I did was to SSH into a Mac running 10.11, using a local admin account as the authentication for the remote login session. This was not the logged in user. I tried the following command, both with and without prefacing it with sudo and got errors both times.

/Library/Application Support/JAMF/bin/Management Action.app/Contents/MacOS/Management Action -title "This is the title" -message "This is the message"

The error that was most interesting was this one:

Oct  6 13:04:57  Management Action[20672] <Error>: This user is not allowed access to the window system right now.
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.

I then exited the SSH session and SSH'd back in, but this time I authenticated as the logged in user, which was my account on the box. I ran the same command as above exactly, and this time the NC message displayed with no errors.
So basically, if the policy runs strictly under a root context, the OS is now blocking the Management Action.app from displaying a NC message. If its run from Self Service or manually by the logged in user, even if done via sudo jamf policy, it works, presumably because its being called as the user and not by the LaunchDaemon (root)
Par for the course. With each new version of OS X, Apple is locking down more and more, causing developers like JAMF to scramble to keep up with all these insane changes. In about 3 years, we probably won't be able to do anything automated unless its the logged in user actually doing it. :-(

[johandahl]

I I however changes the script to use jamfHelper instead will it work.

'/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper' -windowType utility -button1 OK -defaultButton 1 -title "Test of dialog" -description "It worked"

But I don't want to display a dialog but an notification. So I guess this program does something different than Management Action.

[mm2270]

I submitted this issue to my account manager to look into, and they will be trying to recreate it internally and file a defect if needed.
I did find out today that it appears to work if you use the built in policy User Interaction options. It seems to run OK and display the message when it fires using the natural check in frequency. So this issue is limited to calling it through a script or run command in a policy, etc. It begs the question about what that built in option is doing differently than when its scripted that allows it to work.
The problem for me is the User Interaction policy options don't allow for as much customization. You can only specify a message, not the title and subtitle. If JAMF would give us access to all the options the utility can accept in the GUI policy options, I'd be fine with using it that way in at least some instances.

Stil, this needs to be fixed so we can use it in a script again.

[johandahl]

Good work mm2270! Yes the built in option isn't really that useful. It just shows a static message.

[arschebl]

Any further news on this?

[alexissantina]

I am seeing this error every time I try to create a new user account after imaging a machine with Casper Imaging. It effectively makes it impossible to use additional user accounts, other than the ones specified at the time of imaging.

Has JAMF figured out what is causing this yet?

[AVmcclint]

I'm getting the

2016-05-16 10:50:26.432 osascript[3614:18883] CFPasteboardRef CFPasteboardCreate(CFAllocatorRef, CFStringRef) : failed to create global data

stuff only when I install Junos Pulse Secure 5.1.5. It happens 100% of time and the policy log registers it as a failure - even though the software does actually work. What's strange is that previous versions didn't generate that error at all. OSX 10.10.5, JSS 9.81

[bentoms]

@AVmcclint odd. That seems like they might be trying to do something with the clipboard.

[sepiemoini]

@mm2270 @bentoms I too am receiving the same errors on 10.11.x. When I run my script locally within Terminal or evoke the policy to run manually (sudo jamf policy -id <eventID>), it works regardless of what button is selected. When this is completed at the trigger set by the JSS via a policy, errors are received--see screen capture below for reference.

Are either of you/is anyone aware of a fix for this issue?

if [ "$userChoice" == "0" ]; then
        echo "User clicked OK; now launching Self Service."
        open -a Self Service.app
    elif [ "$userChoice" == "2" ]; then
        echo "User clicked Cancel or timeout was reached; now exiting."
        exit 0    
    fi

Also while unrelated, is anyone aware as to why I receive this 10810 error?

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

[mm2270]

@sepiemoini That error is different than what's described in the OP. You're seeing that because when your commands run, they run as root, but the root account, not being the one logged in, will sometimes have trouble opening applications for the logged in user. Its kind of a known issue. You need to call up the app as the user logged in, not leave it up to Casper's default process to do it, because it will sometimes fail with that exact error.

You could also try calling the application directly by its path instead of using the -a flag. Like

open /Applications/Self Service.app

Or even with the bundle identifier flag for the open command, like:

open -b com.jamfsoftware.selfservice

Try one of those to see if you get better results.

[sepiemoini]

@mm2270 Thanks! That seems to have cleared up the 10810 error. While the 10810 error does not pertain to the issue raised in the OP, the other portions of my previous post do. Are you aware of any fixes for that?

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

[mm2270]

@sepiemoini Are you taking about the "CFPasteboardRef... failed to create global data" lines?
If so, no, I don't know of a fix. What version of the Casper Suite tools are you on? I see the Mac having that error you posted is on 10.11.6.
Seems those lines refer to a problem with jamfHelper, but I'm not too sure. If so, that would be on JAMF to fix, not any of us.

[sepiemoini]

@mm2270 Yup! I'm running v9.92 and for this particular issue with jamfHelper, as it pertains to computers running OS X 10.11.x. I imagined that the fix would be one supplied by JAMF but was just curious if one had been communicated to you.

For reference, please review my script below.

#!/bin/bash

/usr/bin/curl -s -o /tmp/wp_icon.png https://lh4.ggpht.com/5wzR5Tsj5fQ4Igs1R1HMBep99ufDzMr0028lxn2Ji4GTidrwwMM5D74JvGE6nmH6OcKH=w300
jamfHelper="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper"
windowType="hud"
description="Your corporate-issued computer is not currently running the latest version of OS X El Capitan. Please first review the information below and then proceed to complete the upgrade from Self Service.

*If you are working remotely, please connect to the VPN.

*This update requires a reboot following installation so please save anything you are working on.

*Please allow approximately 20 minutes for the installation.

When ready, navigate to the Self Service window and then locate the 'OS X Update Combo 10.11.6' icon and select 'UPDATE.'"
button1="OK"
button2="Cancel"
icon="/tmp/wp_icon.png"
title="Update Available: OS X Update Combo 10.11.6"
alignDescription="left" 
alignHeading="center"
defaultButton="2"
cancelButton="2"
timeout="300"

userChoice=$("$jamfHelper" -windowType "$windowType" -lockHUD -title "$title" -timeout "$timeout" -defaultButton "$defaultButton" -cancelButton "$cancelButton" -icon "$icon" -description "$description" -alignDescription "$alignDescription" -alignHeading "$alignHeading" -button1 "$button1" -button2 "$button2")

if [ "$userChoice" == "0" ]; then
    echo "User clicked OK; now launching Self Service."
    open /Applications/Self Service.app
elif [ "$userChoice" == "2" ]; then
    echo "User clicked Cancel or timeout was reached; now exiting."
    exit 0    
fi

Here are the two logs received from the two test machines I am using. The first log is a computer running 10.11.x and the second on 10.10.x.

[sepiemoini]

Also @mm2270 I am still receiving the "LSOpenURLsWithRole() failed for the application /Applications/Self Service.app with error -10810" error after trying your two suggestions a few posts back.

"open /Applications/Self Service.app" and "open -b com.jamfsoftware.selfservice" seem to both fail when the policy is ran naturally from an event trigger (i.e. recurring check-in). When I run the script with locally from Terminal or call the policy by ID, no errors are generated. It's also worth noting that the user-facing actions are totally perfect, the errors only appear in the logs within the JSS.

[mm2270]

Right. Well, it was never a guarantee to work. The basic issue is that when a policy is run by the natural check in trigger or other triggers, its being run by the LaunchDaemon and so being run as root. Root can't open an app for another logged in user. If you were to SSH into a Mac under a local admin account (not the one logged in) then open a root shell and do the same commands, you'll get the same error.

You have to use either the sudo -u trick you sometimes see posted on threads here to run the commands as the user, or use launchctl asuser to run it as the logged in user. Example:

loggedInUser=$(stat -f%Su /dev/console)

/bin/launchctl asuser $(id -u $loggedInUser) sudo -iu $loggedInUser "open -b com.jamfsoftware.selfservice"

Plug in the above code to see if you get better results.

Circling back on the error, this thread was originally referring to the use of Management Action.app, not necessarily jamfHelper.app, though I'm not completely surprised to hear that jamfHelper may be having the same problem as its cousin application. Apple makes it tougher and tougher with each OS rev to run certain commands or pop up dialogs as the current user, for security reasons.

I looked back at my cases, and this issue (specifically with Management Action.app) was filed as D-009802. I was told to watch for it to be fixed in a future release. That was back in late 2015, but I haven't looked to see if this defect was mentioned in any recent release notes. If you're seeing the issue with jamfHelper now, it may be the same issue, but it could be something new. If you feel like going thru release notes looking for that defect number, feel free.

[sepiemoini]

@mm2270 Big help, thanks! I was reading up on other JAMF Nation posts and came to the same conclusion as well with the logged in user vs. root issue.

I'll dig thru the release notes and see if I can find anything--many thanks as usual :)

[were_wulff]

@mm2270 , @sepiemoini

Just to save you guys some time digging through release notes, I checked on D-009802 and it is still in an open state, so it will still be an issue in the current version of the JSS.

Amanda Wulff
JAMF Support

[mm2270]

Thanks for the update @amanda.wulff! Any ideas on when it may get addressed? That's probably asking for too much, but it can't hurt to try. :)

[were_wulff]

@mm2270 ,

Unfortunately, I don't have any sort of time line on it; even Support often doesn't know for 100% certain when/if a product issue will be in a specific release, as sometimes things happen last second prior to release and something we'd thought (or hoped) would make it in doesn't for one reason or another.
It's a big reason why Support tends to hit the release notes right away once we get the notification that a new JSS version has dropped. :)

We don't want to create a situation where there's an expectation for a product issue to be "for sure" fixed by X release then have potential disappointment if something happens prior to release that causes the fix to be delayed.

Since D-009802 is in an open state, it does mean that our Development team is aware of the issue (and that it is still an issue), so it will eventually be fixed.

Amanda Wulff
JAMF Support

[May]

Thanks @mm2270

I've finally managed to get rid of the pasteboard error with jamfhelper using your asuser approach with a couple of differences,

#!/bin/sh

LoggedInUser=$( stat -f%Su /dev/console )

icon="/private/var/tmp/AppIcon.icns"        
title="IT Notification - Update" 
jamfHelper="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper"
description="Applications need to be closed so  
Skype for Business can be updated.  
Please quit the following applications     
$safariopen  
$outlookopen  
$sfbopen  
and then click UPDATE or click LATER"

button1="LATER"
button2="UPDATE"

userChoice=$(/bin/launchctl asuser $(id -u $LoggedInUser) sudo -u $(ls -l /dev/console | awk '{print $3}') "$jamfHelper" -windowPosition ul -windowType hud -description "$description" -title "$title" -button1 "$button1" -button2 "$button2" -icon "$icon")

    if [ "$userChoice" == "2" ]; then

echo "User clicked UPDATE - hoorah"

else

echo "User clicked LATER - i am sad"

fi