Midnight Coders

Tales from the Microsoft Cloud Trenches

The Curious Case of the Delayed PowerShell Script

Picture this: You’ve crafted a beautiful PowerShell script, deployed it with confidence through Microsoft Intune, and then… nothing happens. The device is online. The Intune Management Extension is humming along. But your script? It’s taking a coffee break. Possibly a long one.

The Mystery of the Missing Execution

Here’s a scenario that has puzzled many an Intune administrator: You create a PowerShell platform script to fix something that Intune can’t do natively. You assign it to a device group. The device shows as healthy. The IME service is running. You expect the script to execute almost immediately.

Six hours later? Still nothing.

Then someone logs out and logs back in, and poof — the script runs. Magic? Not quite. Let’s pull back the curtain.

What’s Actually Happening Behind the Scenes

The Intune Management Extension (IME) is not what you’d call a “live connection.” It doesn’t sit there constantly polling Intune like an eager puppy waiting for treats. Instead, it follows its own internal schedule — a cadence determined by hardcoded timers and session events.

When Microsoft says users don’t need to sign in, they’re not entirely wrong… but they’re not entirely right either. Device-scoped scripts can run in the system context, yes. But user context scripts? They need a user session. Without a session, there’s no user token to attach to. The IME is event-driven, not push-driven.

And here’s the kicker: WNS (Windows Push Notification Service) won’t wake up the IME for PowerShell policy check-ins. Push notifications are for specific workloads, but the PowerShell script engine has its own evaluation cycle. It waits for:

The Session Change Revelation

When we dug into the IME logs, the pattern became clear. The magic moment was when a user logged in. The IME detected a SessionChange — specifically SessionLogon — and suddenly it was very interested in checking for PowerShell scripts.

[PowerShell] Request PS Scripts for user logon.

That line is the turning point. The session logon triggers the IME to wake up and check what PowerShell scripts need to run. It’s not magic; it’s event-driven architecture having a scheduled awakening.

Why Pressing Sync Doesn’t Always Help

Ah, the famous Sync button. You press it in Intune. You press it on the device. You expect immediate action. But here’s the plot twist: Remote Sync only talks to the MDM stack (OMA-DM Client). The PowerShell platform script workload lives in the Intune Management Extension — a completely separate component.

It’s like pressing the accelerator in your car and expecting the radio to change stations. Different systems. Different traffic lanes.

The Eight-Hour Revelation

In the PowerShell plug-in code, there’s a line that sets the workload timer:

timerInterval = 28,800,000 MS (Eight hours)

This means if your script lands on the device between timer cycles, it’s going to wait. The IME doesn’t constantly poll. It sits. It waits. And then, when the time is right (or when a user logs in), it springs into action.

What This Means for You

When deploying new PowerShell scripts:

  1. Patience is a virtue — The script will run on the next 8-hour cycle
  2. Log in to trigger — Have a user log in to trigger an immediate check
  3. Restart the IME — If you’re impatient (and who isn’t?), restart the Intune Management Extension service
  4. Sync won’t help — Don’t rely on the Sync button for PowerShell script execution

The IME is event-driven, not push-driven. Understanding this fundamental architecture decision will save you countless hours of staring at the Intune portal, wondering why your script isn’t running.

Remember: The PowerShell script will execute. It just might need to wait for the right moment — like a theatrical actor who only performs when the audience (a user session) arrives.

Next time on “Tales from the Intune Trenches”: We explore why pressing Sync does actually work for some things but not others. Stay tuned!

Tags: