Deploy to a Windows Fleet (Intune)

Push the Waxell AI-endpoint agent to managed Windows PCs with zero user clicks. You stage three Intune objects — trust the tenant CA, deliver the managed config, install the MSI — and capability lights up the next time the user logs in.

This is the Intune-specific walkthrough. The same three-artifact pattern works on Workspace ONE, Kandji-for-Windows, JumpCloud, and other MDMs by analogy; only the console verbs differ. For the macOS path see macOS. For where endpoints fit in the bigger picture see the Overview.

What this deploys

The full AI-endpoint stack. Each device enrolls against your tenant CA, discovers its AI apps, reports metadata flows, and — once an admin turns capture on for a specific host — terminates TLS for that AI host only, DLP-redacts on-device, and uploads.

Interception is default-OFF. Nothing is terminated until you enable a host. See Turning capture on.

The three artifacts

Artifact	What it does	Intune object
The cert — the tenant root cert (PEM)	Trusts the tenant root CA fleet-wide so the proxy's per-host leaf certs chain to it	Devices → Configuration → Create → Windows 10+ → Trusted certificate
The managed config — waxell-setup.ps1 (per-tenant, generated live)	Writes HKLM\SOFTWARE\Waxell (ApiUrl, ApiKey, CaptureEnabled, InterceptHosts, InterceptProcesses) and ACLs the key to SYSTEM + Administrators	Devices → Scripts and remediations → Platform scripts → Windows, or Settings Catalog
The app — Waxell-<ver>.msi	The installer: lays down WaxellSetup.exe, the WaxellNetworkMonitor / WaxellCoworkWatcher / WaxellPolicyDaemon services, and wax-hook.exe; the tenant CA gets pinned to the running services on first run	Apps → Windows → Add → Win32 app (.intunewin)

Service-install order is handled by the MSI. WaxellNetworkMonitor, WaxellCoworkWatcher, and WaxellPolicyDaemon all install auto-start as LocalSystem, boot at device startup, and pick up the managed config the moment it's present.

Where to get the artifacts

There are two ways to obtain the per-tenant cert and setup script.

• In-app (recommended). Go to Governance → Connect → AI Endpoints → Setup. Download the trusted cert and the managed-config script directly.
• Scripted. Pull them from the API with a tenant API key (shown in Steps 1–2 below).

The MSI is built with build-msi.ps1 from the installer source (Step 3).

The setup script carries your tenant API key

waxell-setup.ps1 is generated per-tenant and embeds your tenant API key in the script body. Treat the file as a secret — store it like any other credential and scope who can read it in your MDM.

Step 1 — Download your tenant's setup script

Use a tenant API key. Set it as WAX_KEY in your shell first.

Invoke-WebRequest `
  -Uri "https://api.waxell.dev/api/waxell/v1/endpoint/mdm-profile/?platform=windows" `
  -Headers @{ "X-Wax-Key" = $env:WAX_KEY } `
  -OutFile waxell-setup.ps1

• Capture stays OFF by default. To pre-enable capture for specific hosts at provisioning time, append &hosts=api.openai.com,api.anthropic.com to the URL. You can also leave it off here and enable per-app later from Governance → Connect → AI Endpoints → Guard.
• The script writes only HKLM values — no app install, no driver install. It is idempotent and safe to re-run.

Step 2 — Download your tenant's root cert

Invoke-WebRequest `
  -Uri "https://api.waxell.dev/api/waxell/v1/endpoint/ca-root/" `
  -Headers @{ "X-Wax-Key" = $env:WAX_KEY } `
  -OutFile waxell-tenant-root.pem

# Convert to DER (.cer) if your Intune cert profile wants it
certutil -encode waxell-tenant-root.pem waxell-tenant-root.cer

Step 3 — Build the MSI

cd installers\windows
powershell -ExecutionPolicy Bypass -File build-msi.ps1 -Version 0.7.0 -Sign -CertSubject "Your Code Signing Cert"
# -> dist\Waxell-0.7.0.msi

One-time prereqs: an EV code-signing cert (subject discoverable via -CertSubject), or a .pfx (-CertPath + -CertPassword). build-msi.ps1 errors clearly if the cert can't be resolved.

