Run Script After Enrollment

nvandam
Contributor II

Using a DEP prestage enrollment, I'm trying to get the following script to kick off right after the user is at the desktop. If I scope a policy to trigger at "Enrollment Complete", the policy is being triggered for user "_mbsetupuser" and the JAMF Helper dialogue box opens up in the setup assistant rather than at the desktop. If I use "Login" as the trigger, the JAMF dialogue box opens at the desktop, but clicking "Log Out" doesn't cause the logout to occur.

EDIT: I should add that I've scoped the policy to Self Service and manually ran it. It works as expected that way.

I am a novice when it comes to scripting. The base script I'm using is something I found on JAMF Nation.

!/bin/bash

jamfHelper="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper"
windowType="hud"
description="To begin FileVault disk encryption of your Mac, you will need to log out and log back in. Please save any work and click 'Log Out'. You will automatically be logged out in 5 minutes."

button1="Log Out"
button2="Cancel"

icon="/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/AlertNoteIcon.icns"
title="Configure FileVault Encryption"
alignDescription="justified" alignHeading="justified"
defaultButton="1"
timeout="300"

JAMF Helper window as it appears for targeted computers

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

If user selects "Log Out"

if [ "$userChoice" == "0" ]; then sudo kill -9 pgrep loginwindow exit 0
fi

1 ACCEPTED SOLUTION

davidacland
Honored Contributor II
Honored Contributor II

It might be the syntax for logging out. Scripts from the JSS run as root so sudo shouldn't be needed.

You could also try

if [ "$userChoice" == "0" ]; then
osascript -e 'tell application "System Events" to log out'
exit 0
fi

View solution in original post

6 REPLIES 6

davidacland
Honored Contributor II
Honored Contributor II

It might be the syntax for logging out. Scripts from the JSS run as root so sudo shouldn't be needed.

You could also try

if [ "$userChoice" == "0" ]; then
osascript -e 'tell application "System Events" to log out'
exit 0
fi

nvandam
Contributor II

Removing the sudo resolved it.

Also, I have tried using osascript -e 'tell application "System Events" to log out', but the problem there is that it only opens the log out window, but the user can then cancel that. This way just logs out right away.

Thanks!

mm2270
Legendary Contributor III

It's just my opinion, but I wouldn't do a kill on the loginwindow if I were you. That's a brute force ugly way to accomplish it. It's a little like force rebooting your Mac to do a restart. Sure, it restarts the system, but it's not the most gentle approach.

In case it helps, here is some code I've used to do logouts as the user which does a real logout, not just killing the loginwindow.

The below should work on 10.10.x through 10.12.x, though I can't say I've tested it against Sierra, so I don't know for sure. I assume it should work though.

#!/bin/sh

## Get the logged in username
loggedInUser=$(stat -f%Su /dev/console)

## Get the logged in UID
loggedInUID=$(id -u $loggedInUser)

## Do logout as the user
/bin/launchctl asuser $loggedInUID sudo -iu $loggedInUser "/usr/bin/osascript -e 'ignoring application responses' -e 'tell application "loginwindow" to «event aevtrlgo»' -e 'end ignoring'"

Just a quick note on the «event aevtrlgo» This is Applescript speak for "do event 'Apple event really log out'" It doesn't bring up the logout confirmation window. It just starts an immediate logout. Throwing in the 'ignoring application responses' ensures the event won't care if an open app complains. It just continues with the logout. I don't think that part is really necessary for a post enrollment script, but it's better to have it in there, just in case.

Hope that helps.

kquan
Contributor

I'm having an issue where if I setup a brand new computer, this _mbusersetup is getting policies intended for my "admin" account.

https://www.jamf.com/jamf-nation/discussions/24237/dep-w-10-12-5-done-from-internet-recovery-account-creation-issue

still can't figure out how to stop this _mbusersetup account from getting policies on DEP before I can create my account

kevinwilemon
New Contributor III

@kquan I'm battling the same issue with the _mbusersetup during prestage.

The conversation over at https://www.jamf.com/jamf-nation/discussions/23542/how-are-you-deploying-new-mac-laptops#responseChild142625 may be helpful for you, though. Namely @chriscollins lists a workflow that should solve for this. I haven't been able to reach him for my questions about it, but what he has already posted may be able to help you.

gachowski
Valued Contributor II

So not a direct fix for your issue, but after our machines are enrolled (DEP) and the user is logged in this is how we get the user name

SN=`ls /Users | grep -v Shared | grep -v .localized | grep -v _mbsetupuser |grep -v .DS_Store`

When including time from log in It's the most "reliable" and the fastest way to get the user name.

We used this when were binding to AD too.

C