Moving Beyond “Once Per Computer” Workflows

In today’s session, Bill Smith, a Jamf product expert, took a trip down memory lane to the days of Legos, Tinkertoys and Lincoln Logs. He explained how the basic interactions people have with those toys are applicable to working with Jamf Pro.

“Imagine building your own Death Star with Legos,” he said. “This is a great analogy to what we’re all doing with Jamf Pro, which is taking different-shaped pieces, putting them together and making something that’s greater than the sum of its parts.” But while Smith didn’t always have the pieces he needed to construct the elaborate toy that lived as an image in his head, he said it’s a different story today. “We’re grownups now, and we’ve got one of the coolest construction kits available.”

Much like with the construction toys of yesteryear, there are a lot of ways to build something with Jamf Pro. Smith said it’s important to remember there isn’t a single best way to accomplish something with Jamf, so admins should have confidence in their work and their methodologies.

“If a member of your team disagrees with you or one of your internal customers,” he said, “state your opinion about why you manage things the way you do and then ask him or her to counter your opinion with a better one.”

So where is a team to start? Smith recommends taking a look at naming. “In Jamf Pro, as we create various objects, they turn into lists of things.” This includes scripts, smart groups and more. “When I visit with customers, one of their most common requests is, ‘Can you help us clean up our JSS?’” Smith said the question results from an environment where a Jamf Pro server has been operational for a handful of years with people doing things in different ways.

While cleaning up a Jamf Pro server isn’t quick, Smith suggested a place to start – Categories. He explained how identifying common characteristics, and subsequently using them to make collections, will create a clean server. But these efforts shouldn’t only benefit the IT staff, Smith reminded that they need to make sense to the end users too. He offered a bit of advice. “We all learned our ABCs and 123s as kids. Those are still two pretty good systems for organizing things.”

Smith made a couple of naming suggestions:

Packages: Include the developer name, full application package name and application version.

Scripts and Policies: Name them for what they do, using verbs. Don’t name them after the computers, department or group that’s being scoped.

“Probably the most important suggestion I can offer is, don’t abbreviate. This applies to everything, because not everything has an abbreviation and not everyone abbreviates the same way,” Smith said. He continued expressing the importance of naming conventions with these tips:

Names in the Jamf Pro server should not reflect:

• what you want to accomplish,
• who you want to affect, or
• how you want to impact something.

Names in the Jamf Pro server should reflect:

• the current state of something,
• what an object does, or
• what it contains.

Once a solid and meaningful naming convention is established, Smith looked at the entirety of the device management process. “We learned as a child, we have to put away our toys. As adults, we have to accept that fixing devices, retiring them, uninstalling applications and closing tickets are all a part of the cycle of management.”

While in a JumpStart, an IT admin learns they need to: collect inventory; group machines based on inventory; and deploy settings based on groups, but Smith said there’s much more that goes into managing a Mac deployment. “Management is constant. It’s self evaluating and ongoing. Use your Jamf server as a management tool, not a task tool.”

Tying it all together, Smith said, “Much like the Death Star, Jamf Pro has one purpose. Instead of destroying planets, though, it manages devices.”