Script not running properly.

[ChrisTech]

I am trying to get a script working for Prestage Enrollment. It's supposed to pop up a window where you can enter the asset tag. Works when I use a custom trigger from the terminal, but not recurring check in or on enrollment. When run during enrollment, the window never pops up so not able to enter anything in and it goes ahead and binds with whatever the computer is named.

Script:

#!/bin/sh
/bin/sleep 60
computerName=$(osascript -e 'Tell application "System Events" to display dialog "Please enter computer name and click Submit:" default answer "" buttons {"Submit"} with icon caution' -e 'text returned of result' 2>/dev/null)
/usr/sbin/scutil --set ComputerName $computerName
/usr/sbin/scutil --set LocalHostName $computerName
/usr/sbin/scutil --set HostName $computerName
echo "Computer name has been set..."
/usr/bin/yes | /usr/sbin/dsconfigad -add xxxx.xxx -u username -p password -groups "XXXXComputer Technicians,XXXXDirector of Information Systems,XXXXIT Engineers" -computer ${computerName} -shell /bin/bash -ou "CN=Computers,DC=xxxx,DC=xxx"
echo "Binding to AD"
/bin/sleep 30
dscacheutil -flushcache
echo "<result>`scutil --get ComputerName`</result>"
jamf recon
exit 0

[DBrowning]

Try adding /bin/launchctl asuser 0 before calling osascript...

computerName=$(/bin/launchctl asuser 0 /usr/bin/osascript......)

[ChrisTech]

Tried that. Same result. I don't know why I am not getting the popup window with the prompt.

[mroe]

I've been having the same problem with our newer batch (2018's) of macs. The script I use is almost identical, except there is a separate policy that binds to AD after running jamf policy from terminal. I haven't found a fix yet, but I have noticed that if trying to run the script via terminal manually there is a syntax error that claims there is an ^m at the end of #!/bin/sh. This ONLY happens on our new macs that shipped with Mojave. Anything that came with High Sierra or lower works fine, both automatically after pre-enrollment and manually. Copying the body of the script (without the #!/bin/sh) into terminal also makes it work normally on Mojave. Throwing the script into self service shows that the script executes, but nothing happens. This makes me think that Mojave has an issue with handling shebangs correctly. At least out of box. I still haven't come across anyone else having problems with mojave running scripts with shebangs though so I'm at a complete loss.

[isThisThing0n]

Run your osascript as the logged in user not as root.

variable for storing the current users name

currentuser=stat -f "%Su" /dev/console

Is this Mojave? Have you setup the appropriate permissions for osascript to access system events?

Also the enrollment complete trigger is not reliable. Especially if this is DEP as it triggers during setup assistant and will not display osascript.

[DBrowning]

Here is the rename script that I use today with our automated enrollment and it works perfectly on 10.13.x and 10.14.x. We don't join the domain, so I can't help with that piece.

#!/bin/sh

nameCode=`/bin/launchctl asuser 0 /usr/bin/osascript <<EOT
set office to {"CA", "AZ", "CT", "GA", "IN", "KS", "NY", "PA", "TX-Austin", "TX-Dallas", "UT", "VT", "Loaner", "Other"}

set choice to (choose from list office with prompt "Please select the State that best describes your location")
set city to the result
set code to city as text

if (code = "GA") then
    set nameCode to "ATL"
else if (code = "VT") then
    set nameCode to "BUR"
else if (code = "NY") then
    set nameCode to "NHP"
else if (code = "TX-Dallas") then
    set nameCode to "DAL"
else if (code = "TX-Austin") then
    set nameCode to "VAA"
else if (code = "CT") then
    set nameCode to "GRO"
else if (code = "CA") then
    set nameCode to "MIS"
else if (code = "UT") then
    set nameCode to "SLC"
else if (code = "PA") then
    set nameCode to "EXT"
else if (code = "KS") then
    set nameCode to "KCS"
else if (code = "IN") then
    set nameCode to "CAR"
else if (code = "AZ") then
    set nameCode to "PHO"
else if (code = "Loaner") then
    set nameCode to "Loaner"
else
    set nameCode to "Other"
end if
EOT`

