When Apple finally released the API for Apple Business & School Manager last year I was thrilled. I took it as an opportunity to try and create a Swift CLI for it which ended up being asbmutil, a Swift binary that directly communicates with the Apple School & Business Manager API. I posted it in the MacAdmins Slack, didn't think much about it, and it ended up getting used by folks — along with requests to make it better.

Today I'm shipping ASBMUtil.app, a native SwiftUI front-end on top of the same engine. Same credentials store, same API client, same bulk operations — inside a native Liquid Glass Tahoe app.

Not every Mac admin wants to live in the terminal. Even a well-built CLI carries its own friction — "here's the command, make sure the profile is set, redirect jq somewhere, don't forget the –mdm flag…"

Hence the GUI app. Same engine underneath, same credentials store, same API client.

What's in the App

The main view is a single native table with every managed device in your Apple Business & School Manager account — Macs, iPads, iPhones, Apple TVs, all of it — right next to each other. Click a row and a sidebar slides in with the full device details: serial, order, status, MDM assignment, AppleCare coverage, MAC addresses, the works. Select a handful, right-click, reassign.

• Device browser — every managed device in one paginated, sortable table with a details sidebar. AppleCare coverage enrichment is a toggle away.
• Powerful filters — filter by device status, by order number, by model family, by MDM server — stack filters to narrow to exactly the specific devices you want.
• MDM server list and assignments — see every server and what's assigned to it.
• Bulk assign / unassign — multi-select in the table, pick a destination server, go. Or import a CSV if that's how your desired state arrives.
• Export to CSV or JSON — selection or filtered results out through the macOS share sheet.
• Multi-profile switching — flip between Apple Business & School Manager instances from the sidebar; manage credentials in settings.

Filters

The filters match the web — same categories, same stacking behaviour — so if you already use the ABM filters, you already know how these work. The difference is that here they run against a native table with every device already loaded, so stacking is instant, the selection carries into bulk assign/unassign in one click, and the filtered set exports to CSV or JSON through the share sheet.

Filter by order number, device status, model family, or MDM server — and stack them, so "unassigned iPads from the last PO that haven't been routed to Intune yet" is three clicks.

Once you've narrowed to the right cohort, export (CSV/JSON) or bulk-reassign works on the filtered selection — not on the whole fleet.

What You Get

• Pure Swift 6 binary — no external runtime dependencies.
• Credentials stored in the macOS Keychain — data-protection class, no per-app ACL prompts.
• Multiple profile support — manage several AxM instances (school-district-east, business-unit-3, whatever) from a dropdown instead of –profile flags.
• Automatic OAuth 2 client-assertion handling — token lifecycle handled for you.
• Paginated device fetch — walks the full inventory without you worrying about page cursors.
• Bulk operations — CSV import or multi-select directly in the GUI table.
• StrictConcurrency enabled — actor-isolated, race-free by design.
• Bulk device-to-server resolution — server-side device listing gets the whole fleet in 4–5 API calls regardless of size, instead of per-device lookups.
• Bulk AppleCare enrichment — list-devices –include-applecare runs a two-pass fan-out across the whole fleet, no CSV required.

Recent API Coverage

I've kept the tool caught up with the AxM API as Apple has shipped new fields:

• API 1.5 — MAC addresses now support multiple values (array format) for devices with multiple network interfaces.
• API 1.4 — Wi-Fi, Bluetooth, and built-in Ethernet MAC addresses for macOS.
• API 1.3 — AppleCare coverage lookup for devices (single-serial via get-devices-info, whole-fleet via list-devices –include-applecare).
• API 1.2 — Wi-Fi and Bluetooth MAC addresses for iOS, iPadOS, tvOS, and visionOS.

Running in the Cloud

Alongside the GUI app, the other side of the coin — fully cloud, headless operations — has gotten a lot of work too. Fully static Swift runtime via –static-swift-stdlib, URLSession fixes for musl, and keychain-less credential provisioning from env vars so the same codebase runs cleanly on Ubuntu. One Swift 6 binary, one data model, one API client — running unchanged inside Azure Functions, AWS Lambda, or any Linux container.

