In a “Modern Workplace” ideal, every application would be a web app or a cloud-native package. However, enterprise reality often involves legacy software that relies on local configuration files stored deep within the user profile (%AppData%).

The challenge intensifies when these files aren’t just cosmetic preferences, but critical assets: software licenses, security certificates, or sensitive connection parameters.

This article explores the architectural trade-offs between traditional and modern deployment methods, with a focus on why the “Intune Win32” approach is often more complex than it appears.

1. The Legacy Approach: GPOs and Logon Scripts

For decades, the GPO-driven Logon Script was the gold standard for profile customization.

Mechanism: A PowerShell or Batch script triggers at user login, copying files from an on-premises SMB share.

Pros: Perfect synchronization; the script runs only when the user profile is mounted and ready. It handles multi-user devices natively.

Cons: Requires a line-of-sight to a Domain Controller (VPN/On-prem dependency). It lacks native idempotency—it often overwrites files every time, creating unnecessary network overhead.

2. The Hybrid Struggle: Intune Win32 Apps (User Context)

When migrating to Intune, many architects attempt to “package” the profile configuration into a Win32 app (.intunewin) set to User Context. While logical on paper, this approach often hits a technical wall during the Detection phase.

flowchart TD
    subgraph "Intune Management Extension (IME)"
        A[IME Agent - SYSTEM Context] -- triggers --> B{Detection Rule}
    end

    subgraph "User Environment"
        C[Windows Logon Process] -- mounting --> D[User Profile / HKCU]
        D -- contains --> E[AppData / Config Files]
    end

    B -- "X: Path Not Found" --> F[Status: Install Pending / Failed]
    B -- "Check: %AppData%" --> D

    style F fill:#f96,stroke:#333,stroke-width:2px
    style B stroke-dasharray: 5 5

Figure A —Intune Win32 Apps validation workflow

The Detection Rule Fallacy

The biggest hurdle is the Intune Management Extension (IME) agent. While the installation script can run as the user, the detection rule is governed by a System-level agent.

The Identity Crisis

Even in user context, the IME often evaluates detection rules using the SYSTEM account. If your rule checks HKEY_CURRENT_USER, it might be looking at the System profile’s registry instead of the logged-in user’s.

The Profile Race Condition

Microsoft documents that Win32 app detection occurs periodically. If the IME triggers a check during the exact seconds a user is logging in, the %AppData% folder or the user’s registry hive might be locked or not yet mounted. This results in “False Negatives,” where Intune reports an installation failure simply because it couldn’t “see” the user’s environment at that specific millisecond.

The Multi-User “Sticky” Detection

On shared devices, if your detection rule points to a global location (like C:\ProgramData) to avoid profile issues, Intune will mark the app as “Installed” for the whole device after the first user gets it. The second user logging in will never trigger the configuration script because Intune believes the “requirement” is already met.

Architect’s Note: Attempting to use %AppData% in a standard Intune detection rule is a leading cause of the dreaded “Install Pending” or “Fatal Error” status in the MEM portal.

The Modern Approach: Remediations & Cloud Storage

This is the most granular and “Cloud-Native” architecture, utilizing Intune Remediations.

sequenceDiagram
    participant PC as Managed Device (User Context)
    participant IME as Intune Remediation Script
    participant Azure as Azure Blob Storage (Sensitive Config)

    Note over PC, IME: Periodic Check (Every 8h)
    IME->>PC: Is config file present in %AppData%?
    alt Not Present
        PC-->>IME: No
        IME->>Azure: Request files (via SAS Token)
        Azure-->>IME: Secure Download (HTTPS)
        IME->>PC: Deploy & Verify config
    else Present
        PC-->>IME: Yes
        Note over IME: Exit (Success)
    end

Figure B — cloud native workflow using Intune Remediation

Mechanism: A detection script runs periodically to check the user’s profile. If the sensitive config is missing or outdated, a remediation script downloads the assets from a secure cloud source (e.g., Azure Blob Storage).

Pros: * Self-Healing: If a user deletes their config, it is restored automatically within hours.

True Multi-User: Scripts run independently for every user profile on the machine.

Cons: * Infrastructure Maturity: Remediations cannot “carry” files. You must host your sensitive certificates or licenses in a secure external vault or cloud storage with SAS tokens.

Complexity: Requires advanced PowerShell skills and Azure management.

Architecture Comparison Matrix

Feature GPO Logon Intune Win32 (User) Intune Remediations
Profile Stability Excellent Unstable (Race Condition) Excellent
Multi-User Support Native Poor (Global Detection) Native
Offline Capability No Yes Yes
Data Security Medium (SMB) High (Encrypted Package) Very High (Cloud Vault)
State Management None (Event-based) Basic (Detection Rule) Continuous (Self-healing)

Table 1 — Comparison matrix

Conclusion: A Matter of Compromise

Architecture is rarely about finding the “best” tool, but the right compromise for your specific constraints.

If your environment is strictly on-prem with shared desktops, GPOs still offer unmatched stability for profile timing. If you are fully remote and can afford the Azure overhead, Remediations provide the most resilient “Modern” experience.

The Win32 App approach remains a viable middle ground, provided you accept its limitations: it is a “one-shot” deployment tool rather than a continuous configuration engine. When dealing with sensitive user-level data, the key is to ensure that your Detection Rule is as robust as your installation script—often requiring “blinded” logic that accounts for the gap between the System agent and the User’s reality.

Related Posts