sn=$(system_profiler SPHardwareDataType | awk '/Serial/ {print $4}' | cut -c 5-)
model=$(system_profiler SPHardwareDataType | awk '/Model Name/ {print $3}')

if [[ $model == "MacBook" ]]; then
    modelCode="L"
else
    modelCode="W"
fi
os="mac"

if [[ "$nameCode" == "VAA" ]] || [[ "$nameCode" == "Loaner" ]]; then
    echo "Prompting for Computer Name"
    computerName="$(/bin/launchctl asuser 0 /usr/bin/osascript -e 'display dialog "Please enter Computer Name:" default answer "VAA-USERNAME-LT1 or lBURmacLoaner01" with title "Computer Name" giving up after 86400 with text buttons {"OK"} default button 1 ' -e 'return text returned of result')"
else
    echo "$nameCode was chosen"
    echo "Use standard naming convention"
    computerName=$modelCode$nameCode$os$sn
fi
    echo "computerName has been set to: $computerName"

networksetup -setcomputername $computerName
scutil --set LocalHostName $computerName
scutil --set HostName $computerName
sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server NetBIOSName $computerName

[DBrowning]

Also, @oliverr brings up a very good point, I also have a PPPC profile that allows osascripts access to system events and jamf to call osascripts.

[stevewood]

You could also deploy cocoaDialog and use that for your dialogs instead of osascript. I've been using it for pop-up dialogs during our provisioning, both Self Service initiated and Pre-Stage initiated via an Enrollment Complete trigger, and we've had no major issues. Been using this for well over 18 months now.

There's an example template on my GitHub: Naming Template

That does more than you want, but you could just clip out the bits you need and add in the binding piece. For a few of our agencies that do bind to AD, we use a policy to bind and not the dsconfigad call in the script. So we just call a policy from the script.

[mm2270]

Try this:

#!/bin/bash

LoggedInUser=$(stat -f%Su /dev/console)
LoggedInUID=$(id -u "$LoggedInUser")

computerName=$(/bin/launchctl asuser "$LoggedInUID" sudo -iu "$LoggedInUser" /usr/bin/osascript -e 'Tell application "System Events" to display dialog "Please enter computer name and click Submit:" default answer "" buttons {"Submit"} with icon caution' -e 'text returned of result' 2>/dev/null)

echo "$computerName"

The main reason you're not getting the dialog pop up is because when the jamf binary runs it using the check-in process, that gets called by a LaunchDaemon, which = root. The macOS will stop dialogs like that from popping up for the currently logged in user, unless the window is called by them, not by some other account, like root. The above will use launchctl asuser to call the osascript command as the logged in user, which usually works. Give it a try and see.

BTW, this is a very very common problem. If I had a dollar for every time someone asked a similar question here... well, I'd have a lot of dollars!

[ChrisTech]

Thanks guys. Especially @mm2270 . I had a feeling it was because the script was running as root. I've had a similar issue in the past and I had to run the script as the logged in user. My only issue now is when running recon at the end of the script the JSS doesn't update the computer name for the record. I did a recon when all the scripts were done running and it updated the name. I'm trying to get us off of traditional imaging and this is a step in the right direction!

[djdavetrouble]

I was doing something like this, and am now using depnotify to capture form values on provisioning, it has been amazing..

[mm2270]

Have you tried adding another sleep command to the script before the recon? It may be happening too quickly to pick up the rename.

The other thought I had on that is, if this script is being run via an overall policy as I suspect, you could remove the recon in the script and just let the policy collect inventory at the end using the built in Maintenance payload option. That might work out better for you.

BTW

I'm trying to get us off of traditional imaging and this is a step in the right direction!

Yes, you and everyone else! (who hasn’t already tackled it anyway)