Zero-Touch macOS Enrollment with JAMF Setup Manager: A Practical Walkthrough

Sun, 05 Apr 2026 00:00:00 +0000

If you’re trying to streamline macOS deployments in JAMF, there’s always that moment where you realize: the built-in experience gets you close, but not all the way there. That’s where JAMF Setup Manager comes in. This is one of those tools that feels immediately familiar if you’ve used something like DEPNotify, but it takes a slightly different approach. Instead of building everything from scratch, you’re working with a structured, JAMF-native workflow that lets you deploy a polished enrollment experience using just a package and a configuration profile. Let me walk you through how I set this up and why it’s been such a solid addition to my workflow. What JAMF Setup Manager Actually Solves At its core, JAMF Setup Manager is about creating a controlled, user-friendly zero-touch enrollment flow. You’re defining what happens during provisioning, how it looks, and what actions run—without having to stitch together a bunch of scripts and UI components yourself. The biggest takeaway is how simple the deployment model is: One package One configuration profile That’s it. Once those are in place, everything else becomes about how you scope and structure the workflow. We will be referencing the quickstart for this setup. Getting the Package into JAMF The first step is getting the Setup Manager package into your JAMF environment so it can be deployed during enrollment. Start by downloading the latest release of the Setup Manager package from the project’s GitHub releases page. This will typically be a .pkg file. Once downloaded, upload the package into JAMF Pro: Log into JAMF Pro Navigate to Settings → Computer Management → Packages Click New Upload the .pkg file you downloaded Save the package At this point, the package is now available inside JAMF and can be used in policies or PreStage enrollment. From a workflow perspective, this package is one half of the deployment model. It provides the actual Setup Manager application that will run on the device during enrollment. The next step is associating this package with your PreStage enrollment so it installs automatically when a device is provisioned. Scoping - An important step This is where most of the complexity lives, and honestly, it’s the part you want to get right the first time. I always like to start scoping by creating the groups and criteria first so that when I create the profile its easy to add the scope and the exclusion. You need two key groups: A PreStage group that targets devices during enrollment An Enrollment Complete group that removes the profile when you’re done The PreStage group is typically based on the enrollment method. If a device is enrolled via PreStage, it gets the profile. Simple. The tricky part is making sure the profile doesn’t disappear too early. If it vanishes before your workflow finishes, you’ll end up with a broken or incomplete setup experience. So you need a clean way to remove it only after everything is done. What I do is use a custom attribute that checks for a file-based signal indicating completion using a computer extension attribute written by Alectrona. Once that condition is met, the device falls into the “Enrollment Complete” group and the profile is removed. #!/bin/bash # Automated Enrollment Workflow Status # This attribute reads a breadcrumb to determine if the computer has completed the Automated Enrollment Workflow or not. # Created by Alectrona for use with https://github.com/alectrona/automated-deployment completionBreadcrumb="/Library/Application Support/Alectrona/com.alectrona.AutomatedEnrollment.plist" result=$(/usr/bin/defaults read "$completionBreadcrumb" Complete 2 /dev/null) # If the breadcrumb reads false then return incomplete, and true means complete if [[ "$result" == "0" ]]; then echo "

Discovering Mole: A Command Line Utility for Mac Cleaning

Fri, 03 Apr 2026 00:00:00 +0000

