Fave Friday

I'm a day late. We're living in a topsy-turvy world and I've been spending too much time poking at my new Apple Watch. Here are some of my favorite things from this week, a week that's been keeping me up at night and making it hard to breath from the anxiety. As a doctor I feel I must prescribe some fun and cute things to make us all feel just a tiny bit better as the world changes for the worst. On to the cute!



This ultra adorable Bulbasaur planter by 3DprintJess on Etsy



And this super cute 3d-printed Oddish planter, by 3DprintJess on Etsy



Super cute crochet basket pattern by AllAboutAmi on Etsy



This absolutely genius Mac Plus style Apple Watch stand, on Amazon*



These super cute baby balaclavas, by Jenny Nicole on Ravelry



Stay strong, everyone. 💖

* I use affiliates links on this site. If you shop using this link I get a small percentage of the sale from Amazon. This helps me maintain this site. Thank you for your support!

Deleting and recreating the login keychain via Self Service

In Andrina Kelly's great JNUC 2013 talk, she included a handful of examples of how to use Self Service to give customers the ability to self-solve recurring issues. One of the examples is recreating the login keychain. Her script is on Github here. It gets the currently logged-in user, detects their login keychain, then deletes it and creates a new one. This requires the user's password, which the script prompts for using cocoaDialog.

I've wanted to get something similar going at my workplace, but I've been trying to avoid deploying cocoaDialog to machines as all of our machines already have jamfHelper and AppleScript available. It seems like overkill to install yet another dialog tool if I can get the ones already there to do what I want.

Based on my previous work (which is in turn based on Elliot Jordan's) I decided to utilize jamfHelper and AppleScript to do the heavy-lifting of prompting for the password and passing it along.

From the user's point of view, it will work like this:

They'll open Self Service, and find the Fix Keychain policy (or whatever you want to call it).


Happy Holiday Time

Hey y'all, you may have heard that some holiday of some kind is coming up soon. Whether or not you celebrate I hope you have a wonderful end of the year and enjoy some kind of festivities that bring you joy. If there aren't festivities this time of year that bring you joy, maybe these pictures of my cat Charlie in festive kitty things will bring a smile to your face.





One way to update NoMAD

Now that I have a few people "in the wild" (nomads, if you will…) using NoMAD in our environment, I needed to find a way to install updates that played nicely with the app as its running. If you install and have NoMAD create its LaunchAgent in the user Library (as opposed to the system Library) the LaunchAgent needs to be unloaded prior to running the installer for the new version. Part of the fun of this, especially if managing with an MDM like Jamf, is that Jamf runs as root while the LaunchAgent is in the user's Library. You have to tell Jamf to run launchctl in the correct user context for action to happen in the user's environment.

Fortunately for me, this is something I've been coming across quite a bit recently and have learned a few handy tricks from other Mac admins out there. I knew based on my manual updates/testing that the order of operations needed to be something like this:

  1. Unload ~/Library/LaunchAgents/com.trusourcelabs.NoMAD.plist
  2. Run installer.
  3. Load ~/Library/LaunchAgents/com.trusourcelabs.NoMAD.plist

I figured that this would be best accomplished running one script, with the script itself calling a second policy in the JSS on a custom trigger that contains the installer .pkg. 

A 10000 ft view of the workflow goes something like this:

  1. update_NoMAD.sh runs on policy1, scoped to computers with NoMAD installed.
  2. update_NoMAD.sh triggers policies using update_nomad, this policy2 contains the installer pkg.
  3. update_NoMAD.sh finishes running and at the end NoMAD has quietly closed the old version, updated, and launches the new version.

EA for detecting if a Mac has a Touch Bar



Now that we have some of the new late-2016 MacBook Pros, we want to be able to see at a glance how many of them are in a fleet. After some back and forth with Ross we came up with a relatively simple extension attribute for Jamf Pro that looks for the Touch Bar Agent as an indicator of a machine being a Touch Bar Mac.


We ran into a caveat with the above EA, though; if a machine has Touché or some other Touch Bar emulator on it the TouchBarAgent and ControlStrip will activate (regardless of the physical presence of the Touch Bar), which would skew reporting.

We went through a few ideas until Ross finally settled upon the following:


A Smart Group based on this criteria may be useful if you want to enforce any policies for the Touch Bar via Configuration Profile, or any first-run settings like putting the screen saver shortcut in the Control Strip. It could also be used to scope fun stuff to your Touch Bar Macs, like TouchSwitcher (shown above), Pac-Bar, Dino, or Touch Bar Piano. Because after all, if you're paying more for the Touch Bar you might as well get some use out of it.

Revisiting Custom QuickAdd Packages

With new Apple hardware now available on the market, I've found myself revisiting alternative methods for provisioning and re-provisioning Mac hardware. Interest in "non-imaging" provisioning methods has ebbs and flows in the MacAdmin community, and seems to be at the forefront yet again due to the reading of tea leaves and testing old workflows on new hardware that can (and might in the future) have unexpected and undesirable results. Last year I started toying with the idea of a customized QuickAdd package when it was looking like DEP wasn't a possibility at my old shop. New Macs (especially brand new hardware models) often come with forked OS builds that accommodate new features that the OS installer from the App Store has yet to include. If you buy a new machine, then wipe the shipped OS and install your own (or even delete the entire drive and all partitions), you may find yourself gambling when you don't need to.

Anyway. I'm not here to stern-parent-stare you, other people can do that. ಠ_ಠ

Back to the QuickAdd package.

So the build of the QuickAdd package changed slightly with JSS/Jamf Pro version 9.9, which included a new location of the jamf binary to behave well with recently-added SIP restrictions. Jamf also changed around the components of the QuickAdd package and binary installer. As of 9.96, it looks something like this:



Because of the binary moving to /usr/local/, the  postinstall script in the QuickAdd package is slightly different as well.

Fave Friday