Posted in

I’d Run Omarchy Everywhere if Intune Would Manage It

by ailona•

I have been running Omarchy on my own laptop and it is the most fun I have had with a computer in years. Arch, Hyprland, a terminal-first workflow, and agents wired in deep enough that you can hand them a problem mid-task. I would make it my main work machine tomorrow — except that Intune Linux support does not reach it, and finding out exactly how far that support reaches turned out to be more useful than being annoyed about it.

What Omarchy is, and why it keeps coming up

Omarchy is DHH’s opinionated Arch build: Arch plus Hyprland plus a curated set of defaults, shipped as an ISO you can install in a couple of minutes, with full-disk or dual-boot options, unattended installs, and a plugin ecosystem. It calls itself agentic Linux, and the AI tooling is part of the base experience rather than something bolted on afterwards. A rolling Arch base plus an agent-first workflow is exactly why technical users like it, and exactly why enterprise device management has no answer for it.

Where Intune draws the line

The supported footprint is small and precise. Microsoft documents Linux enrollment for Ubuntu Desktop 24.04 LTS and 26.04 LTS and for RHEL 9 and 10, on x86/64 — physical, Azure VM, or Hyper-V — with Microsoft Edge 102 or later and the Microsoft Intune app for Linux. Ubuntu on WSL2 is explicitly not supported, and enrollment is user-driven with no bulk or Autopilot-style path. Arch is not on the list, so Omarchy fails at the first gate.

The desktop requirement is the detail worth internalising. Enrollment documents a GNOME desktop environment, and newer Microsoft Entra identity-broker documentation for Linux single sign-on describes the requirement more loosely as “GNOME, KDE, or similar.” Either way, Hyprland sits outside Microsoft’s documented enrollment matrix. That matters beyond this one distro: it means this is not purely a distribution question, and swapping GNOME for another compositor on a supported release is not a safe assumption. Two releases that used to be in scope are also already gone: RHEL 8 support ended in July 2026 and Ubuntu 22.04 in August 2026. Devices enrolled beforehand stay enrolled, which is the awkward part — they keep checking in and reporting compliance while sitting outside the support boundary.

What Intune actually does on Linux, and what it does not

Be precise about the boundary here, because vendor pages blur it. What Linux devices do get is compliance policy — distribution type and version, encryption, password complexity — plus Conditional Access for Microsoft 365 web apps in Edge, and custom Bash configuration scripts that Intune can assign to enrolled Linux systems, running in either user or root context on a schedule that defaults to every 15 minutes. Separate from those, compliance discovery scripts run as the signed-in user only, which means they cannot inspect privileged state, and both script and output are capped at 1 MB.

What they do not get is just as concrete. There is no Windows-style application deployment and no broad native settings catalog, so Bash scripts are the configuration mechanism rather than a stopgap. There is no app or package inventory: Intune’s Discovered Apps report has no Linux platform at all, and Microsoft states plainly that hardware device details are not supported for Linux devices. Remote actions are the other gap. The platform tables for remote lock and for the retire-list action list Android, iOS, macOS, and Windows — not Linux — and the wipe documentation carries no Linux coverage either. Microsoft’s Linux deployment guide does mention locking and retiring among actions for noncompliance, but the per-action tables are narrower than that summary sentence. If your offboarding story assumes a remote wipe on a Linux endpoint, test it in your own tenant before you document it as a control.

My own machine, checked against the matrix

I stopped reading docs and ran the checks on the laptop in front of me, an Omarchy 4.0.3 machine, because the result is the whole story in one screen:

  • Supported distribution: fail. Omarchy reports ID=omarchy with ID_LIKE=arch.
  • Supported desktop: fail. Hyprland on Wayland, not GNOME.
  • Client packages: fail. Microsoft Edge is not installed, the Intune app is not available through the configured pacman repositories, and the Microsoft identity broker is absent.
  • CPU: pass at x86_64.
  • Disk encryption: pass, root is on LUKS.
  • Secure Boot: enabled. TPM: a TPM 2 device is present.

That is a reasonably hardened endpoint. It fails anyway, at the platform and client-package layers, and no amount of Secure Boot or TPM gets it past an unsupported distribution and desktop. The gates are identity and packaging, not endpoint hardening.

What I evaluated as a way around it

Himmelblau is the open-source project that joins Linux machines to Entra ID and enrolls them in Intune. Its current packages cover openSUSE, SUSE Linux Enterprise, Fedora, Ubuntu, Debian, RHEL family builds including Rocky, and NixOS. There is no supported Arch package or build target, so it does not create a supportable Omarchy path, and its own documentation notes that Intune policies apply only to the first user who signs in on a Linux client. Useful to know about, not a fix for this desktop.

Fleet is the tool that actually treats Omarchy as a platform. It added Arch-family support in 4.75.0, but Omarchy 4 ships its own /etc/os-release and reports platform=omarchy where earlier versions inherited arch, which broke host recognition until Fleet 4.91.0. So the practical baseline is 4.91.0 or later: at that version vitals and software inventory populate again, disk-encryption status and key escrow are available, linux-scoped policies and labels apply, and scripts can run from the host’s actions menu. Be careful about the licence boundary too. Lock and wipe are Fleet Premium features, and Linux wipe is script-based rather than an MDM command; Fleet Free gives you inventory, policies, and reporting without per-host cost, and Premium is 7.00 USD per host per month. If you want Entra-based Conditional Access for Microsoft 365 in Edge, Fleet does not give you that — nothing outside Intune does.

The compromise I have landed on is the boring one: Omarchy stays my personal machine, and anything that has to live inside a client’s Microsoft tenancy runs on Ubuntu 24.04 LTS with GNOME, enrolled through the Intune app.

What I would tell a client

Do not fight the matrix; design around it. Inventory Linux endpoints against those four releases, flag every Ubuntu 22.04 and RHEL 8 machine as already out of scope, run 24.04 LTS as the default, and treat 26.04 LTS as a pilot until drivers, security agents, VPN clients, and access policies have been validated. After any upgrade, re-check group assignments, filters, and Conditional Access: Microsoft Identity Broker 2.0.2 and later re-register and re-enroll devices, which mints new Intune and Entra device IDs and quietly orphans rules keyed to the old device object. Resolve ownership early as well — Microsoft’s end-user enrollment doc calls enrolled Linux devices corporate-owned and says personal enrollment is not supported, while the admin deployment guide says licensed employees can enroll personal Linux devices. Those two documents do not agree, and the answer changes your licensing and BYOD posture.

And size a Linux program on your own ticket volume rather than the headlines. The market-share numbers being quoted this year are disputed: Statcounter counts page views rather than devices, and Cloudflare Radar’s human-only traffic shows a much smaller rise than a bot-inflated spike suggests. Desktop Linux is growing, and Omarchy is the best argument for it that I have personally used. It just cannot live inside Intune yet — and knowing exactly where it fails is what lets me keep using it happily on my own machine.

Sources