Per-User Applications vs System Deployment | Juriba

During a recent discussion with a customer, we encountered an issue that initially appeared to be a standard application packaging failure. The application was deployed successfully, but users were unable to launch it. Further investigation showed that the package itself was not defective; the issue stemmed from a mismatch between the application’s design and the deployment context.

This scenario is not uncommon and reflects a broader pattern that many packaging and endpoint teams encounter when managing application readiness at scale.

The Root Cause: Installation Context Mismatch

Enterprise deployment tools such as Microsoft Intune and Configuration Manager frequently install applications in the SYSTEM context. This approach works well for traditional, machine‑wide applications but is incompatible with software designed for per‑user installation.

What Happens in Practice

Consider an EXE‑based application such as Postman:

• The application is designed to install to %LOCALAPPDATA%
• It is repackaged into an MSI
• It is deployed via Intune using the SYSTEM context

 During installation, %LOCALAPPDATA% resolves to: 

As a result:

• Application files are installed under the SYSTEM profile

• Shortcuts reference to that location
• When a user logs in, their profile path differs
• The shortcut points to a non‑existent location
• The application fails to launch
  

 The deployment may appear successful, but the application is effectively unusable.  

Application Design Matters

Many modern applications are intentionally built for per‑user installation. Electron‑based applications are a common example. These applications typically:

• Install into %LOCALAPPDATA%
• Avoid requiring administrative privileges
• Rely on user‑level write access
• Manage updates within the user context

Common examples include:

• Postman
• Slack
• Discord
• Visual Studio Code (user installer)

This behavior is by design, not a packaging defect.

Why Repackaging Is Not the Real Problem

Repackaging an EXE into an MSI does not change the application's fundamental design. App Readiness generates well‑constructed packages to correctly use environment variables and avoid hard‑coded paths.

The failure occurs at installation time, not during packaging:

• %LOCALAPPDATA% resolves differently depending on execution context
• SYSTEM installs write into the system profile
• User‑context applications expect files within the user profile

The result is broken shortcuts, missing files, and failed launches—despite technically correct packaging.

Technical Deep Dive: Environment Variables, Shortcuts, and Updates

Let’s break the problem down further.

Environment Variable Resolution

Shortcut Behavior

Shortcuts created during SYSTEM installation:

• Point to system profile paths
• Are not dynamically adjusted per user

File System Ownership

Files installed under SYSTEM profile are: 

• Not visible in the user profile

• Not accessible via expected paths

Update Mechanisms

These modern apps often:

• Run auto-updaters in user context
• Expect write access to user profile

When installed in SYSTEM context:

• Updates fail silently
• Versions drift
• Support issues increase

Deployment Options for Per-User Applications

There is no universal solution. The correct approach depends on the application.

Option 1: Deploy in User Context (Recommended)

• Install behavior: User
• Assignment: User‑based, not device‑based

This ensures correct path resolution and application behavior.

Trade-offs

• Per‑user installation increases disk usage
• Requires user sign‑in

 A common mistake is combining user‑context installs with device‑based assignment, which can lead to inconsistent results.

Option 2: Use Vendor‑Provided Machine Installers

When available, prefer vendor‑supplied enterprise or machine‑wide installers that:

• Install into Program Files
• Support SYSTEM context deployment
• Avoid user‑specific assumptions

Option 3: Advanced Repackaging

If repackaging is unavoidable, additional work is required:

• Redirect installation paths
• Correct shortcuts
• Disable or manage auto‑updaters
• Remove user‑specific dependencies

This typically requires custom scripting and deep application knowledge.

Option 4: Hybrid Deployment Model

Deploy a SYSTEM‑level stub that triggers a user‑context installation at logon. Common techniques include:

• Active Setup
• Scheduled tasks
• Logon scripts

This approach balances centralized control with correct execution context. This option provides flexibility, but it requires additional effort and is not trivial to implement, also requires ongoing maintenance.

Option 5: Accept Per‑User Application Models

Some applications are inherently user‑scoped. Adopting a deployment strategy that accommodates this reality reduces complexity and failures.

Common Mistakes to Avoid

• Blind EXE‑to‑MSI repackaging
• Forcing ALLUSERS=1
• Ignoring installation context
• Breaking vendor update mechanisms

These practices often result in deployments that succeed technically but fail in real‑world use.

A Practical Guideline for Packaging Teams

Before packaging any application, ask:

Where is this application designed to install?

If the answer is %LOCALAPPDATA%, treat it as a user‑context application by default.

Conclusion: Match Deployment Context to Application Design

This is not a tooling or platform issue. It is an alignment problem between application design and deployment context.

Modern applications are often built for user autonomy, minimal privileges, and self‑service updates. Forcing them into system‑level deployment models leads to avoidable failures.

Match the installation context to the application design.
When these align, deployments are stable and predictable. When they do not, troubleshooting “successful” deployments becomes inevitable.

If you encounter broken shortcuts or applications that will not launch after deployment, installation context should be one of the first factors you examine.