Skip to main content

In short I have coupled the Deploying an OS X Upgrade workflow with the displayMessage.sh shell script to encourage the users in our environment to upgrade to OS X El Capitan.



Below, you’ll find the workflow in a little more detail.




  1. Clients not already upgraded to OS X El Capitan (10.11.x) or with the Install OS X El Capitan.InstallESD.dmg already locally cached, will be included in the OS X El Capitan Needed (Not Cached) smart group.


  2. The "Install OS X El Capitan.InstallESD.dmg" policy will run at next check-in, once per computer to aforementioned scope and then run a JSS inventory to update the system that this policy has run successfully.


  3. The client will now fall into scope for the OS X El Capitan Needed (Cached) smart group.


  4. This first triggers the "Display Message: Ready to Install OS X El Capitan" policy which simply alerts the user that the update is available in Self Service. The policy will not complete until the user hits OK at which point Self Service is launched and the "Install OS X El Capitan" policy will be featured on the main page. Those who do not update from Self Service, will continually see the message once a day until they are no longer in the scope.


  5. The installation will begin and prompt for an immediate reboot.


  6. Once the installation has completed, an inventory update will post to the JSS and the locally cached installer will be removed.






Issue:



Step 4 seems to be where the hiccup occurs. Specifically what I am noticing is that clients that fall into scope are posting the following error.





The failed policy does not show the message but does open Self Service. This suggests to me that the issue lies with the script itself which has been used in other applications within our environment with no issues. Please have a look below to see how this particular script is being utilized for this specific policy.





Has anyone seen this error before?

The problem is that the script uses a straight Applescript call (osascript) to call System Events to display a message. The error message "An error of type -10810 has occurred." means the script tried to do something as the logged in user while running from another account, like root. Back in the day on older OSes like the one this script was designed on, that was never a problem, but Apple has made it harder with each version of OS X to do this. If you look at the portion of the script that calls the message up, if you chose to background the message, it uses jamf displayMessage, which doesn't run into the same problem. Since you're choosing the interactive method, its trying to use the osascript call and its failing. The OS is stopping it from displaying the message because that osascript command isn't being run as the logged in user.



Looking at the script, I'm unclear why JAMF chose to use 2 possible messaging methods. Its not hard to call jamf displayMessage and have it wait for input before continuing. There's no need for an Applescript window for that, so I'm not sure what the original thinking was for that.

Thanks for the input, @mm2270!



It appears that the issue lies between lines 119-125 of the original script (copied below).



case $background in "true" | "TRUE" | "yes" | "YES")

        echo "Displaying backgrounded message to user..."

        /usr/sbin/jamf displayMessage -message "$message";;

    *)

        echo "Displaying message to user..."

        osascript -e 'tell application "System Events" to display dialog "'"$message" -e '"buttons {"OK"} default button 1';;

esac


If so would simply adjusting the path which is referenced fix this?



/usr/local/bin/jamf -message "$message"

@mm2270 I am thinking about ditching this approach and going with deferral messages instead.




  1. OS X Installer is locally cached at recurring check-in and is scoped to a specific smart computer group--those without the specified OS X version and without the installer already cached.

  2. Once cached and completed, a second smart computer group is used (those with this specific installer cached) is used to publish the below messages at next log-in.

  3. The user selects a time that best fits their schedule and the installation begins.






What're your thoughts on this approach?

@sepiemoini Looks like it makes sense. At least its one of many possible approaches. I'm sure everyone here has some specific method of doing this, but I don't see any issues with the above.
In fact, we actually do something similar. as in caching the OS installer in one policy, then targeting the group with that installer cached to send up messages that their OS upgrade is ready. The main difference for us is its still user driven from Self Service, or via a button in the jamfHelper message mentioned earlier. So we don't force them to choose a time to run it. Other than that its a similar approach and it works well for us.

@mm2270 Oh nice! Do you mind going into more details about the jamfHelper approach? I think a more friendly, user-driven process would be worth investigating.

@sepiemoini There isn't a lot to detail, as far as the jamfHelper route. The images you posted above are from jamfHelper and are somewhat similar to what we display (although not with the hud window style)



What we do is split it up into 2 policies. for AM and PM. We have each one run once per day and limit the timeframes for each one to either the AM hours or the PM hours, so the clients get a message on screen 2 times per day maximum that their OS X upgrade is ready to be run. This all takes place after the installation is cached on their Macs from a separate policy.
We have a Self Service policy that the user can run that kicks off the installation, or they can click on a button in the message I mentioned that simply runs a trigger to call the install policy. Either way its running the same thing though.



Does that make sense?

@mm2270 Totally! The workflow that I wanted to use utilized the deferral feature which apparently is a known JAMF Software product issue (PI-002338) for this particular error :(



Once cached, the user will receive a message at login, once per day that the upgrade policy is available in Self Service. When they dismiss the pop-up message that they receive at log-in, Self Service opens as an execute command. Regardless of whether or not the upgrade is performed, the policy will show as complete. This isn't a problem per se because both smart computer groups* used will add this computer back into scope to receive the cached installer and then re-run this process at their next eligible login.



*The "not cached" smart computer group has an additional line right now which points to a test machine. Once fully tested, this line will be removed to target specific departments or teams.





Terms & ConditionsCookie settings