Per-Machine vs Per-User Installs in Intune: Getting the Context Right in 2026

Getting install context wrong is one of the most reliable ways to burn an afternoon. The app deploys without error, Intune reports success, and then a user calls because nothing appears in their Start menu. Or it installs fine for one user and silently fails for everyone else on the same endpoint.

Install context — per-machine versus per-user — sits upstream of almost every other packaging decision you make in Intune. Get it right once and deployments work. Get it wrong and you are chasing ghost failures across your device inventory.

This article covers how Intune handles install context, when to use each mode, what breaks when you pick the wrong one, and how to write detection rules that actually match your choice.

What Install Context Actually Controls

When Intune deploys a Win32 app, it calls the Intune Management Extension (IME) on the endpoint. The IME runs your install command under one of two security contexts:

• System context (per-machine): The installer runs as NT AUTHORITY\SYSTEM. No user session required. The app writes to HKEY_LOCAL_MACHINE, installs to C:\Program Files, and is available to every user on the endpoint.
• User context (per-user): The installer runs as the logged-in user. The app writes to HKEY_CURRENT_USER, typically installs to %LOCALAPPDATA% or %APPDATA%, and is visible only to that user.

The Intune portal calls this the Install behavior field. It lives in the Win32 app configuration under Program settings. Your two options are System and User.

That single dropdown has more downstream consequences than almost any other setting in the deployment.

When to Use System Context (Per-Machine)

System context is the right default for the vast majority of enterprise deployments. Use it when:

• The app needs to be available to all users on a shared or multi-user endpoint
• The installer writes to HKLM or C:\Program Files
• The app installs services, drivers, or kernel components
• You are deploying to device groups rather than user groups
• The install needs to complete before any user logs in — Autopilot provisioning, for example

Most traditional enterprise software belongs here. Office add-ins, endpoint agents, LOB tools, anything that touches Program Files — all system context.

Gotcha: Some installers silently switch to a per-user path even when called from SYSTEM. Certain NSIS and Inno Setup packages detect the running context and redirect to %LOCALAPPDATA%. If your detection rule is looking in Program Files but the app landed in C:\Users\Default\AppData, it will fail. Always verify the actual install path by running the installer manually under SYSTEM — via PsExec or a test deployment — before writing your detection rule.

When to Use User Context (Per-User)

User context is appropriate when:

• The app is explicitly designed for per-user installation and has no per-machine installer
• You are deploying to user groups and the app should follow the user, not the device
• The app writes exclusively to HKCU and %APPDATA%
• You are deploying a portable or self-contained tool that does not need system-level access

The catch: user context deployments require an active user session. If the device is at the login screen or the target user has not logged in yet, the IME cannot execute the install. Autopilot enrollment in user-driven mode can handle this, but device-targeted deployments to endpoints with no logged-in user will queue indefinitely.

One more thing: user context installs do not work with device group targeting. If you assign a user-context app to a device group, Intune will not install it. Always assign user-context apps to user groups.

The Detection Rule Must Match the Install Context

This is where most context mismatches surface. You set the install behavior to System, but your detection rule checks HKEY_CURRENT_USER. The install succeeds, SYSTEM writes the registry key to HKLM, and your detection rule comes back empty because it is looking in the wrong hive.

File-Based Detection

If the app installs to C:\Program Files\AppName\app.exe under system context, your detection rule should be:

• Path: C:\Program Files\AppName
• File or folder: app.exe
• Detection method: File or folder exists — or version comparison if you need precision

Do not use %ProgramFiles% as the path in the Intune portal. Spell it out. Environment variable expansion in detection rules is inconsistent across IME versions.

Registry-Based Detection

For system context installs, target HKEY_LOCAL_MACHINE:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{ProductGUID}

For user context installs, target HKEY_CURRENT_USER:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{ProductGUID}

Gotcha: 32-bit apps installed on 64-bit Windows write to the SOFTWARE\WOW6432Node path under HKLM. If your detection rule targets HKLM\SOFTWARE\... but the app is 32-bit, the key will not be there. Check the actual registry path on a test endpoint before finalizing the rule.

Install Context and the Silent Switch Relationship

Install context and silent switches are tightly coupled. A switch that works perfectly under a user session may behave differently under SYSTEM — particularly for installers that check for elevation or redirect paths based on context.

Common patterns by installer type:

• Inno Setup: /VERYSILENT /SUPPRESSMSGBOXES /NORESTART works in both contexts, but the install destination may differ. Under SYSTEM, Inno Setup typically defaults to C:\Program Files. Under a user account, it may default to %LOCALAPPDATA%\Programs.
• NSIS: /S is the standard silent flag. Some NSIS packages include context-aware path logic. Run strings against the binary or check the installer script if you have access.
• InstallShield: /s /v"/qn" for older packages, /quiet for newer ones. InstallShield packages often write to HKLM regardless of context — but verify.

If you are spending time hunting these switches manually, that is exactly what InstallMage's EXE to MSI conversion pipeline eliminates. The AI engine identifies the installer framework, extracts the correct silent arguments, and compiles a WiX-based MSI wrapper with the right switches already embedded. You get a deployable package — not a starting point for more research. For the full framework-by-framework reference, see the silent install switches guide.

