auspex: IT Admin User Guide for Microsoft Intune (Windows)

Last updated: August 27, 2026

This guide covers deploying the Span agent (auspex) to Windows devices with Microsoft Intune. For Macs, see the macOS guide.

What This Package Does

auspex captures AI coding activity (prompts, file edits, tool use) from supported IDEs — Claude Code, Cursor, Codex CLI, GitHub Copilot, and VS Code chat — and sends telemetry to Span's analytics backend. This data appears in your Span dashboard under AI Effectiveness.

On Windows the .msi installs machine-wide to C:\Program Files\auspex, registers a logon task so each engineer's agent starts when they sign in, and converges the device to the managed tier — capture is centrally governed and a user cannot install a competing copy over it.

Prerequisites

  • A Span account with access to integration settings.
  • An Intune tenant with target devices Entra-joined and assigned to groups.
  • Windows 10 (build 1809+) or Windows 11 with the Intune Management Extension present.
  • Each engineer's work email populated in Entra (the mail attribute / UPN) — it identifies the individual on their device.

Which architecture — amd64 or arm64?

Almost certainly amd64. Every Intel and AMD PC uses it, which is the overwhelming majority of corporate fleets. arm64 is needed only for Windows on Arm devices: Snapdragon-based Copilot+ PCs (Surface Pro 11, Surface Laptop 7, Dell XPS 13 9345, Lenovo ThinkPad T14s Gen 6 and similar), or Windows VMs on Apple Silicon Macs.

An amd64 .msi will not install on an Arm device, so don't assume a single build covers the fleet.

Checking architecture across a fleet

Intune already knows. Devices → All devices → Columns → Architecture, or export the device list and group by that column. For a precise count, run this KQL in Reports → Endpoint analytics or against your Log Analytics workspace:

IntuneDevices
| where OS == "Windows"
| summarize devices = count() by Architecture

If any ARM64 devices appear, create a second app deployment with the arm64 .msi and assign it to a group filtered on architecture (Assignments → Edit filter → device.architecture -eq "ARM64").

Deployment order (important)

  1. Identity script that writes identity.json — before or with the package.
  2. The package (line-of-business app, Required).

The package converges the device on install; if identity is already present, the agent starts reporting immediately rather than waiting for the next script cycle.

Step 1: Enable the Integration and Get Your Token (one-time)

This step is the same regardless of your MDM.

Head to the AI tool settings dashboard (https://span.app/_/settings/integrations) and under IDE & CLI AI Tool Integrations, enable the tools your engineers use. The token is shared org-wide and is required regardless of which IDEs you deploy for.

Step 2: Deploy the Identity Script

The token is org-wide; the work email is per-device. Windows has no {{mail}} substitution for scripts, so both are written by one script.

In Intune: Devices → Scripts and remediations → Platform scripts → Add → Windows 10 and later. Run it in system context, not in 64-bit PowerShell host only — leave "Run script in 64 bit PowerShell Host" set to Yes.

$ErrorActionPreference = 'Stop'
$Token = "__PASTE_SPAN_AUTH_TOKEN__"

# Resolve the enrolled user's email (UPN). Adjust if your UPN and mail attribute differ.
$Email = (Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Enrollments" -Recurse -ErrorAction SilentlyContinue |
  Get-ItemProperty -ErrorAction SilentlyContinue | Where-Object UPN | Select-Object -First 1).UPN
if (-not $Email) { throw "Could not resolve work email." }

$Dir = 'C:\ProgramData\auspex'
New-Item -ItemType Directory -Force $Dir | Out-Null

# UTF-8 WITHOUT a BOM. PowerShell's default encodings (UTF-16 from Out-File, or a BOM from
# Set-Content) would put stray bytes in the token, which auspex rejects as a malformed credential.
$json = '{{"token":"{0}","work_email":"{1}"}}' -f $Token, $Email
[IO.File]::WriteAllText((Join-Path $Dir 'identity.json'), $json, (New-Object System.Text.UTF8Encoding $false))

C:\ProgramData\auspex is the managed configuration tree. The .msi applies a restrictive ACL to it (SYSTEM and Administrators full control, Users read-only), so the token is not readable-writable by the signed-in engineer.

If your UPN ≠ mail, replace the resolution line with your source of truth and confirm on a pilot device before fleet rollout.

Step 3: Deploy the Package

Apps → All apps → Create → Windows → Line-of-business app and upload the .msi (no .intunewin wrapping needed). Assign Required to the same group as Step 2.

Download the installer from:

https://auspex.span.app/releases/latest/windows/auspex_windows_amd64.msi
https://auspex.span.app/releases/latest/windows/auspex_windows_arm64.msi

The .msi is signed with a Windows code-signing certificate (Azure Trusted Signing), so policies requiring signed installers accept it.

On install it places the binary, writes the managed configuration marker, registers the machine-wide logon task, and converges the device to the managed tier.

Step 4: Smoke Test (before fleet rollout)

Assign Steps 2–3 to one or two pilot devices first. Confirm both report success in Intune, then verify on-device from an elevated PowerShell:

& 'C:\Program Files\auspex\bin\auspex.exe' status
& 'C:\Program Files\auspex\bin\auspex.exe' auth show
schtasks /Query /TN "app.span.auspex"

Expect install mode: managed, daemon: ok, a token and work email both sourced from managed, and a registered logon task. Then have the pilot user sign in, use Claude Code or Cursor briefly, and confirm their traces reach the Span dashboard.

The engineer's own agent starts at sign-in. On a device where nobody has signed in since the install, status run as an admin will show the managed tier in place but no per-user daemon yet — that is expected.

Optional: Replace legacy Span coding-hooks in the same rollout

If your fleet still runs Span's earlier coding-hooks agent, retire it once auspex is confirmed healthy on each device — running both captures every event twice. See Retiring coding-hooks for a check-then-uninstall script that only acts on devices where auspex has genuinely taken over, and guidance on running it as an Intune remediation so it re-evaluates as the rollout lands.

Upgrading

Upload the new .msi to the existing LOB app (the auspex app → Properties → App information → Edit → Select file to update). Existing assignments reinstall on the next check-in. The managed configuration and identity.json are preserved across the upgrade, and each engineer's captured data and hook wiring are left intact.

Uninstalling

Set the app assignment to Uninstall, or run msiexec /x with the auspex ProductCode. The .msi deliberately leaves C:\ProgramData\auspex behind — the managed configuration and organization identity belong to you, not the installer, so a reinstall or version change never loses your fleet policy. Remove it explicitly when decommissioning:

Remove-Item -Recurse -Force 'C:\ProgramData\auspex'

Troubleshooting

  • install mode: user instead of managed — the managed configuration tree is missing. Confirm C:\ProgramData\auspex\managed.yaml exists; if the .msi installed but the marker is absent, the install did not complete.
  • token: not set after the identity script ran — check the file's encoding. A UTF-16 or BOM-prefixed identity.json is rejected; use the WriteAllText form in Step 2 exactly as given. auspex auth show names the problem when the file is present but unreadable.
  • work_email: (unset) with a token present — the address failed validation (it must look like name@domain.tld). A truncated or malformed value is dropped rather than sent, so check what your UPN resolution actually produced.
  • No traces for a specific engineer — confirm they have signed in since the install (their agent starts at sign-in), then check auspex status in their session shows capture_wiring passing for all tools.
  • An Arm device shows the app as failed — you assigned the amd64 .msi. See Which architecture above.