Intune PowerShell Script Not Running: What to Check First

Intune PowerShell script not running is nearly always documented behaviour rather than a fault. The management extension runs a script once, in a 32-bit host by default, only on devices that are properly joined, and only while the device clock is roughly right. None of those produce an error anywhere in the admin centre, which is why the results ranking for this problem are mostly unanswered Microsoft Q&A threads. Below is each limit in Microsoft’s own words, the order I would check them in, and the place its own article disagrees with itself. It sits inside the wider Intune troubleshooting order, layer by layer.

One naming point first, because it wastes time. In the admin centre these objects live under Devices, Scripts and remediations, Platform scripts. The documentation still calls them PowerShell scripts, and the monitoring blade inside the same article is labelled PowerShell scripts as well. They are the same thing. They are not the same as remediation scripts, which have their own licence gate, their own schedule and their own exit code contract.

The script already ran, so it will not run again

Rule this out first. It accounts for most reports where nothing visible happens on a device that is otherwise healthy. Microsoft states it plainly: “Once the script executes, it doesn’t execute again unless there’s a change in the script or policy.”

Two consequences follow, and neither is visible in the admin centre. Editing the script body counts as a change, so a corrected script will run again. But a device that has already reported Succeeded is finished with that policy, and re-targeting the same unchanged script at the same device achieves nothing at all. Admins in Microsoft’s own Q&A forum report that renaming the script is enough to make the service treat it as a new policy. I have not verified that against the documentation, because the documentation never defines what counts as a policy change.

Failure has a hard stop as well: “If the script fails, the Intune management extension retries the script three times for the next three consecutive Intune management extension check-ins.” After the third attempt nothing further happens, and the status in the admin centre keeps showing the last result it recorded. A script that has been failing for a week is not still trying. Forcing a check-in will not revive it either, which is one of the cases in what a forced Intune sync does not fix.

The article also disagrees with itself about sign-ins. Its Before you begin section says device-assigned scripts run “for every new user that signs in, except on multi-session SKUs where user check-in is disabled”. Its troubleshooting section says “The PowerShell scripts don’t run at every sign in” and then lists only two triggers: when the script is assigned to a device, and if you change the script, upload it and assign it. Both sentences are in the same article, on the date below. I would design for the narrower reading and make every script idempotent, so that it does not matter which one is current.

Devices that never receive the script at all

If a device does not appear in the script’s Device status list, the assignment never reached it. That is a different problem from a script that ran and did nothing, and four documented exclusions cause it.

• Registered, not joined. “Devices that are only registered with your workplace or organization in Microsoft Entra ID don’t receive the scripts.” A personal device brought in through registration is outside scope entirely.
• Workplace joined devices ignore user targeting. “However, when targeting workplace joined (WPJ) devices, only Microsoft Entra device security groups can be used (user targeting is ignored).” A user group assignment across a WPJ estate looks correct in the portal and delivers nothing.
• Surface Hub and S mode. “Scripts don’t run on Surface Hubs or Windows in S mode.”
• No extension yet. “Intune management extension installs automatically when a PowerShell script app is assigned to the user or device.” The assignment is what triggers the install, so the first script on a fresh device waits for the agent to arrive. Where the agent is missing or has gone, the detail is in what installs the management extension, and why it goes missing.

The agent removing itself is the exclusion nobody expects: “When the IME is unable to check in, it retries checking in for up to 24 hours (device-awake time) and then removes itself from the Windows device.” A device that was offline, or blocked at the proxy, for a day comes back without the component that runs scripts.

The 32-bit host, and the script that works on your own desk

The setting that chooses the PowerShell host defaults to No, and Microsoft’s description of that default leaves no room: “No (default) runs the script in a 32-bit PowerShell host.” The capture snippet in the same article points at the SysWOW64 copy of PowerShell, which is the 32-bit host on a 64-bit machine, so the documentation demonstrates the default while describing it.

That default is the most common reason a script that works in an elevated console on an engineer’s machine does nothing under Intune and says nothing about why. A 32-bit process on 64-bit Windows gets the 32-bit view of the registry and of Program Files, so a key written by a 64-bit installer, or a module installed for the 64-bit host, is not where the script is looking. The script finds nothing and exits clean.

There is a second edge in the same table. New scripts default to the 32-bit host, while policies created before the setting existed keep the host they already had until that setting is changed. Reading the toggle in the portal does not tell you what an older policy has been doing.