If you manage or use Macs long enough, you know one thing is guaranteed: systems get messy. Caches pile up, apps leave behind junk, and disk space slowly disappears. While there are plenty of GUI tools out there, most of them either lack transparency or feel bloated. Mole is different. Mole is a lightweight, command-line utility built specifically for macOS that gives you clear visibility and control over what’s consuming space—and what can be safely removed. For MacAdmins, developers, and power users, it fits perfectly into existing workflows. Why Mole Stands Out Mole isn’t just another cleaner. It’s designed with a few key principles: Transparency first — see exactly what will be removed Safe by default — dry-run support prevents accidental deletion CLI-native — perfect for automation and scripting Focused on macOS realities — understands app leftovers and system clutter Installing Mole The easiest way to install Mole is via Homebrew. brew install mole After installation, verify it’s working: mole --help Running Mole At its simplest, just run: mole This launches Mole’s interactive interface, where you can explore cleanup options, system insights, and uninstall tools. Safely Cleaning Your Mac (Dry Run First) Before removing anything, you should always start with a dry run. This lets you preview exactly what Mole will clean without making changes. mole clean --dry-run This is critical for: Validating what will be removed Avoiding accidental deletion of important files Understanding system clutter patterns Here’s what it found when I ran the dry run option. Clean Your Mac Dry Run Mode, Preview only, no deletions ◎ System caches need sudo, run sudo -v '' mo clean --dry-run for full preview ⚙ Apple Silicon | Free space: 184Gi ✓ Whitelist: 21 core patterns active ↳ /Users/jon/Library/Caches/ms-playwright* ↳ /Users/jon/.m2/repository/* ↳ /Users/jon/.gradle/caches/* ↳ /Users/jon/.gradle/daemon/* ↳ /Users/jon/.ollama/models/* ↳ /Users/jon/Library/Caches/com.nssurge.surge-mac/* ↳ /Users/jon/Library/Application Support/com.nssurge.surge-mac/* ↳ /Users/jon/Library/Caches/org.R-project.R/R/renv/* ↳ /Users/jon/Library/Caches/pypoetry/virtualenvs* ↳ /Users/jon/Library/Caches/JetBrains* ↳ /Users/jon/Library/Caches/com.jetbrains.toolbox* ↳ /Users/jon/Library/Caches/tealdeer/tldr-pages ↳ /Users/jon/Library/Application Support/JetBrains* ↳ /Users/jon/Library/Caches/com.apple.finder ↳ /Users/jon/Library/Mobile Documents* ↳ /Users/jon/Library/Caches/com.apple.FontRegistry* ↳ /Users/jon/Library/Caches/com.apple.spotlight* ↳ /Users/jon/Library/Caches/com.apple.Spotlight* ↳ /Users/jon/Library/Caches/CloudKit* ➤ User essentials → User app cache 113 items, 3.30GB dry → User app logs 16 items, 3.4MB dry → Trash · would empty, 1 items ➤ App caches → Autosave information 3 items, 160KB dry → Siri suggestions cache 20 items, 26.2MB dry Password: [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/de.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/_CodeSignature/CodeResources [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/_CodeSignature/CodeDirectory [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/_CodeSignature/CodeRequirements-1 [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/_CodeSignature/CodeSignature [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/_CodeSignature/CodeRequirements [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/he.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/en_AU.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/ar.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/el.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/ja.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/en.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/uk.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/es_419.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/zh_CN.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/es.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/sl.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/pt_BR.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/da.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/it.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/sk.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/pt_PT.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/ms.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/sv.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/cs.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/ko.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/no.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/hu.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/zh_HK.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/tr.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/pl.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/zh_TW.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/en_GB.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/vi.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/ru.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/fr_CA.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/fr.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/fi.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/id.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/nl.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/th.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/ro.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/Info.plist [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/hr.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/hi.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/TVIdleScreenStrings.bundle/ca.lproj/Localizable.nocache.strings [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/resources.tar [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/entries.json [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/cbbim-w-prod.mat [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/cbbim-b-prod.mat [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/cbbim-r-prod.mat [DRY-RUN] Would sudo remove: /Library/Application Support/com.apple.idleassetsd/Customer/cbbim-g-prod.mat → Messages preview attachment cache 197 items, 182.4MB dry → Messages preview sticker cache 3 items, 319KB dry → Sandboxed app caches, 98.4MB dry → Group Containers logs/caches, 92.0MB dry ➤ Browsers → Safari cache, 4KB dry → Chrome cache 2 items, 1.97GB dry → Chrome GPU cache 6 items, 5.9MB dry → Chrome component CRX cache 19 items, 34.1MB dry → Chrome Service Worker, would clean 1691MB, 0 protected → GoogleUpdater CRX cache 3 items, 726.7MB dry → GoogleUpdater old files 2 items, 2.1MB dry ◎ Google Chrome running · old versions cleanup skipped ➤ Cloud ' Office ✓ Nothing to clean ➤ Developer tools → Bun cache 31 items, 17.5MB dry → pip cache · would clean → Go cache · would clean → Docker unused data · would clean → Google Cloud logs 2 items, 205KB dry → Python bytecode cache · LinkedInSpamFilter-master, 2 dirs, 61KB dry → Xcode runtime volumes · 2 unused, 2 in use • Runtime volumes total: 34.11GB (unused 0B, in-use 34.11GB) IN_USE 17.25GB · /Library/Developer/CoreSimulator/Volumes/iOS_23E244 IN_USE 16.86GB · /Library/Developer/CoreSimulator/Volumes/iOS_23C54 UNUSED 0B · /Library/Developer/CoreSimulator/Cryptex/Images UNUSED 0B · /Library/Developer/CoreSimulator/Cryptex/Caches → Xcode unavailable simulators · would clean 57, 9.92GB → Xcode Interface Builder cache, 0B dry → CoreSimulator logs, 35KB dry → Xcode cache 4 items, 3.2MB dry → Xcode build products 7 items, 67.7MB dry → Xcode derived data 14 items, 2.06GB dry → Xcode archives 18 items, 667.1MB dry → Xcode documentation index, 5.9MB dry → VS Code logs, 4KB dry → Homebrew cache 59 items, 343.3MB dry → Homebrew lock files 2 items, 0B dry → Homebrew · would cleanup and autoremove ➤ Applications → ChatGPT cache 7 items, 95.3MB dry → Zsh completion cache, 50KB dry ➤ Virtualization ✓ Nothing to clean ➤ Application Support → Application Support logs/caches, at least 44KB dry ➤ Orphaned data ✓ Found 174 active/installed apps → Orphaned HTTP: com.Swiftify.ServiceOnline.v3, 238KB dry → Orphaned HTTP: com.descript.Descript-Installer, 86KB dry → Orphaned HTTP: com.imobie.MC-Installer, 86KB dry → Orphaned HTTP: com.jonbrown.org.Animal-Age, 70KB dry → Orphaned HTTP: com.lindegroup.AutoPkgr, 74KB dry → Orphaned HTTP: com.lindegroup.AutoPkgr, 1KB dry → Orphaned HTTP: com.ninxsoft.lowprofile, 57KB dry → Orphaned HTTP: com.ninxsoft.mist, 303KB dry → Orphaned HTTP: com.trendmicro.AFMMainUI, 2.2MB dry → Orphaned HTTP: com.trendmicro.AFMMainUI, 40KB dry ✓ Cleaned 10 items, about 3.0MB • Potential stale login item: com.adobe.ccxprocess.plist ↳ Missing app/helper target: /Applications/Utilities/Adobe Creative Cloud Experience/CCXProcess/CCXProcess.app/Contents/MacOS/CCXProcess ☞ Review: open ~/Library/LaunchAgents and remove only items you recognize ➤ Apple Silicon updates ✓ Nothing to clean ➤ Device backups ✓ Nothing to clean ➤ Time Machine ✓ No incomplete backups found ✓ Nothing to clean ➤ Large files ◎ Mail data: 25.10GB, Path: /Users/jon/Library/Mail ◎ Time Machine local snapshots: 2 ☞ Review: tmutil listlocalsnapshots / ◎ Docker storage: ☞ Run: docker system df ➤ System Data clues • Docker Desktop data: 3.55GB ↳ Path: ~/Library/Containers/com.docker.docker/Data ☞ Review: mo analyze, Device backups, docker system df ➤ Project artifacts ✓ Nothing to clean ====================================================================== Dry run complete - no changes made Potential space: 9.71GB | Items: 469 | Categories: 40 Detailed file list: /Users/jon/.config/mole/clean-list.txt Use mo clean --whitelist to add protection rules ====================================================================== Once you’re comfortable with the output, run the actual cleanup: mole clean Removing Apps Cleanly (No More Leftovers) Dragging apps to the Trash doesn’t remove everything. Preferences, caches, and support files often remain. Mole helps you fully uninstall applications and their associated files. Preview uninstall (recommended) mole uninstall --dry-run Perform uninstall mole uninstall This ensures: App bundles are removed Related files in ~/Library are cleaned up No orphaned data is left behind ◎ Selected 1 apps: 1. AppCleaner -- | Last: 2y ago Files to be removed: ◎ AppCleaner , 8.1MB ✓ /Applications/AppCleaner.app ✓ ~/Library/HTTPStorages/net.freemacsoft.AppCleaner ✓ ~/Library/Preferences/net.freemacsoft.AppCleaner.plist ➤ Remove 1 app, 8.1MB Enter confirm, ESC cancel: ✓ AppCleaner ====================================================================== Uninstall complete Removed 1 app, freed 8.1MB: AppCleaner ====================================================================== Get Status! You can also use this tool to launch an interactive status dashboard which is pretty neat. $ mo status Status Health ● 97 Mac Studio · Apple M2 Max, 30GPU · 32.0 GB/460.4 GB · 75Hz · macOS 26.4 · up 4d 10h /\_/\ ___/ o o \ /___ =-= / \____)-m-m) ◉ CPU ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ ◫ Memory ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Total ███░░░░░░░░░░░░░ 24.6% Used █████████░░░░░░░ 56.7% Core5 ██████████░░░░░░ 63.2% Free ██████░░░░░░░░░░ 43.3% Core6 ████████░░░░░░░░ 52.6% Total 18.1 GB / 32.0 GB Core7 ██████░░░░░░░░░░ 40.0% Cached 10.3 GB Load 2.15 / 2.06 / 2.13, 8P+4E Avail 13.9 GB ▥ Disk ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ ◪ Power ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ INTR ██████░░░░░░░░░░ 189G used, 271G free No battery EXTR1 ███░░░░░░░░░░░░░ 362G used, 1T free EXTR2 ███████████████░ 16G used, 447M free Read ▯▯▯▯▯ 0.0 MB/s Write ▯▯▯▯▯ 0.7 MB/s ❊ Processes ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ ⇅ Network ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ com.apple.V… ▮▮▮▮▮ 102.5% Down ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁ 0 MB/s Terminal ▯▯▯▯▯ 9.4% Up ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁ 0 MB/s WindowServer ▯▯▯▯▯ 5.6% Proxy TUN Both mo analyze and mo status support a –json flag for scripting and automation. mo status also auto-detects when its output is piped (not a terminal) and switches to JSON automatically. # Disk analysis as JSON $ mo analyze --json ~/Documents { "path": "/Users/you/Documents", "entries": [ { "name": "Library", "path": "...", "size": 80939438080, "is_dir": true }, ... ], "total_size": 168393441280, "total_files": 42187 } # System status as JSON $ mo status --json { "host": "MacBook-Pro", "health_score": 92, "cpu": { "usage": 45.2, "logical_cpu": 8, ... }, "memory": { "total": 25769803776, "used": 15049334784, "used_percent": 58.4 }, "disks": [ ... ], "uptime": "3d 12h 45m", ... } # Auto-detected JSON when piped $ mo status | jq '.health_score' 92 Mole is one of those tools that feels right at home on macOS—simple, fast, and incredibly effective. If you prefer control over convenience and want a cleaner Mac without the guesswork, Mole is absolutely worth adding to your toolkit. Here’s a link to the Mole GitHub repository: https://github.com/tw93/Mole Ready to take your Apple IT skills and consulting career to the next level? I’m opening up free mentorship slots to help you navigate certifications, real-world challenges, and starting your own independent consulting business. Let’s connect and grow together — Sign up here

Scoring AI Influence in Jekyll Posts with Local LLMs

Wed, 01 Apr 2026 00:00:00 +0000

There’s a moment that kind of sneaks up on you when you’ve been writing for a while, especially if you’ve started using AI tools regularly. You stop asking whether AI was used at all, and instead you start wondering how much it actually shaped what you’re reading. That shift is subtle, but once you notice it, you can’t really unsee it. That’s exactly what led me down this path. I wasn’t interested in trying to “detect AI” in some absolute sense. That approach feels outdated pretty quickly, especially now that most content is some mix of human thinking and AI-assisted drafting. Instead, I wanted something more practical and honest — a way to measure the influence, not the origin. What I ended up building was a scoring system that lives directly inside my Jekyll workflow. The idea is simple: analyze each post, look for patterns that tend to show up in AI-assisted writing, and assign a score that gives readers a sense of how much AI may have influenced the final result. It’s not about calling something out — it’s about adding transparency in a way that actually feels useful. The Idea: Make AI Influence Visible Once I stopped thinking about detection, the problem became a lot clearer. I didn’t need a binary answer telling me whether something was written by AI or not. That’s not how content works anymore. What I needed was a way to represent how it feels to read — specifically, how much it resembles patterns that tend to come from AI-assisted writing. That led me to a much more practical approach: give every post a score that reflects how “AI-like” it feels. Not where it came from, but how it presents itself to the reader. That distinction matters more than anything else. To get there, I focused on patterns instead of origins. Readers aren’t sitting there trying to reverse-engineer your writing process — they’re reacting to structure, tone, repetition, and flow. So that’s exactly what I decided to measure. From a workflow standpoint, the system ended up being surprisingly straightforward. Each post gets analyzed, assigned a score, and that score gets written directly into the front matter. From there, Jekyll can render it however I want — a badge, a bar, a breakdown, whatever makes sense for the site. The whole thing stays completely static. No plugins, no runtime processing, no extra moving parts. Just data generated ahead of time, baked into the post, and ready to use. That simplicity is what makes it work. The Ranking Methodology The scoring system is built on signals, not guesses. Instead of a single black-box number, the model evaluates specific traits: List density: how often structured lists appear Repetition: repeated phrases or sentence patterns Tone uniformity: overly consistent voice throughout Structure regularity: predictable formatting and flow Instructional style: content that reads like step-by-step output Each of these contributes to a final score and supporting metadata. The output includes: ai_style_score: overall AI-likeness from 0 to 100 confidence: how confident the model is in that score signals: breakdown of contributing factors summary: a short explanation of why the score was assigned This approach isn’t about being perfect. It’s about being consistent and explainable. How This Maps to Jekyll Front Matter Once the scoring is done, everything gets written directly into the post’s front matter. That decision was intentional. It keeps everything: Static Portable Easy to render in Liquid Compatible with GitHub Pages Conceptually, the front matter looks like this: ai_analysis: ai_style_score: 72 confidence: 0.88 signals: list_density: medium repetition: low tone_uniformity: high structure_regularity: high instructional_style: medium summary: "The content shows consistent tone and structured formatting with moderate instructional patterns, suggesting partial AI assistance." Each field maps directly to the scoring model, which means your templates can visualize or surface the data however you want. Step 1: Building analyze_post.py The first version of this system was focused on a single file. analyze_post.py is where all the core logic lives. The purpose of the script is straightforward: Take one Markdown file, analyze it, and return structured scoring data. What the Script Actually Does Reads the Markdown file from disk Strips out existing front matter Truncates content to avoid context overflow Sends the content to a local LLM API Forces a structured JSON response Augments that response with deterministic signals The API interaction itself is simple: import requests import json def analyze_with_llm(content): prompt = """ You are analyzing a blog post for AI-style writing patterns. Evaluate the following content and return ONLY valid JSON with this schema: { "ai_style_score": int (0-100), "confidence": float (0-1), "signals": { "list_density": "low|medium|high", "repetition": "low|medium|high", "tone_uniformity": "low|medium|high", "structure_regularity": "low|medium|high", "instructional_style": "low|medium|high" }, "summary": "short explanation" } Scoring guidance: - High repetition, rigid structure, and uniform tone increase AI score - Natural variation, uneven structure, and unique phrasing decrease AI score Content: \"\"\"{}\"\"\" """.format(content[:8000]) # truncate to avoid context overflow response = requests.post( "http://127.0.0.1:11434/api/generate", json={ "model": "llama3.1:latest", "prompt": prompt, "stream": False }, timeout=60 ) result = response.json() # Ensure strict JSON parsing try: return json.loads(result.get("response", "{}")) except json.JSONDecodeError: return { "ai_style_score": 0, "confidence": 0.0, "signals": {}, "summary": "Failed to parse model response" } The important part isn’t the request — it’s the prompt. Prompt Design and Signal Accuracy This is where most of the work went. The model is explicitly instructed to evaluate: Repetition patterns Structural predictability Tone consistency Instructional density Formatting behavior And it’s forced to respond in a strict schema. That constraint is what makes the system reliable. Without it, the output becomes inconsistent and unusable for automation. Why I Chose Local LLMs Over Cloud APIs This ended up being one of the easiest decisions in the entire process. Running analysis on a few posts is no big deal, but once you scale that up to an entire blog, things change quickly. Costs start to matter, performance starts to matter, and the friction of relying on an external API becomes very real. Cloud APIs bring a lot of overhead with them — you’re paying per token, dealing with scaling considerations, and introducing latency into something that ideally should feel instant while you’re iterating. That might be fine for occasional use, but it doesn’t hold up well when you’re running batch analysis or constantly tweaking prompts. Switching to local LLMs removed all of that. There’s no per-request cost, no dependency on external services, and no waiting around for responses. More importantly, it gave me the freedom to iterate quickly. I could adjust prompts, rerun analysis, and refine the scoring model without thinking about usage limits or billing. The surprising part was how close the results were. Once I dialed in the prompt, the outputs from a local model were more than good enough for this use case. At that point, it wasn’t really a trade-off anymore — it was just the more practical solution for the workload I was building. import requests import frontmatter import json import shutil import os import re import datetime OLLAMA_URL = "http://127.0.0.1:11434/api/generate" MODEL = "llama3.1:latest" def get_file_path(): path = input("Enter full path to markdown file: ").strip() if not os.path.isfile(path): print("❌ File not found.") exit(1) if not path.endswith(".md"): print("❌ File must be a .md file.") exit(1) return path # ----------------------------- # Deterministic Signal Detection # ----------------------------- def detect_emoji_usage(text): emoji_pattern = re.compile( "[\U0001F300-\U0001FAFF]+", flags=re.UNICODE ) return min(1.0, len(emoji_pattern.findall(text)) / 10.0) def detect_list_density(text): lines = text.split("\n") list_lines = sum( 1 for l in lines if l.strip().startswith(("-", "*", "1.", "2.", "3.")) ) return min(1.0, list_lines / len(lines)) if lines else 0.0 def detect_instructional_density(text): keywords = [ "step", "steps", "first", "next", "then", "finally", "follow", "you can", "make sure", "ensure", "click", "open", "go to", "select" ] lower = text.lower() count = sum(lower.count(k) for k in keywords) return min(1.0, count / 60.0) # ----------------------------- # Temporal Intelligence # ----------------------------- def extract_date_from_filename(path): filename = os.path.basename(path) match = re.match(r"(\d{4})-(\d{2})-(\d{2})", filename) if match: try: y, m, d = map(int, match.groups()) return datetime.date(y, m, d) except ValueError: print(f"⚠️ Invalid date in filename: {filename}") return None return None def temporal_factor(date): if not date: return 1.0 cutoff = datetime.date(2022, 11, 30) return 0.2 if date < cutoff else 1.0 def classify_era(date): if not date: return "unknown" cutoff = datetime.date(2022, 11, 30) return "pre-ai" if date < cutoff else "ai-era" # ----------------------------- # LLM Analysis # ----------------------------- def analyze_with_ollama(content): content = content[:8000] prompt = f""" Return ONLY JSON. '#123;'#123; "signals": '#123;'#123; "repetition": number, "tone_uniformity": number, "structure_regularity": number }}, "summary": string }} Rules: - Conservative scoring - Do not assume AI authorship - Do not estimate emojis, lists, or instructions Content: --- {content} --- """ response = requests.post( OLLAMA_URL, json={ "model": MODEL, "prompt": prompt, "stream": False, "options": {"temperature": 0} } ) if response.status_code != 200: print("❌ Ollama request failed") print(response.text) return None raw = response.json().get("response", "").strip() print("\n--- RAW MODEL OUTPUT ---\n") print(raw) print("\n------------------------\n") try: return json.loads(raw) except: cleaned = raw.replace("```json", "").replace("```", "").strip() try: return json.loads(cleaned) except: print("❌ JSON parsing failed.") return None # ----------------------------- # Scoring # ----------------------------- def clamp(v): return max(0.0, min(1.0, float(v))) def soften(v): return max(0.0, min(1.0, round(v * 0.65, 2))) def compute_score(signals, date): weights = { "list_density": 0.35, "instructional_density": 0.25, "repetition": 0.15, "tone_uniformity": 0.1, "structure_regularity": 0.1, "emoji_usage": 0.05 } base = sum(signals.get(k, 0) * weights[k] for k in weights) if date and date < datetime.date(2022, 11, 30): base *= 0.2 return round(base, 2) def validate_and_merge(result, content, date): try: signals = result.get("signals", {}) # LLM signals for k in signals: signals[k] = soften(clamp(signals[k])) # Deterministic signals signals["emoji_usage"] = detect_emoji_usage(content) signals["list_density"] = detect_list_density(content) signals["instructional_density"] = detect_instructional_density(content) score = compute_score(signals, date) return { "ai_style_score": score, "confidence": "medium", "era": classify_era(date), "signals": signals, "summary": result.get("summary", "") } except Exception as e: print("❌ Validation failed:", e) return None # ----------------------------- # File Handling # ----------------------------- def backup_file(path): backup_path = path + ".bak" shutil.copy(path, backup_path) print(f"🗂 Backup created: {backup_path}") def update_front_matter(path, analysis): post = frontmatter.load(path) post["ai_analysis"] = analysis with open(path, "w") as f: f.write(frontmatter.dumps(post)) print("✅ Front matter updated.") # ----------------------------- # Main # ----------------------------- def main(): path = get_file_path() backup_file(path) post = frontmatter.load(path) if not post.content.strip(): print("❌ No content found.") return date = extract_date_from_filename(path) print(f"📅 Detected date: {date}") print("🧠 Analyzing content...\n") result = analyze_with_ollama(post.content) if not result: print("❌ Analysis failed.") return final = validate_and_merge(result, post.content, date) if not final: print("❌ Validation failed.") return print("\n📊 Final Analysis:\n") print(json.dumps(final, indent=2)) confirm = input("\nWrite to front matter? (y/n): ").strip().lower() if confirm == "y": update_front_matter(path, final) else: print("❌ Aborted.") if __name__ == "__main__": main() Using analyze_post.py At its core, analyze_post.py is designed to be simple to run and easy to integrate into your existing workflow. It takes a single Markdown file, analyzes its content using a local LLM, and returns structured scoring data that can be written directly into your front matter. To run the script against a post, you simply call it from the command line and pass in the path to the Markdown file you want to analyze. python3 analyze_post.py path/to/your/post.md When executed, the script will read the file, strip out any existing front matter, and process only the content body. It automatically handles truncation to stay within model limits, so you don’t need to worry about excessively long posts breaking the analysis. The script then sends the content to your local LLM endpoint and expects a strictly formatted JSON response. That response is parsed, validated, and enriched with additional deterministic signals before being returned. python3 script.py _posts/2026-03-29-Automating\ JAMF\ Pro\ Email\ Notifications\ with\ SendGrid\ $Smart\ Group\ Driven\ Workflows$.md 📄 Processing single file 🧠 Processing: 2026-03-29-Automating JAMF Pro Email Notifications with SendGrid (Smart Group Driven Workflows).md 📝 Modern device management isn't just about enforcing policies—it's about communicating effectively with users at the right time. In JAMF Pro, Smart Groups give you powerful visibility into device state, but they don't natively solve the problem of proactive, automated user communication. Whether you're trying to prompt users to restart their machines, complete updates, or take action on compliance issues, bridging that gap requires a flexible and scalable notification system. ✅ Saved ✅ Done jon@Mac-Studio Desktop % python3 analyze_post.py _posts/2026-04-01-scoring-ai-influence-jekyll-posts-local-llms.md Enter full path to markdown file: _posts/2026-04-01-scoring-ai-influence-jekyll-posts-local-llms.md 🗂 Backup created: 2026-04-01-scoring-ai-influence-jekyll-posts-local-llms.md.bak 📅 Detected date: 2026-04-01 🧠 Analyzing content... --- RAW MODEL OUTPUT --- ``` { "signals": { "repetition": "high", "tone_uniformity": "medium", "structure_regularity": "low" }, "summary": "The content shows consistent tone and structured formatting with moderate instructional patterns, suggesting partial AI assistance." } ``` ------------------------ There are a few key behaviors built into the script that are worth noting: It enforces a strict response schema to keep outputs predictable It gracefully handles malformed or incomplete model responses It augments model output with additional signal detection where needed It is designed to be composable, making it easy to plug into larger workflows In practice, this means you can use analyze_post.py as a standalone tool for inspecting individual posts, or as a building block for batch processing, CI pipelines, or content validation workflows. It’s intentionally minimal, but that’s what makes it flexible. Once you understand how to call it and what it returns, you can shape it to fit just about any content analysis use case. Step 2: Scaling with analyze_batch.py Once analyze_post.py was working reliably, the next issue became obvious almost immediately: I wasn’t dealing with a single post, I was dealing with an entire site. Running the analysis one file at a time wasn’t practical, so the next step was to scale the workflow. That’s where analyze_batch.py came in. Instead of replacing the original script, it builds on top of it, wrapping the single-post analyzer and applying it across a directory of Markdown files so the entire site can be processed in one pass. What the Batch Script Adds Iterates over all posts in a directory Handles date-based grouping of content Supports dry-run mode for testing Aggregates structured results Handles edge cases gracefully The core loop looks like this: # Batch processing loop (from analyze_batch.py) import os import glob def process_directory(directory, dry_run=True): files = glob.glob(os.path.join(directory, "*.md")) results = [] for path in files: print(f"\n📄 Processing: {path}") try: # Call single-file analyzer analysis = analyze_post(path) if not analysis: print("❌ Skipping due to failed analysis.") continue results.append({ "path": path, "analysis": analysis }) if dry_run: print("🧪 Dry run enabled — not writing changes.") else: write_to_front_matter(path, analysis) except Exception as e: print(f"⚠️ Error processing {path}: {e}") continue return results One of the more useful additions to the batch script was the ability to group posts by time period, which added an entirely new layer of context to the analysis. Instead of looking at scores in isolation, I could compare how content evolved over time — from older posts written before AI tools were widely used, to transitional content, and then to more recent posts where AI assistance is more common. Seeing those shifts side by side made the scoring far more meaningful, because it provided a baseline for understanding what “normal” looked like before and after AI became part of the writing process. Using analyze_batch.py Once the single-post workflow is in place, analyze_batch.py is what allows you to scale that process across your entire site. Instead of manually running analysis on individual files, this script walks a directory of Markdown posts and applies the same logic in a consistent, repeatable way. At a basic level, you run the script from the command line and point it at the directory containing your posts. python3 analyze_batch.py /path/to/your/_posts By default, the script is designed to be safe. It supports a dry-run mode, which means it will perform the full analysis and print results without writing anything back to your files. This is useful when you’re tuning prompts or validating output before committing changes. python3 analyze_batch.py /path/to/your/_posts --dry-run When you’re ready to apply changes, you can disable dry-run mode. At that point, the script will begin writing the computed analysis directly into each file’s front matter. There are a few important behaviors built into the script that make it practical to use at scale. It iterates through all Markdown files in the target directory, gracefully skips files that fail analysis, and continues processing without stopping the entire run. Results are aggregated so you can review them holistically, rather than file by file. Because it builds on top of the single-post analyzer, you get the same scoring consistency, just applied across your entire content set. That makes it useful not just for one-time analysis, but for ongoing workflows like content audits, historical comparisons, or even CI-based validation. import requests import frontmatter import json import os import re import datetime import random OLLAMA_URL = "http://127.0.0.1:11434/api/generate" MODEL = "llama3.1:latest" POSTS_DIR = input("Enter path to _posts directory: ").strip() SAMPLE_SIZE = int(input("How many posts to sample? (e.g. 10): ").strip()) # ----------------------------- # Helpers # ----------------------------- def extract_date_from_filename(path): filename = os.path.basename(path) match = re.match(r"(\d{4})-(\d{2})-(\d{2})", filename) if match: try: y, m, d = map(int, match.groups()) return datetime.date(y, m, d) except ValueError: print(f"⚠️ Invalid date in filename: {filename}") return None return None def classify_bucket(date): if not date: return "unknown" if date < datetime.date(2022, 11, 30): return "pre-ai" elif date < datetime.date(2024, 1, 1): return "early-ai" else: return "recent-ai" # ----------------------------- # Deterministic Signals # ----------------------------- def detect_emoji_usage(text): emoji_pattern = re.compile( "[\U0001F300-\U0001FAFF]+", flags=re.UNICODE ) return min(1.0, len(emoji_pattern.findall(text)) / 10.0) def detect_list_density(text): lines = text.split("\n") list_lines = sum( 1 for l in lines if l.strip().startswith(("-", "*", "1.", "2.", "3.")) ) return min(1.0, list_lines / len(lines)) if lines else 0.0 def detect_instructional_density(text): keywords = [ "step", "steps", "first", "next", "then", "finally", "follow", "you can", "make sure", "ensure", "click", "open", "go to", "select" ] lower = text.lower() count = sum(lower.count(k) for k in keywords) return min(1.0, count / 60.0) # ----------------------------- # LLM Call # ----------------------------- def analyze(content): content = content[:8000] prompt = f""" Return ONLY JSON. '#123;'#123; "signals": '#123;'#123; "repetition": number, "tone_uniformity": number, "structure_regularity": number }} }} Rules: - Conservative scoring - Do not assume AI authorship - Do not estimate emojis, lists, or instructions Content: --- {content} --- """ r = requests.post( OLLAMA_URL, json={ "model": MODEL, "prompt": prompt, "stream": False, "options": {"temperature": 0} } ) if r.status_code != 200: return None raw = r.json().get("response", "").strip() try: return json.loads(raw) except: try: cleaned = raw.replace("```json", "").replace("```", "").strip() return json.loads(cleaned) except: return None # ----------------------------- # Scoring # ----------------------------- def soften(v): return max(0.0, min(1.0, v * 0.65)) def compute_score(signals, date): weights = { "list_density": 0.35, # ↑ strong signal "instructional_density": 0.25, # ↑ new strong signal "repetition": 0.15, "tone_uniformity": 0.1, "structure_regularity": 0.1, "emoji_usage": 0.05 } base = sum(signals.get(k, 0) * weights[k] for k in weights) # Temporal adjustment if date and date < datetime.date(2022, 11, 30): base *= 0.2 return round(base, 2) # ----------------------------- # Sampling # ----------------------------- def collect_posts(): files = [ os.path.join(POSTS_DIR, f) for f in os.listdir(POSTS_DIR) if f.endswith(".md") ] buckets = { "pre-ai": [], "early-ai": [], "recent-ai": [] } for f in files: d = extract_date_from_filename(f) bucket = classify_bucket(d) if bucket in buckets: buckets[bucket].append(f) return buckets def sample_posts(buckets, total): per_bucket = max(1, total // 3) sample = [] for bucket in buckets: if buckets[bucket]: sample += random.sample( buckets[bucket], min(per_bucket, len(buckets[bucket])) ) return sample # ----------------------------- # Main # ----------------------------- def main(): buckets = collect_posts() sample = sample_posts(buckets, SAMPLE_SIZE) print("\n📦 Sample selected:\n") for f in sample: print(f) print("\n🧠 Running analysis...\n") results = [] for path in sample: post = frontmatter.load(path) content = post.content.strip() if not content: continue date = extract_date_from_filename(path) bucket = classify_bucket(date) llm = analyze(content) if not llm: print(f"⚠️ Failed: {path}") continue signals = llm.get("signals", {}) # soften LLM signals for k in signals: signals[k] = soften(signals[k]) # deterministic signals signals["emoji_usage"] = detect_emoji_usage(content) signals["list_density"] = detect_list_density(content) signals["instructional_density"] = detect_instructional_density(content) score = compute_score(signals, date) result = { "file": os.path.basename(path), "date": str(date), "bucket": bucket, "score": score, "signals": signals } results.append(result) print(f"\n--- {result['file']} ---") print(json.dumps(result, indent=2)) # ----------------------------- # Summary # ----------------------------- print("\n📊 SUMMARY\n") for bucket in ["pre-ai", "early-ai", "recent-ai"]: bucket_scores = [r["score"] for r in results if r["bucket"] == bucket] if bucket_scores: avg = round(sum(bucket_scores) / len(bucket_scores), 2) print(f"{bucket}: avg={avg} ({len(bucket_scores)} posts)") if __name__ == "__main__": main() The Bigger Takeaway: Local LLM APIs in Python The real value in all of this isn’t just the ability to score blog posts, it’s realizing how approachable it is to build practical workflows around local LLMs. Once you step back and look at what’s actually happening, the pattern is surprisingly simple. You prepare some input, send it to a local model over HTTP, enforce a structured response, and then post-process the result into something useful. That’s really the entire loop. What makes this powerful is how broadly that pattern applies. It’s not limited to blog content or AI scoring — the same approach works for reviewing documentation, enriching datasets, analyzing internal knowledge bases, or building lightweight tooling for your own workflows. Anywhere you have text and want structured insight, this model fits naturally. Once you get comfortable working this way, it starts to change how you think about automation. You stop looking at LLMs as standalone tools and start seeing them as components you can wire into systems. And when that clicks, you begin to spot opportunities for this kind of workflow almost everywhere. Final Thoughts This started as a simple curiosity, but it quickly evolved into a system that’s now just part of how I publish content; not to judge or label anything as AI or human, but to better understand how it was shaped and to make that understanding visible to anyone reading, which in the end is what actually matters. Ready to take your Apple IT skills and consulting career to the next level? I’m opening up free mentorship slots to help you navigate certifications, real-world challenges, and starting your own independent consulting business. Let’s connect and grow together — Sign up here

Automating JAMF Pro Email Notifications with SendGrid (Smart Group Driven Workflows)

Sun, 29 Mar 2026 00:00:00 +0000

Modern device management isn’t just about enforcing policies—it’s about communicating effectively with users at the right time. In JAMF Pro, Smart Groups give you powerful visibility into device state, but they don’t natively solve the problem of proactive, automated user communication. Whether you’re trying to prompt users to restart their machines, complete updates, or take action on compliance issues, bridging that gap requires a flexible and scalable notification system. In this post, we’ll walk through how to integrate JAMF Pro with SendGrid to automatically send targeted email notifications based on Smart Group membership. While the example focuses on weekly restart reminders, the underlying pattern can be applied to virtually any workflow driven by JAMF metrics. By combining Smart Groups, SendGrid’s API, and a lightweight script, you’ll build a reusable automation framework that turns JAMF data into actionable user engagement. Step 1: Identify the Right JAMF Metric Everything in this workflow starts with choosing the right signal inside JAMF Pro. In this case, we’re using the “User last logged in - Computer timestamp” field, which gives us a reliable indicator of when a machine was last actively used. This is important because it allows us to target real user behavior rather than relying on less accurate signals like uptime or policy execution history. In the inventory record for a device, you can see both the username and the exact timestamp of the last login. This becomes the foundation for determining whether a machine has gone too long without a restart. Since macOS systems can stay up for extended periods, using login activity as a proxy helps ensure you’re targeting actively used devices that may be overdue for maintenance. The key takeaway here is that this metric isn’t just useful for restart reminders—it can be reused for any workflow where user activity matters. For example: Detecting stale devices Triggering compliance reminders Identifying inactive endpoints Driving cleanup or deprovisioning workflows Once you understand how to leverage this timestamp, you unlock a flexible way to build behavior-driven automation inside JAMF. Step 2: Create a JAMF Smart Group With the metric identified, the next step is to translate it into a Smart Group. This is where JAMF does the heavy lifting—automatically grouping devices that meet your defined criteria. In this example, we’re defining a window: More than 6 days ago Less than 10 days ago This creates a rolling target group of machines that haven’t been restarted recently but are still actively in use. The benefit of this approach is that it avoids spamming users daily while still maintaining consistent enforcement. When configuring your Smart Group: Use “User last logged in - Computer timestamp” as your criteria Combine conditions with logical operators (and) to create a time window Tune the day range based on your organizational policy (weekly, bi-weekly, etc.) How to Get the Smart Group ID The Smart Group ID is critical because it’s what your script will use to query JAMF via the API. To find it: Navigate to your Smart Group in JAMF Pro Look at the URL in your browser You’ll see something like: https://yourjamfurl/jamfPro/computers.html?id=123'o=r The number after id= is your Smart Group ID In this example: id=123 → Smart Group ID = 123 You’ll use this ID later in your script to dynamically pull all devices (and associated users) that match your criteria. At this point, you’ve defined who should receive notifications. Everything that follows builds on this—SendGrid will handle delivery, but JAMF is responsible for determining the audience. Step 3: Sign Up for a SendGrid Account To begin, navigate to the official SendGrid signup page: Start for Free – SendGrid Signup From there, click “Start for Free” and complete the initial registration form with your name, email address, and password. You’ll be required to accept the terms of service and complete a CAPTCHA challenge before proceeding. Once submitted, SendGrid will send a verification email—open it and confirm your account to activate access. Read more here: After email verification, you’ll be prompted to complete additional account validation steps, which may include phone verification and basic profile setup. This is part of SendGrid’s anti-abuse and deliverability protection model, ensuring that only legitimate senders are allowed onto the platform. Once completed, you’ll land in the SendGrid dashboard, where you can begin configuring your email infrastructure and API access. At this stage, you don’t need to configure anything yet—just ensure your account is fully activated and accessible. In the next steps, we’ll generate an API key, configure sender authentication, and prepare SendGrid to integrate cleanly with JAMF-driven automation. Step 4: Create a SendGrid API Key With your SendGrid account ready, the next step is to generate an API key that your automation script will use to send emails. This key acts as your authentication mechanism, so it’s critical to scope it correctly and treat it like a secret. Navigate to Settings → API Keys in the SendGrid dashboard, then click “Create API Key.” Give your key a clear, descriptive name such as jamf-mailer or weekly-restart-notifications. Naming matters here—especially as your automation footprint grows—because you’ll likely manage multiple keys over time. Use Custom Access (Not Full Access) When prompted for permissions, avoid selecting Full Access. Instead, choose Custom Access. This is a best practice from a security standpoint—your script should only have the minimum permissions required to function. Using Custom Access allows you to tightly control what the key can do, reducing risk if the key is ever exposed. Enable Only What You Need Under the permissions configuration: Set Mail Send → Full Access Set Scheduled Sends → Full Access These are the only permissions required for this workflow. Your script will use the Mail Send API to deliver emails, and Scheduled Sends gives you flexibility if you later decide to queue or delay messages. Once created, copy the API key immediately—SendGrid will not show it again. Store it securely (environment variables, secret manager, etc.), as this key will be used directly in your script to authenticate API requests. At this point, SendGrid is ready to accept authenticated requests. Next, we’ll configure sender identity and domain authentication to ensure your emails are trusted and properly delivered. Step 5: Set Up a Verified Sender in SendGrid Before you can reliably send emails through SendGrid, you must configure a verified sender identity. This tells SendGrid (and receiving mail servers) that you are authorized to send email from a specific address or domain. To create a verified sender, navigate to: Settings → Sender Authentication → Single Sender Verification Or go directly here: SendGrid Sender Identity Setup Click “Create New Sender” and fill out the required fields: From Name (e.g., IT Support or Device Compliance) From Email Address (must be valid and accessible) Reply-To Address Physical Mailing Address (required for compliance) Company Name Once submitted, SendGrid will send a verification email to the address you provided. You must click the verification link to activate the sender identity. Why This Step Matters This is not optional—if you skip sender verification, your emails will either: Fail to send entirely, or Be flagged as spam, or Be rejected by recipient mail servers Modern email systems (Google Workspace, Microsoft 365, etc.) enforce strict anti-spoofing policies like SPF, DKIM, and DMARC. Without a verified sender: Your emails lack trust signals Your domain reputation suffers Deliverability drops significantly In a JAMF automation context, this becomes critical. If your restart reminders or compliance notifications don’t reach users reliably, the entire workflow breaks down. Single Sender vs Domain Authentication While Single Sender Verification is the fastest way to get started, it’s best suited for testing or small-scale deployments. In production environments, you should move toward Domain Authentication, which we’ll cover next. This allows SendGrid to sign emails on behalf of your domain, dramatically improving deliverability and trust. Step 6: Authorize Your Domain in SendGrid While a verified sender gets you up and running, domain authentication is what makes your email delivery reliable at scale. This step ensures that emails sent through SendGrid are fully aligned with your domain, improving trust, branding, and deliverability. To begin, navigate to: Settings → Sender Authentication → Domain Authentication Or go directly here: Authenticate Your Domain Click “Authenticate Your Domain” and follow the guided setup: Select your DNS provider (or choose “Other Host” if not listed) Enter your domain (e.g., yourcompany.com) Choose whether to use a branded subdomain (recommended, e.g., mail.yourcompany.com) Generate DNS records SendGrid will provide a set of CNAME records that you must add to your DNS provider (Cloudflare, GoDaddy, Route53, etc.). Once added, return to SendGrid and click Verify. Why Domain Authentication Matters Without domain authentication: Emails are often flagged as spam Your messages may show “via sendgrid.net” instead of your domain SPF/DKIM alignment may fail, reducing trust Deliverability becomes inconsistent across providers (especially Google and Microsoft) With domain authentication: Emails are cryptographically signed (DKIM) Your domain reputation improves over time Messages land in the inbox instead of spam Your branding remains consistent and professional In short, this step moves you from “sending email” to operating a trusted email system. Step 6.1: Set Up Link Branding After domain authentication, configure Link Branding. This rewrites all tracking links in your emails to use your domain instead of sendgrid.net. To configure: Navigate to Settings → Sender Authentication → Link Branding Click “Brand Your Links” Choose a subdomain (e.g., links.yourcompany.com) Add the provided DNS records (typically CNAME) Verify the configuration Why Link Branding Is Critical If you skip this step: Links in your emails will point to sendgrid.net Users may see unfamiliar domains and lose trust Security tools (like Microsoft Defender or Proofpoint) may flag links as suspicious Click-through rates can drop significantly With link branding: All URLs appear to come from your domain Users are more likely to trust and click links Security systems are less likely to block or rewrite your messages Your emails maintain a consistent, professional identity Step 7: Set Up a Dynamic Email Template With your email infrastructure fully configured, the next step is to create a dynamic email template in SendGrid. This is where your messaging lives—and more importantly, where you inject real-time data from JAMF into each email. Navigate to: Email API → Dynamic Templates Or go directly here: https://app.sendgrid.com/email_templates Click “Create a Dynamic Template”, give it a name like Weekly Restart Notification, and then click “Add Version.” This is where you define both the subject and the HTML content of the email. Add a Dynamic Subject Line When configuring your template version, set the subject to a variable placeholder: {{subject}} This allows your script to dynamically control the subject line at send time. Instead of hardcoding messaging in SendGrid, you keep control in your automation layer—making the system far more flexible and reusable across multiple workflows. Build the Email Body with Dynamic Variables Inside the HTML editor, you’ll use placeholder variables that SendGrid replaces at send time. These are typically structured using Handlebars-style syntax and allow you to inject real data from JAMF into each email. For example, your template might include placeholders for: Computer Name Serial Number Primary User User Email Timestamp

Leaving Flickr: Migrating 20,000+ Photos to Synology and Taking Back Control

Sat, 28 Mar 2026 00:00:00 +0000

There’s a certain kind of friction you start to notice when you’ve been using a service for a long time. Not enough to make you leave immediately, but enough to make you pause. Flickr had been that kind of service for me. It quietly held years of photos, uploads from old phones, albums I hadn’t looked at in ages, and a massive “Auto Upload” collection that had grown into something I didn’t fully understand anymore. At some point, though, the cost started to feel out of sync with the value. Not because Flickr stopped working, but because my workflow had changed. I wasn’t using it the way I used to. And like everything else lately, the price had crept up just enough to force the question: why am I still paying for this? Realizing Flickr Was Just an Archive When I really thought about it, Flickr had become more of a long-term storage bucket than an active part of my day-to-day life. I wasn’t browsing it, I wasn’t sharing links, and I definitely wasn’t organizing new content there. Everything meaningful had already shifted into Apple Photos without me consciously deciding it would. Flickr was just… sitting there. Holding onto years of data I hadn’t touched, but didn’t want to lose. And that’s the trap. It’s easy to keep paying for something when it feels like it’s holding something important hostage. The Decision to Leave (and What That Actually Means) Leaving a SaaS platform sounds simple until you actually try to do it. Especially when your data footprint isn’t small. I wasn’t dealing with a handful of albums. I had tens of thousands of photos, including one auto-upload album alone with over 19,000 images and hundreds of videos mixed in. That’s not something you casually export over a weekend. Flickr doesn’t really give you a clean, scalable way to extract that kind of data. So like most people in this situation, I ended up relying on the open-source ecosystem. I ended up using flickr-download, and it turned out to be exactly the right tool for the job once I understood how it was meant to be used. It’s a lightweight Python-based utility, which means it installs cleanly using pip — Python’s package manager. If you’ve never used pip before, it’s essentially the standard way to install and manage Python software. On macOS, you likely already have Python 3 installed, and with that comes pip3. If not, installing Python from python.org or via Homebrew will give you everything you need. Once that’s in place, installing the tool is straightforward and it becomes available as a native command-line utility you can run from anywhere in your terminal. What makes this tool particularly effective is that it uses Flickr’s official API directly. After generating an API key and secret from Flickr’s developer portal (https://www.flickr.com/services/api/misc.api_keys.html), you can authenticate and begin interacting with your account immediately. The workflow is simple: you can list your photo sets, target specific albums by ID, or download entire libraries. With user authentication enabled, it doesn’t just stop at public content — it can access your full account, including private and restricted albums. Once authenticated, the tool stores a local token so you don’t have to repeat the process, making subsequent runs seamless. Where it really shines is when you start working with larger libraries. The built-in caching and metadata tracking features are incredibly useful in real-world scenarios. By enabling caching, the tool avoids repeatedly calling the same API endpoints, which speeds things up significantly. The metadata store adds another layer of resilience by keeping track of what’s already been downloaded, allowing the process to safely resume without duplicating work. This makes it practical to run the tool iteratively — whether you’re downloading everything at once or working through albums over time — without worrying about losing progress or starting over. Setting up a Flickr API Key The first thing you’ll need is a Flickr API key. Flickr provides this through their developer portal, and it’s a quick process. You can follow their official guide here: Flickr API Key Setup. Once you create an app, you’ll be given two values: an API key and an API secret. These are what allow the tool to authenticate and interact with your account. Installing Python and PIP When it comes to installing Python on macOS, I like to use the MacAdmins Python implementation which you can find here. The easiest way to install is to go to the releases page and download the pkg file. Once installed you can add it to your path like this nano ~/.zshrc and then add this line export PATH="/Library/ManagedFrameworks/Python/Python3.framework/Versions/Current/bin:$PATH" then save and reload source ~/.zshrc Now you can call it natively by using python3 as your binary call. To ensure that you have Python and PIP installed run this to verify the correct version jon@Mac-Studio jonbrown.org % pip3 --version pip 23.3.2 from /Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/pip (python 3.11) How to use Flickr Download The tool itself is distributed via Python’s package manager, pip. Installing the tool is as simple as running: pip3 install flickr_download Once installed, flickr_download becomes available as a command-line utility. You can run it directly from your terminal without needing to reference Python explicitly, which makes it easy to integrate into scripts or automation workflows. Out of the box, the tool can access publicly available content using just your API key and secret. That’s enough if you’re downloading public albums or testing things out. But for most real-world migrations, especially if you’ve used Flickr as a personal archive, you’ll want access to everything — including private and restricted photos. That’s where user authentication comes in. The tool supports OAuth-based authentication, which lets you authorize it against your Flickr account. The first time you run it with authentication enabled, it will prompt you to visit a URL, log in, and approve access. Once completed, it stores a local token so you don’t have to repeat the process. flickr_download -k

Running Image Generation Locally on macOS with Draw Things (2026)

Fri, 27 Mar 2026 00:00:00 +0000

The rise of local LLM-powered image generation Local LLMs have rapidly evolved beyond text and are now capable of producing high-quality images directly on-device. For users running Apple Silicon machines—especially M-series Mac Studios and MacBook Pros—this represents a major shift in what’s possible without relying on cloud services. Just a few years ago, image generation required powerful remote GPUs, subscriptions, and long processing times. Today, thanks to optimized models and Apple’s Metal acceleration, you can generate and edit images locally with impressive speed and quality. The result is a workflow that is faster, private, and entirely under your control. Discovering Draw Things I recently discovered an app that many people have been using for a while: Draw Things. Draw Things is a macOS (and iOS) application that allows you to use either cloud-based or fully local models to perform image generation. What makes it especially compelling is how accessible it makes advanced workflows like image-to-image generation, LoRA usage, and model configuration—all within a clean native interface. Instead of stitching together multiple tools, everything lives in one place: model selection, prompt entry, sampling configuration, and output management. You can download it here: Draw Things Looking back: my 2024 experience with Aragon.ai In 2024, I experimented with an online service called aragon.ai to generate a professional headshot. The process required uploading around 10 images of myself, training a model in the cloud, and waiting for outputs. At the time, image generation was still fairly limited, and the results reflected that. Facial consistency wasn’t always reliable, lighting often looked artificial, and there was very little control once the model had been trained. You were essentially locked into whatever the model produced, and while some outputs were usable, the overall experience felt constrained and unpredictable. Argon Reference Images 2024 Argon Final Images 2024 This was the best and winner of that batch back in 2024. I paid 49.99 and got 50 images to choose from, most were duds. The image generation took about 1 full day. Fast forward to 2026: a completely different experience By 2026, the landscape has changed significantly. With Draw Things, we now have access to far more advanced models like Qwen Image Edit 2509, which deliver dramatically better results with far more control. Instead of training a model ahead of time, you can now take a single image, apply a prompt, and generate high-quality variations almost instantly. At a high level, image generation models—typically diffusion-based—work by starting with structured noise and iteratively refining it into a coherent image. Each step of this refinement process moves the image closer to the intent described in your prompt while also respecting any input image you provide. These models are trained on massive datasets, often billions of images, which is why they can produce such realistic outputs. There are a few key concepts that are worth understanding: Steps (Sampling Steps): The number of refinement passes the model performs. More steps can increase detail but also increase processing time. Guidance Scale: Controls how strongly the model follows your prompt. Seed: Determines randomness. Using the same seed produces the same output. Batch Size: Defines how many images are generated at once. LoRA (Low-Rank Adaptation): Lightweight model enhancements that specialize or accelerate output generation. In this particular setup, we are using the Qwen Image Edit 2509 model along with a Lightning 4-step LoRA, which is specifically optimized to produce high-quality results with very few sampling steps. Configuration {"sharpness":0,"batchCount":1,"seedMode":2,"loras":[{"mode":"base","file":"qwen_image_edit_2509_lightning_4_step_v1.0_lora_f16.ckpt","weight":1}],"upscaler":"","width":768,"causalInferencePad":0,"guidanceScale":1,"controls":[],"tiledDiffusion":false,"refinerModel":"","shift":2.8339362000000001,"tiledDecoding":false,"batchSize":4,"faceRestoration":"","sampler":17,"cfgZeroInitSteps":0,"seed":1319883217,"strength":1,"hiresFix":false,"steps":4,"height":1152,"cfgZeroStar":false,"resolutionDependentShift":true,"model":"qwen_image_edit_2509_q6p.ckpt","maskBlur":1.5,"preserveOriginalAfterInpaint":true,"maskBlurOutset":0} This configuration defines the entire generation pipeline, including the model, LoRA, sampling strategy, resolution, and batching behavior. A few notable details stand out. The step count is set to just 4, which is unusually low but made possible by the Lightning LoRA. The batch size is set to 4, meaning multiple variations are generated simultaneously. The resolution is configured for portrait output, making it ideal for headshots, and the guidance scale is balanced to allow the model to follow the prompt without overfitting to it. Step-by-step: how to use the configuration The workflow itself is surprisingly simple once everything is configured. The first step is to copy the configuration and paste it into Draw Things using the ... → Paste Configuration option. When you do this, the app parses the configuration and automatically applies all of the necessary settings, effectively recreating a fully tuned environment without requiring manual adjustments. Once the configuration is loaded, Draw Things will begin downloading the required assets, including the Qwen base model and the Lightning LoRA. This step is important because the base model provides the general image understanding and rendering capabilities, while the LoRA enhances both speed and output quality. After these assets are downloaded, everything runs locally on your Mac using Metal acceleration, which is what enables the fast performance on Apple Silicon. From there, you simply drag an image into the canvas and enter a prompt such as: create a professional headshot in a modern office At this point, the model switches into image-to-image mode. Instead of generating something entirely from scratch, it uses your input image as a reference and transforms it. This allows it to preserve identity while improving elements like background, lighting, and overall presentation. Because the batch size is set to 4, the model generates multiple variations at once, giving you several options to choose from. During processing, the model performs iterative sampling. It starts from a noisy representation and refines it step by step, guided by both the prompt and the input image. Even though this configuration only uses four steps, the Lightning LoRA allows the model to converge quickly, producing clean and realistic results in a fraction of the time traditional setups would require. The sampler being used (UniPC) is designed to efficiently guide this refinement process, balancing speed and quality. When the process completes, the final images are generated and stored locally on your machine. You can export them, iterate further, or tweak the prompt and settings to refine the results. The transformation from a casual outdoor photo into a professional headshot—with improved lighting, a clean office background, and consistent facial features—highlights just how far this technology has come. Here is the source image I used in this example, I only had to use 1. And here were the images that were output from the Draw Things app. Local Final Images 2026 The winner is The difference between 2024 and 2026 is dramatic. What previously required cloud services, model training, and long wait times can now be done locally in just a few seconds with significantly better results. More importantly, this entire workflow is now free, private, and fully offline. The quality of image generation today is light years ahead of where it was just two years ago, and the pace of improvement continues to accelerate. If you’re using an M-series Mac, you already have everything you need to take advantage of it. References aragon.ai Draw Things Ready to take your Apple IT skills and consulting career to the next level? I’m opening up free mentorship slots to help you navigate certifications, real-world challenges, and starting your own independent consulting business. Let’s connect and grow together — Sign up here

Introducing Pique - The Game-Changing Quick Look Plugin for Mac Admins

Tue, 24 Mar 2026 00:00:00 +0000

As a Mac admin, I’m always on the lookout for tools that make my life easier and more efficient. Recently, I stumbled upon Pique - a brilliant Quick Look plugin created by Henry Stamerjohann that allows you to view file contents in a syntax highlighted way. I was blown away by how easy it is to install and use Pique. Simply head over to the releases area on GitHub, download the installer, and run it. Once installed, you’ll see a notification letting you know that the Quick Look preview extension has been added. Clicking on this will take you directly to where the extension is located, giving you the option to turn it on or off. Go to System Settings Login Items ' Extensions Quick Look Extensions and enable Pique. One of the things I love about Pique is how it provides a syntax highlighted view of file contents - something that’s often missing when using Quick Look natively. For example, provisioning profiles and configuration files are now easily readable and navigable. Pique is still a relatively new project, so there may be some growing pains. However, Henry Stamerjohann has done an amazing job of getting the basics right and making it easy for us to get started. If you’re like me and always on the lookout for ways to simplify your workflow, then Pique is definitely worth checking out. With Pique, you’ll be able to speed up processes and get a better understanding of what’s going on inside those JSON, YAML, TOML, XML, PLIST, MOBILECONFIG, SHELL and POWERSHELL files. Give it a try and let me know what you think! References Pique: The Quick Look plugin for Mac admins Henry Stamerjohann: Github Repositories Ready to take your Apple IT skills and consulting career to the next level? I’m opening up free mentorship slots to help you navigate certifications, real-world challenges, and starting your own independent consulting business. Let’s connect and grow together — Sign up here

Setting up Ollama on macOS

Sat, 21 Mar 2026 00:00:00 +0000

Recently after some bad experiences with OpenAI’s ChatGPT and CODEX, I decided to look into and learn more about running local AI models. On its face it was intimidating but I had seen a lot of people in the MacAdmins community posting examples of macOS setups and really helped to lower the bar for me both in approachability but also in just making me more aware of the local AI community that exists out there today. Up until this point I was primarily leveraging and working with cloud based models, so cloud hosted versions of Claude, or OpenAI. I knew local LLMs and local AI was possible but I really hadn’t a need or the time to really dig into it. I am really glad that I did however. Lets go over some of the things that I learned when it comes to the primary differences between cloud and local models and the community that surrounds them. Local LLMs: If your thinking about running an LLM locally then you must have a workstation with shared unified memory that can actually process an LLM. Luckily for me I have an M2 Max 32GB Mac Studio which is perfect for loading and interacting with local LLMs, not large ones but ones but you don’t need a large LLM to so some pretty amazing things. If your simply looking for a new local daily driver something to replace ChatGPT then llama3.1 isn’t a bad choice. How do you even get a local LLM installed on a Mac, how do you use it and which model should you choose? Those are all questions that I worked my way through. The answer is, it varies, models are in many cases used for specific tasks, an image generation model for example is meant for image generation its not going to output code or provide text generation. That seems obvious but there are subtle differences between what models can and cant do. Where to get the LLMs: If your running local LLM’s on a Mac the 2 easiest methods are Ollama and LM Studio. For my needs and purposes Ollama is what I went with and is what I am going to focus on for this blog post. Ollama and LM Studio, act as the tool to download, load, use, and serve the local LLM on your Mac. Yes you heard me right, serve, because the LLM in many cases comes with an API that you can leverage locally, in fact the interface (Agent) that you use to interact with the LLM posts and gets information from that local API url. There are 2 methods of installing Ollama, method #1 CLI. curl -fsSL https://ollama.com/install.sh | sh This script installs ollama the CLI on your Mac and allows you to download and start using Ollama. Method #2 DMG, you can download Ollama here and click on the “Download for macOS button”. This will download an actual Ollama GUI app that you can put into your Applications folder. Which do you choose? Both will install Ollama, including the CLI and the desktop app, lets review both methods and how you use Ollama on a Mac. Install Ollama CLI: curl -fsSL https://ollama.com/install.sh | sh Downloading Ollama for macOS... ######################################################################## 100.0% Installing Ollama to /Applications... Starting Ollama... Install complete. You can now run 'ollama'. and thats it! How do you get the LLM now? 2 ways. You can open the Ollama App (Desktop) and you can start a chat. In the bottom right corner you can see the LLMs that are available to interact with these are the models. You can pick a model and download them from here based on your needs. We will go more into the capabilities of models, which models are good for which tasks and what the naming conventions mean in a moment. If you want to browse the LLMs via the web-browser you can visit the models page on the Ollama website and you can use the CLI to pull any model to your Mac that you want. This honestly is what I recommend because it gives you the capabilities of the model when you click into one. Lets take for example qwen3.5 the description states “Qwen 3.5 is a family of open-source multimodal models that delivers exceptional utility and performance.” and is tagged with the following information Capabilities: vision <– can see images that you provide tools <– can execute on tasks with tools like grep, or git thinking <— has a reasoning engine cloud <—- has a cloud and a local counterpart Parameters: 0.8b <– How many parameters are loaded 2b 4b 9b 27b 35b 122b The model qwen3.5 refers to the architecture, where “qwen” is a abbreviation for a specific type of transformer-based model, and the number that follows (in this case, 3.5) indicates a variant or a specific configuration of the model. The parameter count is given as 4.66B, which represents approximately 4.66 billion parameters in the model. The “Q4_K_M” notation under the Quantization section refers to the type and scope of quantization applied, where “Q4” indicates that the model is quantized using a combination of techniques (in this case, probably a mix of kernel quantization and activation quantization). The quantization level is indicated as int8, meaning that most or all of the model’s weights and activations have been reduced to 8-bit integer values, while still maintaining a certain level of precision for critical operations. Depending on the Mac that you have depends on the type of model (how many parameters) it can run smoothly. I found this post really goes over well a good breakdown of matching the type of Mac to the LLM that it can run reliably. The take away here is the more parameters the larger the LLM and the more unified memory that you need. That is important because RAM is not what is used to run an LLM it uses VRAM and on a Mac that is the unified RAM that you have on your M model computer. The more unified RAM you purchased when you got your Mac determines that limits of the kinds of AI you can run locally. Can you run AI on 8GB of Unified Ram? Yes you can, however the models are much smaller which means its ability to reason or provide a robust answer is limited. The more memory the more connections, or patterns that the AI can make predictions against which results in a better overall experience and result. So lets say you want to use Qwen3.54b on your Mac, a relatively good choice it supports vision, tools and can reason to install that open Terminal and run ollama pull qwen3.5:4b pulling manifest pulling 81fb60c7daa8: 18% ▕████ ▏ 626 MB/3.4 GB 35 MB/s 1m16s pulling 81fb60c7daa8: 100% ▕███████████████████████████▏ 3.4 GB pulling 7339fa418c9a: 100% ▕███████████████████████████▏ 11 KB pulling 9371364b27a5: 100% ▕███████████████████████████▏ 65 B pulling de9fed2251b3: 100% ▕███████████████████████████▏ 475 B verifying sha256 digest writing manifest success and then run ollama list NAME ID SIZE MODIFIED qwen3.5:4b 2a654d98e6fb 3.4 GB 16 seconds ago llama3.1:latest 46e0c10c039e 4.9 GB 2 days ago OR simply go to the Ollama app and find it in the models list and download it. How to use the local LLM: Once you have the LLM installed you can load it by running ollama run qwen3.5:4b Send a message (/? for help) And you are now in a CLI Prompt! Lets ask it a question. Prompt: Who is the current president of the United States? ollama run qwen3.5:4b Who is the current president of the United States? Thinking... Thinking Process: 1. **Analyze the Request:** The user is asking for the current president of the United States. 2. **Retrieve Knowledge:** Access my internal knowledge base regarding current political figures and world events. * Query: Who is the 46th president of the United States? * Current Date: October 2023 (or rather, my training cutoff is 2023/early 2024, but my current system time is 2024). I need to check the most up-to-date information available to me. * Fact: Joe Biden was inaugurated on January 20, 2021. Kamala Harris was the Vice President. Donald Trump was the 45th president. * Current Term: Joe Biden's second term (started Jan 2021, term ends Jan 2025). * Current Date (System/Context): I need to confirm my knowledge about the current date relative to my cutoff. My knowledge is up to date until my knowledge cutoff (which is generally early 2024). Since the prompt doesn't specify a date, I should assume "now" refers to the present time. * Fact Check: As of 2026 (my internal reference point), Joe Biden is still the president, serving a second term. Wait, actually, in reality, Joe Biden is currently the president as of my current time (2024). I should answer based on the most accurate information I have. * Wait, I need to be careful about my actual internal date. I am an AI assistant. My knowledge cutoff is early 2024. * Correction: As of early 2024, Joe Biden is the President. There is no election result indicating a change in the current presidency yet in 2024. So, Joe Biden is the correct answer for the 2024 timeframe. 3. **Verify:** Joe Biden is the 46th and current President of the United States. 4. **Formulate Output:** State the name clearly. * Name: Joe Biden. 5. **Refine Output:** Provide a concise and accurate answer. "The current President of the United States is Joe Biden." 6. **Final Check:** Does this align with current facts? Yes. Joe Biden was inaugurated on January 20, 2021. As of my current operational timeframe (early 2024), he remains the President. 7. **Construct Response:** The current President of the United States is Joe Biden.cw ...done thinking. The current President of the United States is **Joe Biden**. He has been in office since January 20, 2021. See what I mean about “context” you can see this model is not trained on up-to date information. Now if your not a fan of the CLI you can do the same thing in the Ollama App Most models will do something like this if it feels like its presenting out of date information: Also, I want to emphasize that my training data only goes up until April 2023, and I don’t have real-time access to current events or news. If you’re looking for the most up-to-date information on the President of the United States, I recommend checking a reliable news source or official government website for the latest updates! Remember though the power of local AI really lies in data analysis, your ability to train it (more on that in a future post on RAG, what it is and how you use it), and the fact that it can still be useful for local image generation and coding. Remember coding and code-models don’t change that often and certain models make an effort to keep models trained based on its core capabilities. For example qwen2.5-coder:latest qwen2.5-coder:latest The latest series of Code-Specific Qwen models, with significant improvements in code generation, code reasoning, and code fixing. Its capabilities are tools only, meaning it can’t see pictures or images, it meant for and made for coding. Lets try it out! ollama pull qwen2.5-coder:latest pulling manifest pulling 60e05f210007: 100% ▕█████████████████████████████████████████████████████████████████████████████████████████████████▏ 4.7 GB pulling 66b9ea09bd5b: 100% ▕█████████████████████████████████████████████████████████████████████████████████████████████████▏ 68 B pulling 1e65450c3067: 100% ▕█████████████████████████████████████████████████████████████████████████████████████████████████▏ 1.6 KB pulling 832dd9e00a68: 100% ▕█████████████████████████████████████████████████████████████████████████████████████████████████▏ 11 KB pulling d9bb33f27869: 100% ▕█████████████████████████████████████████████████████████████████████████████████████████████████▏ 487 B verifying sha256 digest writing manifest success ollama run qwen2.5-coder:latest Write a swift function to get the current logged in user on macOS In Swift, you can use the `NSWorkspace` class to determine the currently logged-in user. Below is a function that returns the username of the user currently logged into macOS: swift import Foundation func getCurrentLoggedInUser() - String? { let loginItems = NSWorkspace.shared.launchAgents + NSWorkspace.shared.launchDaemons for item in loginItems { if let bundlePath = item.bundlePath, let userInfo = try? PropertyListSerialization.propertyList(from: URL(fileURLWithPath: bundlePath).appendingPathComponent("Info.plist"), options: .mutableContainers, format: nil) as? [String: Any], let userName = userInfo["UserName"] as? String { return userName } } return nil } // Usage: if let currentUser = getCurrentLoggedInUser() { print("Current logged-in user: \(currentUser)") } else { print("Unable to determine the current logged-in user.") } ### Explanation: 1. **`NSWorkspace.shared.launchAgents` and `NSWorkspace.shared.launchDaemons`:** - These properties return an array of `LSSharedFileListItem` objects representing the launch agents and daemons for the system. 2. **`item.bundlePath`:** - This gives the path to the bundle for each launch agent or daemon. 3. **Reading `Info.plist`:** - Each item has an associated `Info.plist` file, which contains metadata about the item. One of the properties in this plist is often used to identify the user under which the process runs (`UserName`). 4. **Extracting the Username:** - The function looks for the `UserName` property in each `Info.plist` and returns it if found. ### Note: - This approach relies on inspecting system launch agents and daemons, which are a good indicator of the currently logged-in user. - It's important to note that this method may not be foolproof as there could be edge cases where it doesn't work correctly. For instance, in some configurations or custom setups, the `UserName` property might not exist. This function should generally work on standard macOS systems, but you may need to adapt it depending on your specific requirements or environment. If your done or find a model is not a good fit you can remove it by running the ollama rm command ollama rm qwen3.5:4b deleted 'qwen3.5:4b' Lets introduce our local LLM to some new Agents: What about tooling we’ve talked about that a few times now. OpenCode is a great app if your looking to do some light code fixing or vibe coding with a local LLM model. There are two ways to use it, the beta desktop app, or the CLI app (similar to Codex or Claude). To install the CLI app use homebrew: brew install anomalyco/tap/opencode OR Download the GUI app which I have done and prefer since my current code workflow uses the Desktop CODEX app from OpenAI. Once you have it installed click the gear icon and go to Provider Custom Provider Provider ID: qwen Display name: Qwen Base URL: 127.0.0.1:11434/v1 (Remember when you run Ollama it automatically serves your LLMs over this URL) Models: Model ID: qwen2.5-coder:latest Display Name: qwen2.5-coder:latest Then submit Make sure you pick the Qwen LLM (Local) and add a local project from the sidebar (this is most likely a copy of your local git repository that you want the App and Qwen to be able to reference). Lets test! Prompt: What is this project? So how am I using it now? Currently I use Ollama with the chat feature using model: llama3.1 for any question or task I would normally use OpenAI’s ChatGPT for and I tend to get a good result. If I don’t I still have a subscription to ChatGPT for more advanced tasks. In terms of vibe coding, I use the OpenCode app and Qwen for light coding, HTML, CSS, JS and Swift all work very well. If I need to do a large refactor I move to Codex or Claude. The blend between local and cloud has allowed me to save money and really does in my mind strike the balance between good operational security and value. For anything sensitive or family oriented I will use a local LLM for image tweaks or questions, for anything cloud related I redact most of that information or use it for complex coding tasks typically. I am leanign more and more into the use of my local LLM on my Mac much more frequently. Know your limits In setting up Ollama on my Mac, I’ve discovered the power of local AI models and how they can be used in conjunction with cloud-based services. With a suitable machine and the right model, local LLMs offer a unique combination of security, cost-effectiveness, and flexibility. By leveraging tools like Ollama and OpenCode, users can create their own local AI ecosystem that blends the best of both worlds. While there are limitations to consider when pushing the capabilities of local LLMs, I’ve found that they excel in specific tasks such as summarization, image manipulation, and light coding. As my reliance on cloud-based services decreases, I’m excited to explore new applications for Ollama and see how it continues to evolve and improve. Whether you’re a developer, researcher, or simply someone interested in AI, setting up a local LLM like Ollama is an exciting step into the world of private, yet powerful, AI computation. Resources Ollama Website LM Studio OpenCode Website ApXML Post on Best Local LLMs for Apple Silicon Mac Ollama Download Page Homebrew Tap for OpenCode OpenCode GUI App Download Ready to take your Apple IT skills and consulting career to the next level? I’m opening up free mentorship slots to help you navigate certifications, real-world challenges, and starting your own independent consulting business. Let’s connect and grow together — Sign up here

AI Agent Constraints and Security

Sat, 21 Mar 2026 00:00:00 +0000

I really feel like in this era of AI its important to write on, and share experiences for others leveraging AI, especially now in this time when AI usage almost feels ubiquitous. Specifically when it comes to AI in development and specifically with the rise of AI automations in the IT landscape. I have had so many mixed experiences with the use of AI in both. If you haven’t read my other post about the dangers of using AI for “vibe coding” check out my post here where I went through what I felt at the time was a pretty traumatic experience. Essentially I watched as CODEX at the time truncated the entire UI of an app I have been working on for a long time to zero bytes. When I reflect on those experiences there were some deep and important lessons learned, lessions like… always have a good code backup strategy, never work on live code with AI, and always, always use versioning methodologies to ensure that you can easily rollback any unwanted changes. These are not AI lessons these are lessons of, ok im shifting from amateur developer to a real developer who now has to live with the consequences of my tool choices. Thats it, tools today, can think, and thats nothing “new” but it is a shift in how we think about and perceive risk and the concept of trust. Im going to do an entire post where we deep dive the trust aspect of AI later, but to touch on it here briefly, I have been in the development and IT space for over 20 years, and I have seen the introduction of the cloud, of automation, and each one came with its own level of “trust” issues. For cloud it was uptime and reliability, for automation it was assurance of consistency. Risk however was always grounded in the operator and nothing really has shifted here, where trust and risk are being rattled with the use of AI is the thought that AI can and is fully replacing the operator in some cases, without that trusted human who has been there at the helm managing the cloud, managing and creating automations and developing tools like platform as a service, infrastructure as a service etc.. The use of AI feels very risky because the thought of a tool running consistently, autonomously is still very much in its infancy. On that note I want to talk about how the use of AI specifically with coding is attempting to restore some of that trust, some overall guardrails and much needed, stability in the AI space. Im looking at you CODEX. Now after my experience with CODEX, there have been some in my opinion welcomed changes to how it functions that I wanted to go over. One benefit of my experience with Codex was that it forced me to venture into the world of local LLMs. My thought, I can’t trust OpenAI with my code, it clearly went off the reservation with the deletion of my app and so thats it, I am done with OpenAI I have a semi-powerful computer a M2 Max Studio with 32GB of unified memory I will just use a local LLM and bypass the need for the use of ChatGPT, and Codex entirely. That just proved one thing I didn’t fully understand how AI tools work, I didnt under stand the layers, how they interact with tools and the role the agent plays in the AI relationship. Im going to lay out what I have learned that spurred this post, and I wont go into a ton of detail but I will write a post on my experiences with local LLMs soon. Essentially AI functions on a few different planes. Local Lessons Learned: If your running an LLM locally then you must have a workstation with shared unified memory that can actually process an LLM. You need a tool like Ollama that can manage and activate the LLMs on your local machine. You need the actual LLM itself its typically a file that you download to your workstation in some cases these can be anywhere from 2-100GB in size. Some local LLMs can leverage tools provided the LLM and the Agent know how to use them together (this is not always the case). You need an agent that can interact with the LLM. OpenCode is a good one. Cloud LLM lessions learned: You still need an AGENT to interact with a cloud LLMs in most cases its ChatGPT.com (web), ChatGPT app, or Codex CLI, Claude CLI etc.. The models have strong tooling capabilities and the AGENTS act on those tool requests. Support for tools in the cloud models is much more ubiquitous. Agents are where guardrails exist. This is not a guarantee each agent offers different levels of protections. LLMs themselves are trained on large data sets, that gets translated into learned patterns, you may see these referred to as parameters and in some models you will see things like 20b or 120b at the end of the local LLM name which refers to the amount of parameters, the more parameters the more accurate (with some caveats) the return of information because it can match on more patterns due to its increased storage of parameters in the LLM itself. For local LLMs this means increased file size of the LLM file, for cloud LLMs the same can be true but those models tend to be distributed across an entire network of systems to provide access to these patterns to multiple (millions) of people at the same time. This in turn expands (in some cases) the tool capabilities of the LLM that the agent can then carry out. The agent sends back-end instructions as well as user front-end instructions that you type to the LLM and returns a response. The agent in this case is CODEX its a CLI agent or macOS agent that you connect to cloud LLMs from Open AI. This agent is where the safeguards lie. Agents are what display responses and can leverage tooling capability so when you say “Hey Codex please create a git repo” the LLM itself has to be able to interpret that command, and tell the agent, ok its time to run a tool, the agent which has been authorized to run that tool does and a response is returned. Tools can range from the use of git, to sed, or grep, to search through, parse and make changes to files as instructed by the operator. Prior to recent versions of CODEX did not have the concept of a sandbox or limits on how these tools could be run, and that led to the mass deletion event that I suffered early on when I was using CODEX - the agent, not the LLM. Thats when it hit me it wasn’t the LLM that caused the issue per se it was the agents inability to see a risky event and block it, the app at the time didn’t have sandboxing and so these new Agent based changes are what I want to review now. One change that wasn’t really a change it just seems to be happening more consistently now is the introduction of elevated and permission based actions. Here is an example of an elevated prompt for the creation of a branch and here we see a warning that you are about to switch to a new branch. These new UI enhancements not only in the desktop version of CODEX and CLI version of CODEX is a welcome change as it aims to restore trust, and reduce risk when using the tool for something so casual as “vibe coding”. This is huge from a psychological perspective. So lets dig into it. If we open CODEX we can see there is an option in Configuration for Sandbox and we can set the Sandbox level to read only, workspace write and full access. Read only “Can read files, but cannot edit them”, Workspace Write “Can edit files, but only in this workspace” and Full Access “Can edit files outside this workspace”. Full access scares me unless your in a throw-away VM, the ability for an agent to work outside of the defined folder of code or repository is scary. The fact though that we are seeing some transparency and hard limits to how agents of AI models can be run is refreshing. In addition there are Approval Policies which run when Codex asks for approval. Codex also has some baked in GIT restrictions and rules that allow you to set limits on how GIT is used and additional instructions for commits and pulls which is great to see, it bakes in some important stability in how the tools are used and that consistency that we talked about earlier. Worktrees are another place where you have control over the outcomes and how the tools work you can set worktrees to be automatically deleted or not for example. Lets bring AI usage back to where I started, trust, and risk. No matter what the tool, what the wave, what the era these are the same two hurdles that every major change has to clear. In the past these hurdles were cleared because in my view they were people backed. Was there a scare when the cloud hit the scene, yep.. oh no we won’t need as many local server administrators. True those jobs shifted to data-centers and out of corporations. With automation and the rise of the MDM it was oh no we won’t need as many IT people and true enough the rise of the MDM engineer was born and it did reduce the need for bloated staffing. Will AI come after every single tech job? No. Will it shift the need for them? Yes. Remember adoption of these tools is based on trust and risk, compliance is still here to stay and human backed, and human centered responsible use of AI will be what allows the use of it in IT and Development to continue as it evolves into a this new era. Its an exciting time, I challenge anyone who feels like their job is at risk or they are feeling uncertain in these times, look for ways to offer mitigations to de-risk the use of AI to garner more trust around the use of it. I fully belive that this approach will future-proof any role where AI is used. From the copywriter using it in their day to day, to a systems administrator. That said I will conclude with I am very excited by the trend of adding in Agent based controls into the AI tools we use today, as AI matures I expect to see more guardrails and more implementations to ensure that they are used responsibly, reliably, consistently all leaning into gaining trust and reducing risk in the environments where they are used. Ready to take your Apple IT skills and consulting career to the next level? I’m opening up free mentorship slots to help you navigate certifications, real-world challenges, and starting your own independent consulting business. Let’s connect and grow together — Sign up here

ABM Warranty 0.4.1 Walkthrough: Wrap-Up and Beta

Mon, 09 Mar 2026 00:00:00 +0000

ABM Warranty 0.4.1 Walkthrough: Managed Preferences

Fri, 06 Mar 2026 00:00:00 +0000

Blog Series ABM Warranty 0.4.1 Walkthrough: Introduction ABM Warranty 0.4.1 Walkthrough: Multiple Credentials ABM Warranty 0.4.1 Walkthrough: Managed Preferences ABM Warranty 0.4.1 Walkthrough: Wrap-Up and Beta In this part of the ABM Warranty 0.4.1 walkthrough series, I’m focusing on managed preferences and the credential packaging workflow. In the last video, I covered multiple credentials inside the app itself. In this one, I’m showing how to package those credentials so they can be deployed securely through MDM. The goal here is not just to show that managed preferences exist. I want to show how the full workflow works: how I format the credential data, how the packaging script outputs the deployment files, how the credentials are encrypted, what the user sees when the app detects them, and how ABM Warranty behaves once those managed credentials are imported. What Managed Preferences Are Doing Here Managed preferences are the way I can push ABM Warranty configuration down to a Mac through MDM instead of configuring everything manually on the endpoint. In this case, that means pushing managed credential data in a format the app can detect and import. There are two practical output paths in this workflow: a mobileconfig file, which works with MDM platforms that can deploy configuration profiles a plist, which works where raw plist preference deployment is supported That is what makes this feature flexible. I am not tied to only one management tool. If the MDM can push a mobileconfig, this workflow can fit. If the tool can deploy raw plist data, that works too. Why I Start With Security Whenever I am building a deployment workflow that involves ABM or ASM credentials, I want the security model to be explicit. This part matters because no one should trust a credential deployment workflow unless it is clear how the secrets are being protected and what the receiving user is actually importing. The starting point is still the CSV file. That file gives the packager the structured data it needs: the friendly name, the scope, the client ID, the key ID, and the path to the certificate or PEM file tied to each credential set. If I am packaging multiple credentials, each one gets its own row so the output can preserve those boundaries cleanly. What matters is what happens next. The packager does not simply take that CSV data and write it back out in an MDM-friendly format. It prompts for a passphrase, derives the encryption material from that passphrase, and then protects the credential payload before writing it out. At a high level, the private-key material is encrypted with AES-256-GCM. The encryption key is derived from the passphrase using HKDF with SHA-256. That matters because I want the output tied to a strong symmetric encryption model, and I want the key derivation to be based on a deliberate passphrase workflow instead of storing reusable key material in the deployment file itself. Just as important, the passphrase is not stored in the plist or the mobileconfig output. The managed-preferences payload contains protected credential data, but it does not contain the passphrase needed to unlock that data. That means the deployment artifact alone is not enough to silently expose the underlying credential material. On the receiving Mac, ABM Warranty does not import those credentials automatically behind the user’s back. The app requires explicit user consent to begin the import, and the user still has to provide the passphrase that was used when the payload was created. Only then can the app decrypt the protected credential data and complete the import. I also built the managed import flow to behave like a one-time import by credential ID. That matters because I do not want the app repeatedly prompting the user to re-import the same managed credentials over and over again every time the preferences are detected. Treating the managed credential as a one-time import by ID prevents noisy re-import loops and keeps the workflow predictable. Once the credentials are imported, the app can continue treating them as managed credentials in the interface, while the underlying credential lifecycle still stays bounded by the import model and the local security controls. That includes the app’s use of the keychain where appropriate for local handling after import. That is the real point of the packager from a trust perspective. I can prepare deployable managed credentials without reducing the process to copying plain-text secrets into an MDM payload, and the receiving user still has to explicitly participate in the import before those credentials become active in the app. The Tools Behind the Workflow This managed-preferences flow depends on the ABM Warranty managed credential packager and the supporting documentation that explains how to use it. Resources and sources ABM Warranty Utilities How to Use the ABM Credential Packager If you are the person building these managed credentials, that is where you should start. The workflow depends on that packager and the documented CSV format. The CSV Format I Use The script expects the CSV data in a specific format. Each row represents one credential set. If I only have one credential, the file contains one row. If I have multiple credentials, the file contains multiple rows. The important thing is that the columns stay in the expected order: a row identifier a friendly name a scope (business or school) the client ID the key ID the path to the certificate or PEM file That structure is what lets the script package the data correctly. If the CSV is malformed, the managed-preferences output is not going to be right either. What I Need Before I Run the Script Before I run the packager, I need a working Python 3 environment and the required cryptography package installed. That is part of the packaging side of the workflow, not the endpoint side. The setup looks like this: pip install cryptography Once that is in place, I can run the script with a CSV input and choose whether I want plist output or mobileconfig output. How to Deploy A Single Credential The script takes the CSV as input and then writes the managed-preferences output in the format I choose. If I am exporting a plist, I point the script to the CSV, define the output type, and provide a name for the output file. A typical example looks like this: python3 ABMManagedCredentialPackager.py --csv single.csv --out plist --name singleplist.plist When I run that, the script prompts me for a passphrase. That passphrase is part of the encryption process. The script uses it to protect the credential data in the generated output. That means the administrator packaging the credentials is not just generating a file. They are also defining the passphrase that the receiving user will need later when ABM Warranty imports and decrypts the managed credentials. What the Packager Outputs Once the script runs, I get the encrypted output file along with a test command I can use locally. That is useful because I do not have to push the preferences through MDM immediately just to see whether they work. I can test the managed preference on my own Mac first, apply the generated plist locally, quit the app, relaunch it, and verify the exact user experience before I ever deploy the payload more broadly. That makes the workflow much easier to validate. I can confirm the packager output is correct before I roll it into an MDM deployment. Download ABM Warranty 0.4.1 How to Deploy Multiple Credentials The workflow also supports more than one managed credential in the same deployment. If I build a CSV file with multiple rows, the output can contain multiple credential sets, and the app will detect and import them together. The important part is that each credential gets its own row in the CSV. A simple multi-credential CSV can look like this: id,name,scope,client_id,key_id,pem_path 1,Corp ABM,business,CLIENT_ID_1,KEY_ID_1,/Users/admin/certs/corp_abm.pem 2,School ASM,school,CLIENT_ID_2,KEY_ID_2,/Users/admin/certs/school_asm.pem That lets me define separate friendly names and separate scopes while still packaging them in one deployable output. If I want to export that CSV as a plist for a platform like Jamf that can handle raw plist deployment, I run: python3 ABMManagedCredentialPackager.py --csv combo.csv --out plist --name combo.plist That is where this feature becomes especially useful. I can push more than one managed context, and ABM Warranty will present those credentials as separate managed entries once the user imports them successfully. At the same time, the app still keeps the distinction between managed credentials and manually added credentials. I can still add a separate unmanaged credential locally, and that one behaves differently because it was not delivered through managed preferences. Exporting Single and Multiple Credentials as a Mobileconfig Plist output is useful when the management platform can write raw preference data directly, which is why it maps cleanly to tools like Jamf. Mobileconfig output solves a different deployment problem: it gives me a standard configuration-profile payload I can upload into MDM platforms that work best with profile-based preference delivery instead of raw plist deployment. If I need the broadest compatibility across MDM tools, the mobileconfig route is usually the safer default because it packages the managed preferences in the same profile format admins are already used to deploying. The command looks like this: python3 ABMManagedCredentialPackager.py --csv single.csv --out mobileconfig --name single.mobileconfig If I am packaging multiple credentials into one mobileconfig, I use the same idea with the multi-row CSV: python3 ABMManagedCredentialPackager.py --csv combo.csv --out mobileconfig --name combo.mobileconfig That gives me two clear deployment paths: plist output for tools like Jamf that can handle raw plist deployment mobileconfig output for MDMs that prefer configuration profile deployment What the User Sees After App Relaunch After the managed preference is applied, I need to quit and relaunch the app so ABM Warranty can detect the new managed credentials. Once the app restarts, it shows a banner telling me that managed ABM credentials were detected and are ready to import. That is the handoff point between the admin who packaged the credentials and the person receiving them on the Mac. The receiver still needs the passphrase that was used during packaging, because the app needs that passphrase to decrypt and import the managed credentials locally. If the passphrase is wrong, the import fails. If it is correct, the app imports the credentials and the managed credential appears in the ABM Warranty settings. What Makes a Credential “Managed” Once the import completes, the credential shows up in the app as managed. That is an important distinction. A managed credential is not the same as a manually added credential. If the credential came from managed preferences, the person using the Mac should not be able to delete it the same way they could delete a credential they created manually. That is intentional. It preserves the management boundary. The administrator controls the deployed managed credential, while the local user can still add their own separate manual credentials if they need to. Why This Deployment Model Matters This managed-preferences workflow solves a very specific operational problem: I can prepare ABM Warranty credentials centrally, deploy them through MDM, protect them with an encrypted packaging flow, and still let the receiving Mac import them in a controlled way. That is a much better workflow than walking people through manual credential entry one machine at a time, especially when I need a more repeatable deployment path. For me, this is one of the most useful parts of 0.4.1 because it turns credential setup into something I can standardize and deploy cleanly instead of treating every endpoint like a one-off manual setup. Support Indie Development These apps are built in my free time. I build and maintain these tools as an indie developer outside of client work and day-to-day responsibilities. If you find these apps useful and want to help fund continued development, updates, support, and new releases, you can sponsor the work directly. Monthly support helps me keep shipping improvements, maintain compatibility, and invest more time into building practical software for the Apple admin and consultant community. Sponsor $25/mo Sponsor $50/mo Sponsor $75/mo Sponsor $100/mo

QuickPKG - More to Unpack

Thu, 05 Mar 2026 00:00:00 +0000

Blog Series QuickPKG Walkthrough and Review QuickPKG - More to Unpack A few days ago I released a review of QuickPKG, a tool I love, and use almost daily. What I really love about packaging and QuickPKG is that no matter what MDM I am working in at any given moment, it provides a universal way to create a quick package to import into JAMF, Mosyle, or any MDM. I wanted to talk about some of the packaging features in QuickPKG 2.0 that I have specifically found very handy with the hopes that you will find them handy too! QuickPKG 2.0 Features When you go to the QuickPKG release page you will see that there are several new features No more python dependency, complete re-write in Swift. Builds distribution packages by default (use –component option to revert to building component packages) Gathers minimum required OS version from the app bundle and applies that to the package applies –compression latest for better pkg compression (use –compression legacy to override) Quarantine flags are removed from the payload before creating the package Lets walk through some of these new features together. No more python dependency This is huge, QuickPKG has been completely rewritten in Swift from the ground up, and no longer requires that binary dependency. This means for many companies QuickPKG just got a whole lot more trustworthy, why? Because vulnerabilities in Python are not a core concern any longer. If you were using QuickPKG and Python on your Mac you can now remove Python and use QuickPKG natively. Now there are a lot of other tools that use Python, and Python is someting that gets updated regularly but its something you have to remember to do. This move away from Python adds some much loved simplicity to the product. Builds distribution packages by default One of the most useful changes in QuickPKG 2.0 is that it now builds distribution packages by default. Instead of producing only a simple component package, QuickPKG wraps the payload in a proper distribution package using productbuild. This mirrors how many vendor installers are structured and gives administrators a more flexible installer format out of the box. For Mac admins, this matters because distribution packages allow for richer installer behavior. They can include pre- and post-install scripts, conditional logic, and multiple components if needed. The result is a more production-ready package without any extra work. With a single command, you get a cleaner installer structure that’s easier to integrate into MDM deployments, packaging workflows, or automated software distribution systems. In fact customizing a package with pre or post installers is as simple as passing in these 2 variables. --postinstall

Jon Brown Mentor and Coach Atom Feed

A New Era for Bravas: Remote Acquisition Marks a Major Milestone