jamfHelper full screen from Self Service


I recently began testing a script that calls jamfHelper in full screen mode, this time as a Self Service policy. The script behaves normally except when executed from Self Service. The full screen window will not disappear, but I can manually dismiss it via Command+Q on the machine itself.

Am I missing something here? I have tried killing jamfHelper every JAMF documented way, and also via kill -9 <pid> and killall -m jamfHelper. Nothing works except Command+Q. The script is a modified version of the Apple Software Update helper script created by lisacherie.



For anyone else's benefit, the following works every time:

sudo ps axco pid,command | grep jamfHelper | awk '{ print $1; }' | xargs kill -9

View solution in original post



When the jamfHelper application is loaded in full screen mode (fs) it uses the System Events application to prevent user interaction with the environment behind the display of the computer "lock down." I'd give sudo killall jamfHelper System Events a try and see if that works for you.



After a bit of trial and error, the only thing I found that would kill it is sudo kill -9 <pid>. It didn't work previously in a script, so I'll have to figure out what's wrong with the script. Thanks!


For anyone else's benefit, the following works every time:

sudo ps axco pid,command | grep jamfHelper | awk '{ print $1; }' | xargs kill -9

New Contributor III

I think the Full Screen helper can be quit with command + q on 10.7 and 10.8

We used to use this to lock the screens of the machines but people can quit it now.

New Contributor II

I came across this post while dealing with a similar challenge.

We wanted to administratively lock certain Mac clients when they returned to our network and thought JAMFHelper would be a good way to do it. The other choice was to use the MDM screen locks, but they appeared to be geared more to one-off situations and we were looking to target a smart group.

The problem with JAMFHelper was the CMD+Q element. Using a full screen takeover that the user could back out of wasn't going to be effective. After confirming JAMFHelper was behaving as expected, we figured out a way to use the "LockScreen.app" from Apple Remote Desktop to harden the policy.

Here's the script to "lock" the client as well as another script (using Stephen Grall's concise JAMFHelper killer) to unlock them. I should also note the super nice coding format was borrowed from my esteemed teammate Pat Norton :)

To lock a Mac Client

#Machine is not bound - Lock HUD

#INVOKE ARD's Lock Screen and move on to the JAMF Helper
/System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app/Contents/MacOS/LockScreen &

echo "This computer has been locked by Mac Support"

#Fill in the variables to customize your message

#Window Title

#Window Heading
heading="This computer has been locked by COMPANY'S IT"

#Window Message
description="This system is owned by COMPANY, is on the COMPANY network but is not bound to our domain.

Please call the COMPANY help desk at 555-5555 to have this computer unlocked and bound."

#command below makes the window and stores the value in $userdecision
if [ -d /Library/Application Support/JAMF/bin/jamfHelper.app ]; then
userDecision=`/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType fs -title "$title" -alignHeading center -heading "$heading" -alignDescription center -description "$description" -icon /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/Lock.jpg -lockHUD -startlaunchd`

echo "Could not find jamfHelper.app"
exit 0

#This is the result of the takeover screen
echo "$userDecision"

To unlock a Mac Client

#unlock a machine with jamfhelper takeover

#stop the JAMF Helper

ps axco pid,command | grep jamfHelper | awk '{ print $1; }' | xargs kill -9

#stop the LockScreen app

ps axco pid,command | grep LockScreen | awk '{ print $1; }' | xargs kill -9

echo "This computer has been unlocked by Mac Support"

Hopefully this one-two combo helps someone else along the way. It goes without saying that you should test it in your own environments first ;)

Contributor III
Contributor III

@Janowski I was able to achieve the killing of the Lock Screen and JAMF Helper in a much simpler way.

#Kills the Lock Screen pocess.
killAll LockScreen

#Kills the JAMF Helper pocess.
killAll jamfHelper

New Contributor II

Yeah... I've learned a few things in the last couple years and would probably do this differently now. Using the command pgrep would be where I start now. If you're not familiar with that command, it's worth checking out ;)


Just wanted to add to the mix. For anyone who is as verbose as I am, the most frustrating thing about jamfhelper is the lack of options for formatting. We did a lock screen message for a computer that was checking in still, logged in as a former employee, and was missing from inventory. But we couldn't get it to say what we wanted to say about remediating without going over the limited constraints of jamfhelper's -fs option.

... until we figured out we can mock up any message, with any format, pictures, colors, dancing clowns... whatever, in Pages, export it to a .png or .jpg, and forgo all other settings (-heading -description - title) in lieu of just using the flags:

-icon [/path/to/mockup] -fullScreenIcon