Intune PowerShell scripts not running: execution context, 64-bit, signing and where to look

Symptoms to confirm

• Under the script's Monitor › Device status or User status, devices show Failed, or stay Pending for days.
• The report says the script succeeded, but the change it was supposed to make isn't on the device.
• The script works when you run it by hand in an elevated PowerShell window, but not when Intune runs it.
• It ran fine on the first wave of devices and now doesn't run on new ones, or you need it to run again and can't make it.

Likely causes

• Error stream equals failure. Anything written to the error stream, including an uncaught exception or a stray Write-Error, marks the run as failed even if the work completed. The reverse also happens: an external command that fails without throwing lets the script exit 0 and report success.
• Execution policy. If Group Policy or MDM enforces a restrictive execution policy on the device, the script can be blocked; Microsoft lists reviewing execution policy as a first isolation step.
• Context dependencies. Mapped drives, the user's profile, user-scoped modules and a user-only proxy don't exist for SYSTEM. If the proxy is configured only per user, the IME can't download anything until a user signs in, or until you set the machine-wide BITS proxy with bitsadmin /util /setieproxy.
• Antivirus sandboxing. If a script reports success but did nothing, Microsoft's guidance is to check whether your antivirus is sandboxing AgentExecutor.exe.
• IME service set to Manual. After a reboot the service may not start, so no check-in and no scripts.
• +6 more causes in the full article.

Checklist

1. 1

   Read the right report

   Open the script, select Monitor, then Device status for device-targeted and User status for user-targeted assignments. Pending on every device points at targeting or the IME itself; Failed on every device points at the script.

2. 2

   Confirm the IME is present and healthy

   Check that %ProgramFiles(x86)%\Microsoft Intune Management Extension exists and that the IntuneManagementExtension service is running with startup type Automatic. If it isn't installed, go back to the prerequisites: the device must be Entra joined or hybrid joined, actually enrolled, not in S mode, and able to reach the IME endpoints for your tenant region.

3. 3

   Read the logs

   In C:\ProgramData\Microsoft\IntuneManagementExtension\Logs, IntuneManagementExtension.log shows the policy arriving and the result being reported, and AgentExecutor.log shows the actual execution, including the exit code and captured error output. Open them with CMTrace.

4. 4

   Reproduce in the same context

   For a SYSTEM-context script, test with psexec -i -s powershell.exe. For the 32-bit host, test in C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe.

5. 5

   Make the script report honestly

   Exit explicitly and keep the error stream clean on success:

   powershell

   try {
       # work goes here
       New-Item -Path 'HKLM:\SOFTWARE\Contoso' -Force | Out-Null
       Write-Output "Done"
       exit 0
   }
   catch {
       Write-Error $_.Exception.Message
       exit 1
   }

6. 6

   Fix signing or turn the check off

   If Enforce script signature check is Yes, sign the script with a code-signing certificate the device trusts, and deploy that trust first. If you don't need signing, set it to No.

7. 7

   Re-run it the supported way

   Edit the script (even a comment change), re-upload it, or change the assignment; the device runs it at the next IME check-in. Restarting the IntuneManagementExtension service or rebooting triggers a check-in immediately.

Tip: If you need a script to run on a schedule, run again when something drifts, or produce a readable output per device, you've outgrown platform scripts. Remediations give you a detection script, a remediation script, a recurring schedule and an on-demand run from the device page, and the output lands in the admin center.

Verify

• Device status shows Succeeded for the device, and AgentExecutor.log shows exit code 0 with an empty error output.
• The change is on the device in the place you expected, for example under the 64-bit registry view rather than WOW6432Node.
• A newly enrolled device in the same group gets the script on its first IME check-in without any manual help.

Key takeaways

• Decide the context first: SYSTEM or user, 32-bit or 64-bit, signed or not. Most failures are a mismatch between what the script assumes and how the IME runs it.
• A platform script is a run-once tool with three retries. If you need recurrence or reporting, use Remediations.
• Treat the error stream as your status signal: clean on success, explicit on failure.
• Test with psexec -s and the SysWOW64 PowerShell before you assign to production groups.