Limits that stop a run you believed had succeeded

• Size. “The script must be less than 200 KB (ASCII).”
• Time. “PowerShell scripts time out after 30 minutes.” Anything that waits on a large download, a reboot or a user is a poor fit for this surface.
• Clock. “Scripts deployed to clients running the Intune management extension fails to run if the device’s system clock is exceedingly out of date by months or years.” Microsoft gives no threshold and no error. A machine that has been in a drawer since last year qualifies.
• Order. “PowerShell scripts are executed before Win32 apps run.” A script that depends on an application already being present will fail on a freshly built device, which is one reason to keep it separate from the parts of Win32 app deployment that break rather than sequencing the two.

Where the evidence is

Two logs answer two different questions, and both sit in the folder Microsoft lists in its Win32 troubleshooting guide.

1# The management extension log folder. IntuneManagementExtension.log answers whether
2# the policy arrived on the device. AgentExecutor.log answers what the script then did.
3C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
4    IntuneManagementExtension.log
5    AgentExecutor.log
6    ClientHealth.log
7    _IntuneManagementExtension.log

If the script never appears in IntuneManagementExtension.log, go back to the targeting section above. If it appears and AgentExecutor.log shows a clean exit, the answer is less comfortable. Below is a verbatim extract an admin posted in the Microsoft Q&A thread linked at the end of this article, on a case where platform scripts never ran on fresh Windows 11 devices.

1# AgentExecutor.log, as posted by an admin in the thread linked below
2PowerShell path is C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
3[Executor] created powershell with process id 22876
4Powershell exit code is 0
5length of out=2
6length of error=2
7Powershell script is successfully executed.

My reading of that is an exit code of 0 with two bytes of output, which is a bare line ending and nothing else. Intune records it as Succeeded, because the exit code is the only thing it grades. That moves the investigation off Intune and into the script, and the 32-bit host above is usually what it turns out to be.

One warning in the article catches anyone trying to reproduce a run by hand: “Remember, the Intune Management Extension cleans up the logs after the script executes”. It sits next to a snippet whose entire purpose is to keep the output and error files for review, so plan to capture them rather than expecting to find them afterwards.

Intune PowerShell script not running: the order I would check

1. Open the script’s Device status list. If the device is absent, this is a targeting problem and not a script problem.
2. Confirm the device is Entra joined or hybrid joined rather than merely registered, and that any workplace joined device is targeted through a device group.
3. Confirm the device is not a Surface Hub and is not running Windows in S mode.
4. Confirm the management extension is installed, its service is running, and the device has checked in inside the last 24 hours.
5. Check whether the script has already reported Succeeded. If it has, nothing more will happen until the script or the policy changes.
6. Check the 64-bit host setting, then re-test the script in a 32-bit console on a test machine before blaming the service.
7. Check the device clock.
8. Read IntuneManagementExtension.log for arrival, then AgentExecutor.log for the exit code and the output length.

If the script is running but something else is undoing its work, that is a separate question: which setting actually wins when two policies collide.

What I would do differently

Reading Microsoft’s limits against the threads that rank for Intune PowerShell script not running, I would stop treating platform scripts as a general automation surface. Run once, three retries, then silence, is a deployment mechanism rather than a configuration mechanism. Anything that has to stay true over time belongs in a remediation, which runs on a schedule and reports a detection result, or in a configuration profile.

I would write every script to be idempotent and to exit non-zero when it has not achieved what it set out to do, because the exit code is all the service reads. A script that swallows its own errors will report Succeeded on every device and change nothing on any of them, which is precisely the state the ranking threads describe.

And I would set the host explicitly on every new script rather than accept the default, because that default is the one setting here that fails silently, consistently, and without appearing anywhere in the admin centre.

I have not run platform scripts in production. My tenant is a lab with no enrolled devices, so everything above is what Microsoft documents, what admins report in its own forum, and where I would expect it to bite. Where the documentation contradicts itself, on whether device-assigned scripts re-run at sign-in, I have quoted both sentences rather than pick one.

Primary sources, verified on the date below: Use PowerShell scripts on Windows devices in Intune, Troubleshoot Win32 app issues, and the Microsoft Q&A thread How to fix Intune platform scripts not running on fresh Windows 11 devices.

Last verified: 15 October 2026. I have not run this in production; my tenant is a lab with no enrolled devices, so everything above is what the documentation states, what practitioners report, and where I would expect it to bite.