Wrap the MSI as an .intunewin for upload:

.\IntuneWinAppUtil.exe -c dist -s Waxell-0.7.0.msi -o dist\intunewin
# -> dist\intunewin\Waxell-0.7.0.intunewin

Code-signing status — read before you distribute

The Windows MSI is not yet EV code-signed — the certificate is still in verification.

Because Intune installs the MSI as SYSTEM during MDM deployment, the push path below does not hit SmartScreen — a fleet rollout through Intune is unaffected. What is not yet available is a publicly signed download that an individual user could double-click without a SmartScreen warning. Use the MDM path for now.

Step 4 — Upload the three objects to Intune

4a. Trusted certificate

Intune console → Devices → Configuration → Create policy → Windows 10+ → Templates → Trusted certificate:

• Name: Waxell Tenant Root CA
• Certificate file: waxell-tenant-root.cer
• Destination store: Computer certificate store - Root

4b. Managed config (HKLM\SOFTWARE\Waxell)

Two equivalent paths — pick one.

Option A — Platform script (simpler). Intune → Devices → Scripts and remediations → Platform scripts → Add → Windows 10+:

• Script file: waxell-setup.ps1 (Step 1 output)
• Run this script using the logged on credentials: No
• Enforce script signature check: No (or Yes if you signed the script first)
• Run script in 64 bit PowerShell host: Yes

Option B — Settings Catalog (auditable per-key). Intune → Devices → Configuration → Create policy → Windows 10+ → Settings catalog. Use a Custom OMA-URI profile if you prefer raw paths. Push these registry values to HKLM\SOFTWARE\Waxell:

Value	Type	Example
ApiUrl	String	https://api.waxell.dev
ApiKey	String (mark as password)	wax_sk_...
CaptureEnabled	DWord	0 (off) or 1 (on)
InterceptHosts	MultiString	api.openai.com;api.anthropic.com
InterceptProcesses	MultiString	Cursor.exe;claude.exe;Copilot.exe

Either option is equivalent — Option A is exactly what the generated waxell-setup.ps1 does.

4c. MSI (Win32 app)

Intune → Apps → Windows → Add → Win32 app:

• App package file: Waxell-0.7.0.intunewin
• Install command: msiexec /i "Waxell-0.7.0.msi" /qn /norestart
• Uninstall command: msiexec /x {9F3A2B81-7C4E-4E1A-9D0B-5E6F1A2B3C4D} /qn /norestart (the UpgradeCode from Waxell.wxs)
• Install behavior: System
• Device restart behavior: No specific action
• Detection rule: MSI → auto-detected from package
• Requirements: Windows 10 1809+ (or your floor)

Step 5 — Target a device group and push

Add all three objects (cert profile, managed-config script/policy, MSI app) to the same Intune device group, then push.

Order matters

Stage the cert profile and managed-config before the MSI so the services have everything they need on first boot. Intune usually applies configuration profiles within minutes; Win32 apps land over the next sync (up to roughly an hour).

Step 6 — Verify

Within an hour of the device's next Intune sync, each PC will:

1. Trust the tenant root CA (cert profile applied).
2. Have HKLM\SOFTWARE\Waxell populated (managed-config applied).
3. Have the MSI installed, services started, and the device enrolled against the tenant CA (CSR → per-device intermediate); %PROGRAMDATA%\Waxell\device-identity.json written.
4. Have WaxellPolicyDaemon long-polling and writing %PROGRAMDATA%\Waxell\policy.json + guard-effective.json.
5. Have scanned itself and reported its AI apps.

Watch it land in Governance → Connect → AI Endpoints:

• AI Apps — the device's discovered apps (Cursor, Claude Code, Copilot, ChatGPT desktop, …).
• Devices — map each app's process to a governed agent.
• Captures — once you enable capture for a host on Guard, the redacted requests appear.

Run the bundled diagnostic on a problem PC to see what's missing:

"C:\Program Files\Waxell\Setup\waxell-diagnose.ps1"
# -> %TEMP%\waxell-diag-<datestamp>.zip

Memory Integrity (HVCI) considerations