Cloud automations that the Linux binary offers:

• Reconciliation (inventory → Apple) — a trigger fires off a desired-state list (a CSV, a DB query, an event), the function asks asbmutil what Apple Business & School Manager currently shows, diffs the two, and issues assign/unassign calls to close the gap. Anything the inventory system considers authoritative — MDM server, department, ownership tags — can drive the comparison.
• Enrichment (Apple → inventory) — a timer pulls the full device list plus AppleCare coverage via asbmutil, hashes the normalised payload per serial, stores the fingerprint in blob storage, and only writes back to inventory when the Apple-side data has actually changed. Warranty months, coverage status, order number, MDM assignment — all flow in automatically, and the hash cache keeps API traffic and downstream write-load proportional to real change, not fleet size.

Outcome: inventory and Apple Business & School Manager stay in lockstep without anyone opening either UI. Warranty data flows in one direction, MDM assignments in the other, both driven by the same Swift binary you'd run on your Mac.

I plan to write in more detail how I'm running these and the code behind them in follow-up posts.

How to Use All Three

The CLI has its place. It's the thing I'll use to check which MDM a device is assigned to when I need quick operations — asbmutil list-devices-servers –mdm "Intune" piped through jq and grep, done in a second.

For bulk operations I reach for the GUI app — load a CSV, select in the table, hit the button. Being able to see what's assigned, what's unassigned, and peruse the fleet side-by-side catches mistakes before they ship and surfaces clean-up opportunities you'd miss on the command line.

And for the continuous, unattended work — nightly syncs, warranty enrichment, inventory reconciliation — the Linux binary inside a serverless function quietly does it in the background, no interaction, automated.

Same data model, same trust store, same API calls underneath.

Grab It

Repo: github.com/rodchristiansen/asbmutil

Grab the latest .pkg or .dmg from the releases page. The installer drops both the app into /Applications and the asbmutil CLI into /usr/local/bin.

A note on signing: the released artifacts are unsigned and not notarized. On first launch Gatekeeper will complain — clear the quarantine attribute and you're good:

xattr -dr com.apple.quarantine /Applications/ASBMUtil.app
xattr -dr com.apple.quarantine /usr/local/bin/asbmutil

Or build and sign it yourself from source — make build in the repo will do the whole signing + notarization dance if you drop your own Developer ID into .env. As Mac admins you know the drill.

Requirements: macOS 14+, and an AxM API account with a client ID, key ID, and PEM. If you already have the CLI configured, the app reads the same keychain profiles — nothing to migrate.

More posts coming on the specific things this tool makes trivial that ABM's web UI makes painful — starting with the bulk device-to-server resolver, which I think is the most interesting piece of the codebase. For now: v1 of the app exists, it works, and I'd love to hear where it breaks for you.

QuickLook on the Mac doesn't support previewing the contents of YAML files. You're digging through repos, config files, CI pipeline files, playbooks, terraform plan and you want to peek at a YAML file without opening it.

You hit Space.

Nothing. Just the generic document icon staring back at you.

QuickLook on the Mac supports text files, plists, JSON—but YAML? Nothing out of the box. I fixed that with YAML Quick Look.

What It Does

It's a native macOS Quick Look extension that does two things:

1. Preview: Hit Space on any .yaml or .yml file, and you get a clean, scrollable plain-text view—same experience as .txt or .plist.
2. Thumbnails: Finder shows file content in the icon itself, so you can tell files apart without opening them.

