Intune Error 0x80070005 (Access Denied): Why SYSTEM Still Gets Blocked

Q: What does Intune error 0x80070005 mean?

It is ERROR_ACCESS_DENIED. The install, or a step inside it, was refused access to a file, registry key, service or network path. It does not say which, so use Process Monitor or a verbose MSI log to identify the resource.

Q: Why do I get 0x80070005 when the app runs as SYSTEM?

SYSTEM is privileged locally but has no user profile, mapped drives or user network credentials, and it cannot override protected objects such as tamper-protected services. The denial is almost always one of those, not a missing admin right.

0x80070005 is ERROR_ACCESS_DENIED, and in Intune it almost never means "you lack admin rights". For a wrapped EXE installer it means something running as SYSTEM, or as a standard user, tried to touch a file, key, service or share it was not allowed to touch. The portal shows the code and no path, so the fix starts with finding what was denied.

Here is where the denial usually comes from, how to find it in minutes, and how to remove the class of failure instead of patching it app by app.

Fast Verdict Matrix

Denied Resource	Legacy EXE Behavior	Native MSI Behavior
Writes under the user profile or HKCU	Setup writes to `%APPDATA%` or HKCU. Under SYSTEM that is the wrong profile, or the write is blocked.	Per-machine files and HKLM keys only. Per-user data is created at first launch by the app.
Network paths and mapped drives	Setup reads a UNC path or drive letter. SYSTEM has no mapped drives and uses the computer account.	Payload is embedded in the package and read from the local IME cache.
Protected folders and services	Overwrites a file held by a running service, or stops a protected service, and gets denied.	Installer stops and starts services through defined actions and defers locked files to reboot.
Diagnosability	Exit code only. Which resource was denied is unknown.	Verbose log names the action, and `Error 1925` or `1303` points at the denied target.

The Rule of Thumb

Treat 0x80070005 as a path problem, not a privilege problem. SYSTEM outranks local administrators, so the denial is a wrong profile, an unreachable share, or a protected object, and Process Monitor will name it.
Stop reading from places SYSTEM cannot reach. Anything the install needs should be inside the package, not on a share or in a user profile.

The Fix: Remove the Dependency

The usual workaround is a PowerShell wrapper such as PSAppDeployToolkit that copies files locally, adjusts ACLs, stops services and retries. It works until the next vendor update changes which path the setup touches, and then someone debugs the script again.

InstallMage converts the EXE into a native MSI with the payload embedded and every file and registry write expressed as a per-machine table entry. Nothing is fetched from a share, nothing depends on a profile, and the install runs under SYSTEM exactly as it was tested. No PSADT wrapper and no ACL scripts.

Deep Dive

Finding the Denied Resource

Reproduce the install as SYSTEM, then capture file and registry activity with Process Monitor filtered on Result is ACCESS DENIED:

psexec -i -s cmd.exe
procmon /AcceptEula /Minimized /BackingFile C:\Windows\Temp\denied.pml
setup.exe /S
:: In Procmon: Filter > Result is ACCESS DENIED > Include

The first denied entry after the setup process starts is usually the cause. A path under C:\Users\<name> points to a profile problem. A path beginning \\server\share points to a network dependency. A path under C:\Windows\System32 or a service key points to a protected object. The Intune side only records the code, in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.

SYSTEM Cannot Use Your Network Identity

On a domain-joined device SYSTEM authenticates to the network as the computer account. A share that grants access to a user group denies it, and an Entra joined device with no line of sight to a file server cannot reach it at all. The manual test passed because you ran it as yourself with your drives mapped. That is the same context gap described in the SYSTEM vs user context guide, and the status code reference in the Intune error codes guide lists where 0x80070005 sits among the other Intune codes.

Protected Objects and Locked Files

An upgrade that replaces a file loaded by a running service or by security software is denied, and so is a setup that tries to stop a service with a restricted ACL. Windows Installer handles the locked-file case by scheduling a replacement at the next restart and returning 3010, which is covered in the reboot handling guide. A bare EXE usually aborts instead. Tamper protection and controlled folder access also return access denied to installers, so check the endpoint protection logs before changing the package.

Frequently Asked Questions

What does Intune error 0x80070005 mean?

It is ERROR_ACCESS_DENIED. The install, or a step inside it, was refused access to a file, registry key, service or network path. It does not say which, so you need Process Monitor or a verbose MSI log to identify the resource.

Why do I get 0x80070005 when the app runs as SYSTEM?

SYSTEM is highly privileged locally but has no user profile mapped drives or user network credentials, and it cannot override protected objects such as tamper protected services. The denial is almost always one of those rather than a missing admin right.

How do I fix 0x80070005 without a PowerShell wrapper?

Remove what the installer needs from outside the machine: embed the payload, write only per-machine locations, and let Windows Installer manage services and locked files. Converting the EXE to a native MSI with InstallMage does this, so no ACL or copy script is required.

0x80070005 points to a place SYSTEM cannot reach. Find it with Process Monitor, then package the dependency away so the same denial cannot return on the next update.