# Deploy Claude Desktop with Microsoft Intune (Win32 + auto-update)

Scripts and instructions for deploying the Claude Desktop **direct-download
MSIX** through Microsoft Intune as a **Win32 (`.intunewin`) app**, so that
Claude's built-in auto-updater keeps devices current **and** Intune keeps
reporting the app as installed.

> **Why not the native MSIX line-of-business (LOB) app type?**
> The LOB app type detects the app by the *exact* package version uploaded to
> Intune. Claude updates itself in place (within the MSIX framework — the
> package identity `Claude_pzs8sxrjxfjjc` never changes, only the version), so
> after the first auto-update the device no longer has the exact version Intune
> deployed and the deployment flips to **"installation failed"
> (0x87D1041C)** even though the app is installed and working. The Win32 path
> with the version-aware detection script in this directory avoids that.
>
> If you prefer IT to own update cadence instead, deploy as a LOB app and
> disable auto-updates via the `disableAutoUpdates` policy — see the
> [enterprise configuration article](https://support.claude.com/en/articles/12622667-enterprise-configuration).
>
> Deploying only the `disableAutoUpdates` or `autoUpdaterEnforcementHours`
> policies does **not** mark the install as organization-managed — users can
> still configure an inference provider via the in-app Setup panel. Deploying
> any other key the app recognizes under `HKLM\SOFTWARE\Policies\Claude`
> switches the install to fully managed and the panel becomes read-only.
>
> The app enumerates the `Policies` key on Windows: a key containing **no**
> value names the managed tier can honor (misspelled, newer-version, or a key
> another channel delivers) locks the Setup panel — the install reads as
> managed-but-unusable until those values are corrected or removed — while
> such names alongside recognized keys surface as config-health warnings
> without changing the management state. Verify the panel state on a test
> device after deploying a profile that should manage it.

## Contents

| File | Used as |
| --- | --- |
| `Install-Claude.ps1` | Intune **install command** (packaged inside the `.intunewin`). Installs a bundled `.msix` if one is packaged next to it; otherwise downloads the current release from Anthropic's official endpoint, verifies its signature, and installs that. |
| `Uninstall-Claude.ps1` | Intune **uninstall command** (packaged inside the `.intunewin`) |
| `Detect-Claude.ps1` | Intune **custom detection script** (uploaded separately in the app's detection rules — *not* part of the `.intunewin`) |

All scripts target Windows PowerShell 5.1 (what the Intune Management Extension
uses), run correctly from the 32-bit IME host (they re-launch themselves in
64-bit PowerShell), match the package by its full family name
(`Claude_pzs8sxrjxfjjc`, which pins Anthropic's signing publisher), and write a
transcript log to `%TEMP%` (`C:\Windows\Temp` when running as SYSTEM).

Official copies of these files are published with each Windows release at
fixed URLs, alongside a `Claude-Intune-SHA256SUMS.txt` you can verify
downloads against:

```
https://downloads.claude.ai/releases/enterprise/intune/Detect-Claude.ps1
https://downloads.claude.ai/releases/enterprise/intune/Install-Claude.ps1
https://downloads.claude.ai/releases/enterprise/intune/Uninstall-Claude.ps1
https://downloads.claude.ai/releases/enterprise/intune/Claude-Intune-README.md
https://downloads.claude.ai/releases/enterprise/intune/Claude-Intune-SHA256SUMS.txt
```

## Prerequisites

- **Sideloading** enabled on target devices: `ApplicationManagement/AllowAllTrustedApps = 1`
  (Intune Settings Catalog or custom CSP). Developer Mode is *not* required.
- **Cowork only:** the `VirtualMachinePlatform` Windows feature must be enabled
  (see the [Windows deployment article](https://support.claude.com/en/articles/12622703-deploy-claude-desktop-for-windows)).
- The [Microsoft Win32 Content Prep Tool](https://github.com/microsoft/Microsoft-Win32-Content-Prep-Tool)
  (`IntuneWinAppUtil.exe`).

## 1. Build the `.intunewin`

Two packaging options — both use the same scripts and the same Intune app
configuration; they differ only in whether the `.msix` is inside the package.

### Option A — scripts only (recommended)

Wrap just the two scripts. At install time, `Install-Claude.ps1` resolves the
current Claude release for the device's architecture from Anthropic's official
endpoint, downloads it, verifies it, installs it, and deletes the download.
Verification requires a chain-valid Authenticode signature **and** pins the
package identity to Claude's exact publisher (family suffix
`pzs8sxrjxfjjc`, derived from Anthropic's full signing-certificate subject) —
a package signed by any other publisher is rejected before it reaches the
deployment stack. To additionally pin the exact signing certificate, pass
`-ExpectedSignerThumbprint <SHA-1 thumbprint>` in the install command; note
that this pin must be updated whenever Anthropic renews its signing
certificate, while the default publisher pin needs no maintenance. Devices
that already have an equal-or-newer Claude skip the download entirely.

```
ClaudeIntune\
  Install-Claude.ps1
  Uninstall-Claude.ps1

IntuneWinAppUtil.exe -c .\ClaudeIntune -s Install-Claude.ps1 -o .\out
```

- New enrollments always install the **latest** release — the package never
  goes stale, so there is nothing to re-wrap or refresh, ever.
- Requires devices to reach `claude.ai` and `downloads.claude.ai` at install
  time (the same endpoints the app itself uses to run and update).

### Option B — bundle the MSIX

Wrap a specific `.msix` into the package. The install script uses the bundled
copy and never goes to the network. Choose this when install-time egress is
restricted, or when you want to pin exactly which build seeds new devices.

Download the `.msix` for your architecture:

- x64: `https://claude.ai/api/desktop/win32/x64/msix/latest/redirect`
- arm64: `https://claude.ai/api/desktop/win32/arm64/msix/latest/redirect`

```
ClaudeIntune\
  Claude-x64.msix          <- the downloaded MSIX (any Claude*.msix name works)
  Install-Claude.ps1
  Uninstall-Claude.ps1

IntuneWinAppUtil.exe -c .\ClaudeIntune -s Install-Claude.ps1 -o .\out
```

With this option, refresh the bundled `.msix` a few times a year (rebuild the
`.intunewin` with a current download and update the app content in Intune) so
newly enrolled devices don't start from an old build and immediately download
a large update. Devices that are already current are unaffected by a refresh.

## 2. Optional: configure `Detect-Claude.ps1`

As shipped (`$MinimumVersion = "0.0.0.0"`), the detection script reports
Claude as installed when **any version** is present — self-updates never break
detection and no edit is needed. Optionally, set a baseline:

```powershell
$MinimumVersion = "1.2.345.0"
```

Detection then requires **version ≥ `$MinimumVersion`**, so devices below the
baseline (for example, one whose updater never ran because the app was never
launched) are remediated by the install command instead of being reported as
already installed. With Option B, set this to the bundled MSIX's version and
bump it on each refresh.

## 3. Create the app in Intune

Apps → Windows → **Add** → App type **Windows app (Win32)**, then:

| Setting | Value |
| --- | --- |
| App package file | the `.intunewin` from step 1 |
| Install command | `powershell.exe -NoProfile -ExecutionPolicy Bypass -File Install-Claude.ps1` |
| Uninstall command | `powershell.exe -NoProfile -ExecutionPolicy Bypass -File Uninstall-Claude.ps1` |
| Install behavior | **System** (recommended — provisions Claude for every user on the device). Only choose **User** if the targeted users are local administrators: the Claude package registers a Windows service for Cowork, so per-user registration fails for standard users. |
| Device restart behavior | No specific action |
| Return codes | defaults (0 = success) |
| Requirement rules | OS architecture: x64 and arm64 with Option A (the script downloads the right one per device), or the single architecture you bundled with Option B; minimum OS Windows 10 1903 (build 18362) — the package's own minimum supported version |
| Detection rules | Rules format **Use a custom detection script** → upload `Detect-Claude.ps1`. "Run script as 32-bit process": **No**. "Enforce script signature check": **No** (or sign the script with your own code-signing cert and select Yes) |

Assign to your device or user groups as usual.

Notes on install behavior:

- **System**: the package is *provisioned* machine-wide. Users who are already
  signed in get Claude registered at their **next sign-in**; new users get it at
  first sign-in. This is the equivalent of the previous LOB/device-group setup.
- **User**: Claude installs immediately for the targeted user, no sign-out
  needed — but registering the package (which includes Cowork's Windows
  service) requires the signed-in user to be a local administrator, so this
  mode is not suitable for standard-user fleets.

## 4. Updates

Leave Claude's auto-updater enabled (do **not** set `disableAutoUpdates` on
this path). Devices stay current on their own; the detection script keeps the
Intune status green. The `autoUpdaterEnforcementHours` policy (default 72h)
controls how long a downloaded update can be deferred before Claude restarts
to apply it.

With Option A there is no package maintenance at all. With Option B, refresh
the bundled `.msix` occasionally as described in step 1.

## Migrating from a native MSIX / LOB deployment

If you previously deployed Claude as a LOB app and the deployment now shows
"installation failed" after auto-updates:

1. Create the Win32 app above and assign it to the same group.
2. `Install-Claude.ps1` detects the existing (newer) install and exits
   successfully without touching it; the detection script then reports it
   installed. No reinstall happens on devices that already have Claude.
3. Remove the assignment from (or delete) the old LOB app entry. Don't select
   "Uninstall" for the old assignment — just remove it.

## Troubleshooting

| Symptom | Explanation |
| --- | --- |
| LOB deployment shows **0x87D1041C — "application was not detected after installation completed successfully"** after Claude updates itself | Expected with the LOB app type + auto-update (exact-version detection). Use this Win32 path, or disable auto-updates and own the cadence in Intune. |
| **0x80073D06 — "a newer version of this package is already installed"** during install | The device is already ahead of the wrapped baseline (auto-updater ran). `Install-Claude.ps1` treats this as success. |
| Detection works when run manually but fails from Intune | Intune runs detection as SYSTEM; make sure you're using `Detect-Claude.ps1` from this directory (it checks `-AllUsers` and provisioned packages, and re-launches in 64-bit PowerShell). |
| Install logs | `Claude-Intune-Install-*.log` / `Claude-Intune-Uninstall-*.log` in `%TEMP%` (`C:\Windows\Temp` for system-context installs), plus the IME log `%ProgramData%\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log`. |
| Need to verify what's on a device | `Get-AppxPackage -Name Claude -AllUsers` (admin PowerShell) shows the installed version; the package family name is always `Claude_pzs8sxrjxfjjc`. |

## Package identity reference

| Field | Value |
| --- | --- |
| Package name | `Claude` |
| Package family name | `Claude_pzs8sxrjxfjjc` |
| Publisher display name | Anthropic, PBC |
| Version | increments every release; identity (name/publisher/family) never changes across updates |

The Microsoft Store build of Claude uses a different identity
(`AnthropicPBC.Claude`) and is not matched by these scripts.