Dark mode works. Large files are handled (truncated at 10 MB so it doesn't eat your RAM). It uses a shared YAMLFileReader module backing both extensions, so the behaviour is consistent.

It's not a syntax highlighter—that was a deliberate choice. Quick Look is for glancing, not editing. Plain text, monospace, scrollable. That's it.

Why I Wrote This

Honestly, it was scratching my own itch. I spend a lot of time in repos and Terraform configs, and the missing YAML preview was a small but consistent annoyance.

There are third-party alternatives, but most of them are either abandoned, use Homebrew, or are bundled inside larger editor apps. I wanted something clean, native, and deployable via a single pkg.

It's available on GitHub under MIT. It requires macOS 14 Sonoma or later.

The App

The app is three targets:

• YamlQuickLook — A lightweight container app. You open it once to register the extensions, then mostly ignore it. I added Status, Preview, and Settings tabs to make it feel like a real app rather than a hollow shell.
• YamlQuickLookExtension — The Quick Look preview extension
• YamlQuickLookThumbnailExtension — The thumbnail generator

The shared module (YamlQuickLookShared) handles all the file reading logic, so both extensions stay thin. The test suite covers 38 cases across the reader—everything from empty files to malformed YAML to files at the size limit.

Installing It

The simplest path: grab the latest zip from Releases, move the app to /Applications, and run the post-install script to strip quarantine and activate the extension:

xattr -cr /Applications/YamlQuickLook.app
pluginkit -a /Applications/YamlQuickLook.app/Contents/PlugIns/YamlQuickLookExtension.appex || true
pluginkit -a /Applications/YamlQuickLook.app/Contents/PlugIns/YamlQuickLookThumbnailExtension.appex || true
qlmanage -r
qlmanage -r cache

Building with Code Signing

The release build isn't code-signed—I don't have (yet) a Developer ID. You can sign and notarize with your own cert for your environment. I plan to release it onto the Mac App Store.

If you want a properly signed and notarized build—which I'd recommend for org-wide deploys—clone the repo and configure signing in Xcode for all three targets:

xcodebuild -scheme YamlQuickLook \
  -configuration Release \
  -derivedDataPath build \
  CODE_SIGN_IDENTITY="Developer ID Application: Your Name (TEAM_ID)" \
  DEVELOPMENT_TEAM="TEAM_ID" \
  clean build

Then notarize it with xcrun notarytool and staple the ticket. The README has the full steps. A signed build skips the xattr step entirely and removes the quarantine friction for your users.

The Makefile also has a make release target that handles the signing and notarization flow if you've set up your credentials in .env.

A year ago, we were managing Macs the way most orgs still do: one shared Mac, VNC’d into, running a local copy of Munki with no real version control or workflow isolation. Git was an afterthought. Deployments were manual. It worked—until it didn’t scale.

We’ve since inverted the model. Git is the gate. CI is the deployer. Each admin works from their own machine. And the Munki repo is fully DevOps-native.

Here’s how we rebuilt everything using Git, Azure DevOps, Service Bus, pipelines, local caching servers, and inventory automation—all open source and cloud-integrated.

From Manual to DevOps

The legacy flow was:

• GitLab running on-prem
• One shared Mac as the deploy point
• One central repo, updated by many hands
• No pipeline. No hooks. No approval gates.
• Everyone stepped on everyone’s toes

Now we have:

• Azure DevOps Git repos and pipelines
• Git hooks that upload/download packages automatically
• Separate working copies per admin
• Local caching servers that sync intelligently
• A full CI/CD system that integrates with inventory and deploys via pull requests

Architecture Overview

We’ve split this into two core flows:

Munki DevOps Infrastructure

• Admins commit to a shared Azure DevOps repo with manifests/ and pkgsinfo/
• Git hooks (post-commit/merge) run azcopy sync to upload or download packages
• A pipeline (munki-push-production.yml) builds catalogs and updates Azure Storage
• Local caching servers (like PLUTO and PROTEUS) are notified via Azure Service Bus
• A daemon listens for commits and runs git pull and syncs assets
• CDN serves files globally or from on-prem caches
• It’s fast, redundant, and observable

Inventory-Orchestrated Enrollment

• A polling script checks Snipe-IT for inventory changes and builds new CSVs
• CSVs are committed to Git → triggers DevOps pipelines → runs enrollment-munki, enrollment-intune, enrollment-sharepoint, and more
• Each system (Munki, Intune, Fleet, TDX, Papercut) gets updated data
• Pull requests are the approval gate
• Everything is traceable, auditable, and CI-driven

Resources

• Presentation Repo: github.com/rodchristiansen/munki-devops

Want to talk shop or ask questions? Connect with me on BlueSky or on the GitHub.

Wiring Git Credential Manager (GCM) into your local global Git helpers you trade fragile over-scoped PATs for one-hour tokens that renew silently and leave no secrets on disk or in build logs.

What this guide helps you with

• Enable seamless Single‑Sign‑On on macOS and Windows for:
  • Azure DevOps (https://dev.azure.com/ORG/…)
  • GitHub.com or GitHub Enterprise (https://github.com/…)

macOS

How to setup GCM for password‑free access on macOS:

Prerequisites

• Homebrew
• Git ≥ the version bundled with Xcode 15
• Git Credential Manager (installed below)

Install / upgrade components

brew install --cask git-credential-manager
brew upgrade git

Configure global helpers

git config --global --replace-all credential.helper manager
git config --global --add credential.helper osxkeychain
git config --global credential.msauthFlow devicecode
git config --global credential.guiPrompt false

Persist settings for shells & GUI apps

echo 'export GCM_MSAUTH_FLOW=devicecode' >> ~/.zprofile
echo 'export GCM_GUI_PROMPT=0' >> ~/.zprofile
launchctl setenv GCM_MSAUTH_FLOW devicecode
launchctl setenv GCM_GUI_PROMPT 0

• VS Code: add "git.terminalAuthentication": false to settings.json
• Git Tower: defaults write com.fournova.Tower5 UseCredentialManager -bool true

First run

git fetch   # single device‑code prompt, then silent

Windows

And here's how to setup on Windows, leveraging the Entra ID broker for silent SSO with Azure DevOps and device‑code for GitHub.

Prerequisites

• Git for Windows ≥ 2.45 (bundles GCM v2)
• Device joined to Entra ID (native, hybrid, or AAD‑registered)

Clean up old helpers

git credential-manager unconfigure
git credential-manager configure
git config –global –unset-all credential.helper
git config –global –remove-section credential

Enable Broker SSO (Azure DevOps) and Device Code (GitHub)

git config –global credential.helper manager-core
git config –global credential.microsoft.sso true
git config –global credential.msauthUseBroker true
git config –global credential.msauthFlow broker
git config –global credential.githubAuthModes devicecode

Strip hard‑coded usernames from remotes

git remote set-url origin https://dev.azure.com/ORG/PROJECT/_git/REPO
git remote set-url origin https://github.com/ORG/REPO

First run

git fetch   # one Windows dialog, then silent

Bulk‑fix existing repositories (optional)

Replace the sample paths below with the folder that contains multiple repositories.

PowerShell (Windows)

Get-ChildItem C:\Dev\Repos -Directory | ForEach-Object {
git -C $.FullName remote set-url origin (git -C $.FullName remote get-url origin -replace '://.@', '://')
}

zsh (macOS)

for d in ~/Dev/Repos/(.); do
url=$(git -C "$d" remote get-url origin | sed 's#://.*@#://#')
git -C "$d" remote set-url origin "$url"
done

Troubleshooting

Run git-credential-manager diagnose for a quick health check. Erase stale tokens with:

git credential-manager erase https://dev.azure.com
git credential-manager erase https://github.com

Need verbose output? Temporarily set:

export GIT_TRACE=1
export GCM_TRACE=1
git fetch

If GCM prompts twice on macOS, login.keychain-db may be read‑only. Unlock and purge stale entries, then retry:

security unlock-keychain ~/Library/Keychains/login.keychain-db
git credential-manager erase https://dev.azure.com
git credential-manager erase https://github.com

By switching from long-lived PATs to short-lived tokens through Git Credential Manager, you lock down your supply chain while making everyday Git activity faster and quieter:

• MFA is enforced automatically and refreshed in the background.
• Tokens rotate every hour, slashing the window for theft or replay.
• No secrets leak into scripts, CI logs, or dotfiles—nothing to scrub later.

Bake these GCM settings into your workstation images and onboarding scripts once, and every clone, fetch, and push runs hands-free from that point on. Stronger security, zero extra clicks, and no browser pop-ups—that’s a win on every front.

Publishing Like a Dev: Meet GhostPost

You use Ghost because it’s modern, open, and built for professional creators. It gives you newsletters, subscriptions, and a full publishing stack that doesn’t sell your soul to adtech.

You use Git because you want version history, branches, and working with the all mighty plain text.

ghostpost is a GitOps-style CLI for managing Ghost posts.

Each post lives as a Markdown file in your repo. The front-matter stores all metadata—including the Ghost post_id.

You edit locally. You commit. ghostpost publishes.

Why I Built This

I wanted a writing workflow that matched how one might ship code.

• No fragile CMS UI edits
• No "oops I deleted the draft"
• No back-and-forth between browser and source doc

The Ghost GUI becomes just a preview tool. Nothing gets edited in it.

Not necessarily a new idea—post2ghost laid out the same "Articles as Code" concept where content belongs in Git. The CMS should be a rendering layer, not an editing platform.

That post nailed the philosophy:

• Keep Markdown files under version control
• Write in your editor of choice
• Automate publishing with API calls

It was still a bit DIY and python based which is a dependency headache -- I love python, but not for cli tools...

ghostpost takes that same idea and wraps it in a clean CLI. One command and simple.

How It Works

You write a post in Markdown, with front-matter like this:

---
title: Your title here
slug: your-slug
custom_excerpt: Short summary here
tags: [DevOps, Ghost]
feature_image: images/cover.jpg
status: draft
---
Your content in Markdown.

Then you run:

ghostpost publish -f /path/to/post.md –editor

The tool takes care of:

• Creating the post if it’s new
• Updating the post if it already exists
• Uploading and rewriting image paths to proper Ghost URLs

There’s no runtime. No daemon. No need to open the CMS.

What You Get

• Real version control Posts live in Git. You get git log, pull requests, inline diffs, CI checks.
• Stateless deploys Posts can be published from anywhere. Just point to the Markdown file. Or automatically with CI/CD.
• Front-matter is the truth Titles, tags, status, authors, descriptions—everything is stored right inside the Markdown file.
• Smart images Use local paths. ghostpost uploads and rewrites them for you.
• CI-ready Validate structure. Block merges on bad metadata. Push on deploy.

Here’s a basic example using GitHub Actions:

# .github/workflows/publish.yml
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: ghostpost publish -f posts/hello-from-git.md –editor

Why Not Just Use the Ghost UI?

Because once you’ve versioned your posts, previewed with Markdown, and deployed with a single command—there’s no going back.

No clunky editors. No missing history. No surprises.

Get Started

Check out the repo and the readme at https://github.com/rodchristiansen/ghost-gitops-publishing

Install the binary, connect it to your Ghost API, and start treating your writing like the rest of your infrastructure: reproducible, testable, and versioned.

It worked—until it didn't.

We moved from running local scripts on a shared Mac to each admin working from their own local repo, committing changes through Git, syncing packages with az git hooks. We used to push changes first, then capture them in Git after the fact. Now, Git is the gate. Commits and PRs drive the entire process. Pipelines run automatically, and the cloud becomes the source of truth. Our local caching servers listen for updates—pulling down only when there are changes—fully inverting the workflow into something distributed, reliable, and scalable. All of it version-controlled. All of it traceable. All of it running on infrastructure provisioned with Terraform.

Every config, every profile, every software assignment that matters tracked in Git. It’s CI/CD deployed, reproducible by design, and logged automatically for traceability.

What This Blog Is About

This blog is about the journey—the migrations, the patterns that emerged, the decisions that held up, and the ones that didn’t. And about the new tools and ideas I'll be building and using along the way.

If you work in endpoint management with DevOps, you’ll find deep dives into:

• CI/CD pipelines that manage device tools, states, and configuration
• Every cloud resource under Infrastructure as Code with Terraform
• Inventory systems that drive deployment logic
• And Git at the center of it all

As I now manage both macOS and Windows endpoints, I’ll be writing about how I'm creating a cohesive, mirrored management system—where both platforms are driven by open source tools, DevOps, and Git, and where admins speak the same language on both sides.

Focused Systems. Grounded in what actually works and scales. Very opinionated.

Let’s get to it.