Listen to this Post
Introduction:
Microsoft Intune Win32 app deployments often fail silently or hang indefinitely due to subtle permission mismatches between the installer’s execution context and target folders. In enterprise environments, using SYSTEM context to write logs to protected paths like `C:\Program Files\App\Logs` triggers access denied errors—manifesting as error 0x87D300C9 and endless “Installing…” states in Company Portal. This article dissects a real-world case, provides step‑by‑step remediation, and offers hardened packaging standards to prevent recurrence.
Learning Objectives:
- Diagnose Intune Win32 app stuck in “Installing…” state using local logs and error code 0x87D300C9.
- Identify and remediate folder permission conflicts between SYSTEM context installer and protected directories.
- Apply proactive packaging standards, including log path relocation to `C:\ProgramData` and validation of detection rules.
You Should Know:
1. Decoding Error 0x87D300C9 – The “Installing” Trap
The error code 0x87D300C9 in Intune generally signals a failure during the installation phase where the Intune Management Extension cannot confirm successful completion. In the real example, the app remained in “Installing…” because the installer (running as SYSTEM) tried to write logs to `C:\Program Files\App\Logs` – a directory that, by default, grants modify permissions only to TrustedInstaller and Administrators, not to SYSTEM in all scenarios (especially when folder creation is attempted during installation). The installer failed silently, and Intune never received a detection rule match.
Step‑by‑step guide to replicate and verify the issue locally:
– Open an elevated Command Prompt on a test device.
– Use PsExec (from Sysinternals) to simulate SYSTEM context:
psexec -i -s cmd.exe
– Inside the SYSTEM shell, attempt to create the log folder and write a test file:
mkdir "C:\Program Files\App\Logs" echo test > "C:\Program Files\App\Logs\test.log"
– If access denied, the same will happen during Intune deployment.
– Then test the recommended fix:
mkdir "C:\ProgramData\App\Logs" echo test > "C:\ProgramData\App\Logs\test.log"
– Success indicates that `C:\ProgramData` (which grants write to SYSTEM) is the correct log destination.
2. Forensic Log Analysis: Finding the Silent Failure
Intune Win32 deployments write detailed logs locally. The most valuable for this scenario are IntuneManagementExtension.log, AppWorkload.log, and AgentExecutor.log. They often contain “Access Denied” or “CreateFile failed” entries even when Company Portal shows only “Installing…”.
Step‑by‑step guide to extract and analyze logs:
- On the affected Windows device, open PowerShell as Administrator.
- Navigate to the Intune log directory:
cd "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs"
- Search for the specific app’s installation attempt (replace
YourAppName):Select-String -Path ".log" -Pattern "YourAppName|0x87D300C9|Access Denied" | Out-File C:\temp\Intune_Errors.txt
- Open `AgentExecutor.log` and look for lines containing “Exit code” – a missing exit code or non‑zero exit code indicates failure.
- In
AppWorkload.log, find the `Detection rule` section; if detection never runs, the install never completed. - Cross‑reference timestamps with `IntuneManagementExtension.log` to see if the IME retried the installation.
3. Validating Install Commands and SYSTEM Context Permissions
Many enterprise packagers mistakenly assume SYSTEM has full write access everywhere. In reality, SYSTEM lacks write permissions to `C:\Program Files` subfolders that are not pre‑created with proper ACLs. The fix is to redirect logs to `C:\ProgramData\App\Logs` or %ProgramData%\App\Logs.
Step‑by‑step guide to modify and redeploy the Win32 app:
– Repackage the application (using IntuneWinAppUtil.exe) with the install command changed to write logs to C:\ProgramData\App\Logs.
– Example install command before:
setup.exe /quiet /log "C:\Program Files\App\Logs\install.log"
– After fix:
mkdir "C:\ProgramData\App\Logs" 2>nul & setup.exe /quiet /log "C:\ProgramData\App\Logs\install.log"
– Ensure the uninstall command also uses `ProgramData` or cleans up accordingly.
– In Intune Admin Center, under Apps → Win32 → Properties, update the install command.
– Set Install behavior to System (which uses SYSTEM context) – do not change to User unless required.
– Re‑upload the .intunewin file and redeploy to a test group.
4. Detection Rules That Don’t Lie
A common oversight: detection rules that rely on files or registry keys written to a protected location. If the installer fails to create those artifacts, Intune will never mark the app as installed – leading to endless retries.
Step‑by‑step guide to create robust detection rules:
- After changing log path to
C:\ProgramData, also ensure that the application’s main executable or a version file is placed in a writable location (e.g., `C:\Program Files\App` only for binaries; logs and state files go toProgramData). - For detection, use a registry key under `HKLM\Software\YourApp` – SYSTEM has full access.
- Alternatively, detect a file in `C:\ProgramData\YourApp\installed.flag` that the installer creates at the very end.
- Example detection script (PowerShell) that Intune can call:
if (Test-Path "C:\ProgramData\App\version.txt") { exit 0 } else { exit 1 } - In Intune, under Detection rules, choose “Use a custom detection script” and upload the script. Ensure the script runs in 64‑bit context if needed.
5. Security Policies: WDAC, Antivirus, and AppLocker Interference
Modern security controls like Windows Defender Application Control (WDAC) or third‑party antivirus can block installers from writing logs or creating new folders – even for SYSTEM. This often manifests as the same 0x87D300C9 error.
Step‑by‑step guide to identify and mitigate policy blocks:
- Check the Code Integrity operational log for WDAC blocks:
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" | Where-Object { $_.Message -match "blocked" } - Temporarily enable WDAC audit mode to see if policies are interfering:
Set-RuleOption -Option 3 -Delete Audit mode (requires reboot)
- For antivirus, exclude `C:\ProgramData\Microsoft\IntuneManagementExtension` and the app’s install folder from real‑time scanning via Group Policy or Intune configuration profile.
- If AppLocker is enforcing executable rules, ensure that the installer binary (e.g., `setup.exe` dropped by Intune) is allowed under `%ProgramData%` paths.
6. Proactive Packaging Standards for Enterprise Intune
To avoid “Installing…” states and silent failures, enforce a packaging checklist before any Win32 app is uploaded to Intune.
Step‑by‑step guide to build a standard operating procedure:
- Use a dedicated packaging VM with no internet access to avoid contamination.
- Always test install under SYSTEM using `psexec -i -s cmd.exe` and manually run the install command.
- Redirect all write operations (logs, temp files, user data) to
%ProgramData%\CompanyName\AppName. - Never hardcode `C:\Program Files` for writable artifacts.
- Include a `PreInstall` script to create folder structure with proper ACLs:
if not exist "C:\ProgramData\App\Logs" mkdir "C:\ProgramData\App\Logs" icacls "C:\ProgramData\App\Logs" /grant "SYSTEM:(OI)(CI)F" /T
- Validate detection rules using the same SYSTEM context.
- Deploy to a pilot group of 5‑10 devices and monitor `AgentExecutor.log` for 24 hours before broad release.
7. Rapid Remediation via Intune Remediations (Proactive Scripts)
For apps already stuck in “Installing…” across thousands of devices, you can deploy a proactive remediation script that kills the hung installation and resets the log folder permissions.
Step‑by‑step guide to create an Intune remediation:
- Detection script (checks for stuck app):
$appName = "YourApp" $log = "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs\AgentExecutor.log" $stuck = Select-String -Path $log -Pattern "$appName.Installing" -Context 0,5 | Where-Object { $_.Line -match "0x87D300C9" } if ($stuck) { Write-Output "Stuck detected"; exit 1 } else { exit 0 } - Remediation script (force cleanup):
Stop-Service -1ame IntuneManagementExtension -Force Remove-Item "$env:ProgramData\Microsoft\IntuneManagementExtension\Policies\" -Recurse -Force Remove-Item "$env:ProgramData\Microsoft\IntuneManagementExtension\Staging\" -Recurse -Force Recreate correct log permissions icacls "C:\ProgramData\App\Logs" /grant "SYSTEM:(OI)(CI)F" /T Start-Service -1ame IntuneManagementExtension Trigger new sync Get-ScheduledTask | ? TaskName -like "Intune" | Start-ScheduledTask
- Assign the remediation to the affected device group in Intune.
What Undercode Say:
- Key Takeaway 1: The difference between `C:\Program Files` and `C:\ProgramData` is not just convenience – it’s a security boundary. SYSTEM context installers must never write logs or dynamic data to `Program Files` unless the folder is pre‑created with explicit SYSTEM write ACLs.
- Key Takeaway 2: Error 0x87D300C9 is a “silent killer” in Intune deployments because it often does not produce a user‑visible error; only log analysis reveals permission denials. Always simulate the install under SYSTEM on a clean test VM before packaging.
- Analysis (10 lines): This real‑world scenario highlights a systemic flaw in many enterprise packaging workflows: assuming SYSTEM has unlimited file system access. In modern Windows versions, even SYSTEM respects folder inheritance and security descriptors. The fix – moving logs to `C:\ProgramData` – is simple, but the troubleshooting process reveals deeper needs: consistent log review, use of tools like PsExec, and proactive permission hardening. Organizations that adopt a “write‑only to ProgramData” rule for all Win32 apps will drastically reduce deployment failures. Moreover, this case underscores the importance of detection rule design – if detection depends on a file that never gets written, Intune enters an infinite retry loop. Finally, security policies (WDAC, antivirus) must be audited alongside folder permissions, as they can independently block SYSTEM writes. Moving forward, packaging teams should include a permission validation step in their CI/CD for Intune deployments.
Prediction:
- -1: As Intune adoption accelerates for Windows endpoint management, more organizations will encounter similar permission errors due to legacy installers designed for user‑context or admin‑only installations. Without standardised packaging guidelines, helpdesk tickets for “stuck installing” apps will increase by 30–40% over the next 18 months.
- +1: Microsoft is likely to improve IntuneManagementExtension logging to surface specific “access denied” paths directly in the Company Portal error details, reducing mean time to resolution. Additionally, the trend toward cloud‑native endpoint management will drive the creation of community‑maintained packaging templates that automatically redirect writable paths to
ProgramData.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Shamseersiddiqui Microsoftintune – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