Windows 11 with Memory Integrity (a.k.a. HVCI — Hypervisor-protected Code Integrity) enabled blocks WinDivert v2.2.2's signed kernel driver — WinDivertOpen returns Win32 1275 ERROR_DRIVER_BLOCKED. This affects L0 payload capture and HTTP/3 (QUIC) SNI extraction — the two features that depend on the kernel driver.

Everything else continues to work normally: metadata flows, app discovery, hook governance (Cursor / Copilot / Claude Code), guard cascade policy, cowork audit, and the in-app Captures and Activity tabs.

Whether your fleet is affected:

• New Windows 11 installs (22H2+) on supported hardware default to HVCI on.
• Win10 → Win11 upgrades usually have HVCI off.
• Enterprise Win11 fleets often have HVCI on via Intune compliance policy.

For each device, the bundled diagnostic at "C:\Program Files\Waxell\Setup\waxell-diagnose.ps1" prints HVCI status in section 10b. The Captures tab also surfaces an explicit "Memory Integrity is on — L0 unavailable" banner so users aren't confused by an empty view.

Three options for HVCI-on endpoints:

1. Run metadata-only on those endpoints (default). The service silently downgrades — no L0, no QUIC SNI, but every other capability works. This is the right ship default. The Captures tab tells the user why.
2. Disable Memory Integrity per-device if the user / org accepts the security trade-off. Settings → Privacy & security → Windows Security → Device security → Core isolation → Memory integrity → Off → reboot. Push the same via Intune Settings Catalog: Device Restrictions → Memory integrity.
3. Wait for the attestation-signed driver (target: Q4). Once the Microsoft-attested .sys ships via the same MSI, HVCI accepts it and L0 lights up on those endpoints without changing the user's security posture. No re-deployment needed — the service rebinds on next restart.

Turning capture on

Capture is off until you say so. There are two ways to enable it.

• Re-push the managed-config with CaptureEnabled=1 and a populated InterceptHosts. It takes effect on the device's next Intune sync (~minutes) plus the next CaptureWorker poll (about 30s after that).
• Intended path — the Guard cascade. Set it from the Guard policy cascade (global → app type → user group → device → agent) and let it flow to the device via the WaxellPolicyDaemon long-poll (~5 min). See Guard for how to enable capture for a host.

On-device safety

TLS is terminated only for catalog AI hosts you've explicitly enabled — never banking, health, or mail. Secrets and PII are DLP-redacted on-device before anything is uploaded.

Removing a hand-installed dev copy first (your own machine)

If you've been testing locally, remove the dev copy before enrolling so the MDM-managed install is clean.

# Stop services
Stop-Service -Name WaxellNetworkMonitor, WaxellCoworkWatcher, WaxellPolicyDaemon -Force

# Uninstall MSI by UpgradeCode (no version dependence)
$msi = Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like 'Waxell*' }
$msi | ForEach-Object { msiexec /x $_.IdentifyingNumber /qn /norestart; Wait-Process msiexec }

# Clean the persistent CNG keys + Waxell certs (otherwise enrollment re-uses them)
& "C:\Program Files\Waxell\Setup\WaxellSetup.exe" --reset 2>$null
Get-ChildItem 'Cert:\CurrentUser\My', 'Cert:\CurrentUser\Root' |
    Where-Object { $_.FriendlyName -like 'Waxell *' } |
    Remove-Item -Force

# Drop ProgramData state
Remove-Item -Recurse -Force "$env:PROGRAMDATA\Waxell"

Then enroll the PC in Intune (Settings → Accounts → Access work or school → Connect), push the three objects, and let MDM take over.

What's inside the generated waxell-setup.ps1 (reference)

The endpoint emits a PowerShell script that:

• Imports the tenant root CA into LocalMachine\Root (silent — certutil -addstore).
• Writes HKLM\SOFTWARE\Waxell values for ApiUrl, ApiKey, CaptureEnabled, InterceptHosts, InterceptProcesses.
• ACLs the registry key to SYSTEM + Administrators (denies ordinary users so they can't read the API key).

It does not install the MSI — that's Step 4c. This is equivalent to the macOS managed-config payload inside the .mobileconfig. Same artifacts, different MDM verbs — see macOS.