32-Bit vs 64-Bit Installer Context

The Run installation as 32-bit process on 64-bit clients checkbox in Intune's Win32 app configuration interacts directly with install context. Enabling it forces the installer to run under WOW64, which redirects:

• C:\Program Files → C:\Program Files (x86)
• HKLM\SOFTWARE → HKLM\SOFTWARE\WOW6432Node

Enable this option but target 64-bit paths in your detection rule and detection fails. Disable it but deploy a 32-bit binary that expects WOW64 redirection and the install may succeed while writing files to unexpected locations.

The rule: match the 32-bit checkbox to the actual bitness of the installer binary, then write your detection rule against the resulting registry and file paths.

Supersedence and Install Context

When you configure supersedence relationships in Intune, the uninstall of the older app runs in the same install context as the new app's deployment. If the old version was installed per-machine and you are deploying the new version per-user, the uninstall may fail silently — SYSTEM cannot find the per-user install record.

Document the install context for every app you deploy. When you create a supersedence relationship, verify that both the old and new deployments share the same context. If they do not, the uninstall string will not resolve and you will end up with both versions coexisting on the endpoint.

For a broader look at how these decisions fit into a complete deployment workflow, the Intune deployment best practices guide covers detection rules, supersedence, and assignment targeting in more depth.

MSI vs EXE and Install Context

Pure MSI packages deployed as LOB apps in Intune always run under SYSTEM. You do not get a choice. That is one reason wrapping a legacy EXE into an MSI before deployment gives you more predictable behavior — the install context is fixed and the Windows Installer service handles execution.

Win32 app deployments give you the context toggle. If you are deploying an EXE directly as a Win32 app, you control the context. If you have wrapped it in an MSI, the MSI's own install logic applies, but Intune still calls it under SYSTEM for LOB deployments.

The .intunewin vs MSI comparison breaks down when each format is the right choice and what each one gives you in terms of Intune feature access.

A Practical Decision Framework

Before you configure any Win32 app in Intune, answer these four questions:

1. Where does the app install? Program Files means per-machine. %LOCALAPPDATA% means per-user.
2. Who needs the app? All users on a device means per-machine. Specific users following their profile means per-user.
3. Does the deployment need to run without a logged-in user? Yes means per-machine.
4. What does the detection rule target? HKLM or C:\Program Files means per-machine. HKCU or %APPDATA% means per-user.

If your answers point in different directions, the app's actual install behavior wins. Test the installer under SYSTEM using psexec -s -i cmd.exe on a test endpoint, then observe where files and registry keys actually land. Write your detection rule against observed reality — not assumptions.

Where InstallMage Fits

The install context decision is yours to make. No tool makes it for you. But the packaging work that follows that decision is fully automatable.

When InstallMage converts your EXE, it outputs the package plus ready-to-paste Intune deployment commands, detection rule GUIDs, and uninstall strings — generated based on the actual installer behavior the AI engine observes during conversion. You still need to verify the install context setting in the Intune portal, but the detection rule and uninstall string are already written.

That last-mile step — the one where most admins spend 30 to 60 minutes per package — is done. Start with a free conversion at installmage.com.

FAQs

What happens if I deploy a per-user app to a device group in Intune?

Intune will not install it. User context deployments require an active user session and must be assigned to user groups. Device group targeting with user context results in the deployment queuing indefinitely or reporting as not applicable.

Can I change the install context after deploying an app?

Not cleanly. Changing the install behavior on an existing Win32 app effectively creates a different deployment. The old install — under the previous context — will not be automatically removed. Handle uninstallation of the previous version separately before redeploying under the new context.

Why does my detection rule fail even though the app installed successfully?

The most common cause is a context mismatch. The app installed under SYSTEM and wrote to HKLM, but the detection rule targets HKCU. Or the app is 32-bit and wrote to WOW6432Node, but the detection rule targets the standard 64-bit path. Check the actual registry and file paths on a test endpoint after installation.

Does install context affect app removal in Intune?

Yes. The uninstall command runs in the same context as the install behavior setting. If the app was installed under SYSTEM but you attempt uninstall under user context — or vice versa — the uninstall string may not resolve and the removal will fail silently.

What is the difference between install context and the 32-bit process checkbox in Intune?

Install context controls which security principal runs the installer — SYSTEM versus the logged-in user. The 32-bit checkbox controls whether the installer runs under WOW64 emulation on 64-bit Windows. Both affect where files and registry keys land, so both must be consistent with your detection rule.

How do I test an installer under SYSTEM context before deploying?

Use psexec -s -i cmd.exe from an elevated command prompt on a test endpoint. This opens a command prompt running as SYSTEM. Run your installer from there and observe where it writes files and registry keys. That is your detection rule source of truth.

Does wrapping an EXE in an MSI fix install context issues?

It standardizes execution — MSI packages deployed as LOB apps always run under SYSTEM. But it does not eliminate the need to verify where the underlying installer writes its files. The WiX wrapper controls the outer shell; the inner EXE's install logic still applies. Always test on a clean endpoint after conversion.