Standing on the Shoulders of Giants
-or-
What I've Stolen from JNUCs Past
"If I have seen further it is by standing on the shoulders of Giants." ~Isaac Newton[1]
Cover photo by: Iris Vallejo (Witizia on Pixabay)
About This Presentation
The first time I worked with Jamf was in 2009. I had just starting working with a consulting company and my first client was a school district that used Jamf Pro (fka Casper Suite) to manage all their Macs.
I attended my first Jamf 300 (fka Casper Certified Administrator) course a few months later in February of 2010. Later that year I attended the second JNUC (my first) in the fall.
Those first JNUCs were full to the brim with new ideas and skills I could take home and help my coworkers and/or clients. And every JNUC has had at least one "Ah-ha!" moment since.
Aside from the first one in 2009 and the one 2012 which I missed to a family emergency, I've managed to attend all the others. This year marks my 10th JNUC and I'm happy to be presenting.
Over the years I've taken the things I learned at JNUC and tweaked them, updated them, and (dare I say) improved upon them from time to time. And I've leveraged them to solve problems from past jobs through current clients. And I wouldn't have been as successful were it not for the presenters of JNUCs past who shared their wisdom so freely.
So this year's presentation is meant to call out a handful of presentations that have meant the most to me and to show how I've used them and share the little "pearls of wisdom" that have come out of them.
Getting Your Users to Do Your Job (Without Them Knowing It)
To this day Andrina's presentation in 2013 remains one of my favorites. While her 'gimmick' (no spoilers) definitely made it memorable, it was the content that pushed it ahead of the pack. I had two big takeaways:
Basic Troubleshooting
The old trope of "have you tried turning it off an on again" is ubiquitous in the technology world. Mostly because... it works! But there are a lot of reasons people never choose to reboot like time and inconvenience. And then they call us when things go wrong and we ask them to reboot and they balk it.
But what if we gave them a magic button they could push to fix most computer problems! That's what this policy does.
And since the reason people keep skipping software updates is because it wants them to reboot... let's install those while we're at it.
Make Me An Admin
The year that Andrina gave this talk presenting her solution for granting admin rights on a *temporary* basis and automatically taking it back, I was working at a manufacturing company with this exact need. It was the perfect solution at the perfect time.
Over the years, I've implemented a version of this for almost every client I've ever had. Yes. The need is that ubiquitous.
I'm far from the only person to do something like this. In fact, in her presentation Andrina cites Kyle Brockman's script in a Jamf Nation Discussion as the inspiration for her own workflow. Jamf's own GitHub page has a version as well.
As of this writing, our version has a few additions to make it modular enough to drop it into a client's Jamf Pro server and shape the functionality with script parameters in the policy that drives it.
The link to the most current version can be found on our GitHub page along with additional documentation.
Add Pop and Practicality with a Clean User Interface
Arek Sokol and Jason Borchardt - 2014
In their presentation, Arek and Jason each hit a key point for me.
Arek started with a discussion on how to approach the process. He emphasized starting with thinking about the what and why but also the who and considering exactly how your interaction will be perceived by your people.
One of the biggest challenges I've faced over the years comes from two places:
Signal/Noise - We are bombarded with so many notifications and pop-ups on a daily basis and we have so many windows/tabs open at any time that it's hard to find a way to get the attention of our people and get them to take action.
Security - A lot of us have spent so much time getting people not to click on every single thing that pops up that now we have to work even harder to get them to get them to click on the right things.
He also discussed "TIMTOWTDI" or "There is more than one way to do it."
I also follow the philosophy that says,
"I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail." ~Abraham Maslow
As such I try to keep a number of tools in the box, as it were.
Arek provided the following list of tools for developing a GUI interface:
AppleScript
jamfHelper
CocoaDialog (deprecated)
terminal-notifier
Xcode
Python
Sadly, cocoaDialog is gone. Xcode not only has a higher learning curve, but then you have to distribute the files. And I find the builtin GUI libraries for Python annoying and to use better ones requires either distributing those libraries or "freezing your code" and distributing the file(s).
So I find AppleScript and jamfHelper to be the best built-in tools for daily use.
But if you saw my presentation last year, "Beyond Step Three or The Magic of Endpoint Provisioning," you'll know that I really like using DEPNotify in onboarding workflows to keep people informed throughout the process.
Thinking Outside the Apple Crate
This past summer found me with a unique challenge for a client. In the past they held in-person workshops for new computer deployment. With everyone working remote, these moved virtual.
After initial introductions and a summary of the process, each person would start their computer going through the onboarding workflow. If we were in-person it would have been easy to keep an eye out on where everyone was in the workflow.
But in a virtual setting? Even though the intro had included a series of slides and screenshots on what to expect, the first workshop turned into a constant stream of overlapping voices asking for help and asking the same questions over and over. And worse, some people who had problems didn't say anything and just sat waiting! The entire workshop was scheduled for one hour but ran for close to two hours.
There had to be a better way!
I ended up (subconsciously, perhaps) following Arek's advice on stepping back and thinking about the who and the why to guide your tool selection. I decided to leverage Jamf's webhooks and a few external tools:
Integromat - An automation system like IFTTT or Zapier to connect web services together
Airtable - A cloud-based database service
Slack - The ubiquitous and easily extensible team chat service
Now whenever a computer finished a policy in the workflow , it would send a webhook to my Integromat scenario which would check the policy ID and, if it was on the list of onboarding policies, create or update a record in Airtable indicating the current step of the workflow they were at with the time, and send a message to me in Slack.
So at the remaining workshops I was able to keep an Airtable window open to see the total "scoreboard" and Slack became my own personal announcer. I was able to say things like,
"I see Alice has reached step five. You should be getting a request for your username and password."
"Bob, it looks like you've been stuck on step eight for a while. Are you seeing any error messages?"
"It looks like Mallory just finished the whole process. Unless you have any questions, you are free to go."
I announced each person reaching a new step like I was calling at a racetrack which kept the mood a lot lighter as well. We were done with time to spare.
Moving Beyond "Once Per Computer" Workflows
Bill (aka Talking Moose) actually has two slots on my top ten JNUC presentations list. The other is his 2019 presentation, "Who's Afraid of the Command Line? — Taking the Mystery Out of the Terminal and Scripting."
But today I’m talking about his presentation from 2017.
Bill had a lot of great advice. Much of which I still quote during JumpStart training sessions. Including, but not limited to:
Develop an opinion about why you do the things you do
And be prepared to back it up
Choose naming schemes for things (categories, policies, packages, etc.) that tell you what they are for at a glance.
Document everything!
Let's start with documentation. With the obvious (and odd) exceptions of groups and policies, you can add descriptions/notes to just about every object in Jamf. So why not:
Add a note to each package on how you made it or where you got it
Provide a nice, clean summary of what a script does
Explain what security guidelines a configuration profile provides
Sure, there is a history button at the bottom that will show when an object was created or edited and by whom, but that's only good for as long as your log flushing settings provide. And while you can get some details from most objects, it doesn't highlight exactly what changed. So for the sanity of your co-workers and/or the admin that comes after you, please document things when you make them. At the very least, think of one of the most important people on your team: the you six months from now. Once that history rolls over and you are staring at a screen wondering what past you was thinking, you'll wish you had.
And it's a good habit in other aspects of your life as well. For example, my wife and I love cooking dinner together. We use a recipe manager on our iPads to plan meals and grocery shopping and coordinate cooking. And every time we try some twist, we add a note to our future selves. The other night I found this thread in the recipe:
Dear Future Ruth and Chad, Use the cast-iron skillet for this. We tried with the other deep pan and it wasn't quite right. Love, Ruth and Chad June 3rd, 2018 Dear Past Ruth and Chad, You are very wise. It’s like you knew we weren’t sure which pan to use! 😎 Love, Ruth and Chad January 5th, 2020
Now let's talk about naming and taxonomy.
At Rocketman, the names of all our smart and static groups start with either an "S:" or "M:" to indicate if they are there for (S)cope or (M)onitoring respectively. That way we know at a glance what their purpose is. We have a Python script we use to perform ongoing health checks of our clients servers. One of the blocks of the report lists all groups that aren't being used in any policies or configuration profiles.
So if a group name on that report starts with "S:" it has likely been orphaned along the way and can be deleted. But if it start with "M:" it may be pinned to someone's dashboard.
I really liked Bill's suggestion of creating smart groups to indicate the way things should be and then create policies that are scoped to "All Computers" excluding those that are already in that group.
For example, a smart group might be called "Has Google Chrome" and a policy that deploys Google Chrome would be scoped to all computers excluding the ones that have it.
But here's where I have a different opinion. ...and I'm prepared to back it up.
Don't get me wrong. I like the philosophy of choosing to always look on the bright side of life, but what if I flip it instead. What if I have a smart group called "M: Needs FileVault" and I pin it to my dashboard? And maybe a few other smart groups looking for trouble?
Now when I log into Jamf, I (hopefully) see a row of little zeros across the top. And, if not, I can click on the non-zero numbers and see who is non-compliant.