Jamf Pro Reporter: a Slack Webhook to help keep track of Mac deployments

As the number of Mac deployments began to ramp up at my work it became apparent to me very quickly that I needed an easy way to keep track of what was being built, and when. As we began having more Macs built in different timezones, it became harder for me to quality check each new Mac setup.

I also wanted to make sure that there was greater visibility in regards to failed Mac builds, beyond relying on emails from the JSS about failed policies. So I decided to create a Slack ‘Jamf Pro Reporter’, to post to a team ‘client computing fyi’ channel at the end of every Mac build. The post would be a summary of the kinds of things that I want to make sure we got right – does it have the correct computer name? Is the username of the primary user of the Mac correct? Is FileVault encryption enabled and is the primary user a FileVault enabled user? Is the Mac successfully connecting to the corporate wifi?

I also wanted there to be a clear green/red visual cue if the deployment was successful or not. The final product looked something like this:

A successful Mac build 🙂
An unsuccessful Mac build :’-(

Steps to creating JamfPro Reporter:

Open api.slack.com/apps and click Create an App
Give your app a name
Give your app a nice looking icon
Go to Features > Incoming Webhooks > and toggle this feature on
Select the channel you want this webhook to post to. I suggest you start off posting to Slackbot first, as that way all your testing will be visible to you only, before moving to a shared team channel
Copy the Webhook URL – going to need it for the script below!

That’s all that’s required on the Slack side of things, and now you just need to create a new JSS script that will be the policy payload to be run at the end of each completed Mac setup.

To post to Slack from a bash script is straightforward enough – just a single curl command to the webhook URL that Slack provided us above.

curl -sk -d payload=”$JSON” “$WEBHOOK_URL”

The trick is getting the JSON string that you are sending through to include all the correct parameters. Slack provides some good formatting tips but the basic post that I went with uses the following JSON content:

{

“text”: “<title of post>” ,

“attachments”:

[{“thumb_url”: “<post image url>”,

“color”: “<color of left border line>” ,

“text”: “summary text, with all quotes and single quotes escaped”

}]

}

The color is defined by the word “good” which gives us a green left-border, or “danger” which gives us the red.

The script preceding the curl command is just getting all the values that we want to include in the summary text, and making the checks that we need to confirm if the color attribute should be a “good” or “danger”:

Just like how the color attribute is defined by whether any issues were encountered, we could do the same with the image link – so that there is a happy/sad Mac image based on the result, making failed deployments even clearer. Another way to make failed deployments clearer is to add an @here to the text (if your team’s Slack etiquette allows that is).

I think I could also improve the script by including more extensive post-deployment testing to the script – such as a confirmation that the relevant security agent processes are running, and validating that the username of the account that is created actually exists in AD.