Are your PowerShell scripts not executing on newly enrolled Intune devices? You are probably not the only one. The root cause may be a bit funny. When the Intune Management Extension (SideCar) sends its initial policy request, the payload can exceed the maxJsonLength limit used by JavaScriptSerializer. When that happens, the PowerShell scripts will never come down to your device…
PowerShell Scripts not executing
It started with a tag on Reddit. Not long after, I was contacted by multiple different companies experiencing the same thing. IT Admins were running into the same issue: brand new Intune-enrolled devices where the PowerShell platform scripts simply didn’t run. The Win32 apps installed fine. Detection scripts were executed successfully. Even proactive remediations seem to work. But the PowerShell scripts (Platform scripts)? Nothing.
The Intune portal showed no execution history, no success or errors, just alot of nothing. It was as if the PowerShell scripts were never getting deployed at all. Was it an assignment issue or something else? Well, I was bound to find out.
The Issue
Our tests confirmed it. Existing devices had no problem processing existing PowerShell scripts. But new devices, especially freshly enrolled ones, weren’t running any PowerShell scripts delivered via the Intune Management Extension. The Intune Management Extension (IME) would install as usual, Win32 apps and their detection scripts executed successfully, and remediation scripts (triggered via get-scripts) also worked. But PowerShell platform scripts were completely skipped… which felt weird.
The IME Logs: MaxJsonLength
Initially, we dove into the usual Intune Management Extension log we need to use when we are troubleshooting PowerShell issues: the AgentExecutor log. Well…. that log contained nothing usefull! No evidence of PowerShell script execution at all. But the IntuneManagementExtension.log had something more useful. Just after successfully sending a web request to the SideCar gateway, a new line appeared just before it went silent:
[PowerShell] Exception occurs when processing user session… Error during serialization or deserialization using the JSON JavaScriptSerializer. The Length of the string exceeds the value set on the MaxJsonLength Property.
The error clearly referenced the maxJsonLength property, which was our first real clue. MaxJsonLength told us that the JSON string had reached its maximum length, which literally broke the Intune Management Extension PowerShell script’s execution. I decided to dig deeper.
Capturing IME traffic with Fiddler
At first, we thought we could intercept the SideCar policy request using Fiddler. We installed Fiddler and enabled HTTPS decryption (check out our webinar to find out how to set it up!). But the moment we hit the SideCar endpoint (manage.microsoft.com), the IME gateway rejected us with a 401 Forbidden/Unauthorized.
The WebRequest call broke because it expected a trusted certificate that corrosponds with agents.amsub0302.manage.microsoft.com request. Of course this could solved pretty easily…How? Well, check out the video series called Patch and Rant that will discuss this in more detail and how to fix it. As shown below it’s pretty easy to capture the IME traffic but I wanted to find out more.
The PowerShell Script Plugin IME Flow
After capturing the IME traffic with Fiddler, we moved on. This time, we started looking at the IME decompiled code. After decompiling the IME ScriptPlugIn.dll with the dotpeek tool, we focused on the PowerShellScriptPlugIn logic.
Here’s how the full PowerShell Script Plugin flow works:
- The IME starts its polling cycle
- It fetches the current AAD session IDs and prepares to check in
- It uses the device’s MDM certificate (retrieved via GetMDMCertWithRetry) and attaches it to the request
- A SideCar Gateway Session object is built
- The request uses the content type PolicyRequest (at first, I thought it would use the GetScript content type…. but I guess I was totally wrong)
- The IME serializes (converts) the policy result data using the JavaScriptSerializer
- The serialized string is included as the request payload
- The request is sent via a PUT to the SideCar gateway endpoint: /SideCarGatewayService/SideCarGatewaySessions
At this point, if the serialized JSON payload exceeds the configured maxJsonLength on the IME service side, deserialization fails. The server returns nothing. The IME logs an exception, and no PowerShell scripts are delivered.
Rebuilding the PowerShell Policy Request in PowerShell
We wanted to validate this behavior ourselves, so we built a PowerShell script that mimicked the IME behavior. Yes, we built a PowerShell script to communicate with the IME service and fetch the policy ourselves!
By using Fiddler previously, we first captured a working session and copied over the session ID, request key, and bearer token. (The AccountId/DeviceID were already mentioned in the IME log)
With the PowerShell script finished, it was ready for a testdrive to find out if we could run into the same MaxJsonLength error.
Reproducing the MaxJsonLength error
From there, the custom PowerShell script executed a manual PUT request to the SideCar endpoint, using the same headers and including the same payload structure to start the policy request (PowerShell scripts). At first, we skipped the JavaScriptSerializer. And it worked!! (after spending some time on it to get it working)
The response came back successfully with the full set of assigned PowerShell policies, around 3.7 MB. The JSON file itself was even bigger (7 MB). That indeed contained all the base64-encrypted PowerShell scripts that we configured.
Then we rebuilt the script to serialize the payload exactly the way the IME does using JavaScriptSerializer. That’s when the response gave the exact same error as we noticed in the Intune Management Extension log.
As shown earlier, we added a JSON size check to our PowerShell script to pinpoint the issue. Then, we started removing one PowerShell script from Intune, one by one… and waiting a cloud minute.
After each PowerShell/Platform script that we removed from Intune, we restarted the IME and re-ran our PowerShell script to check if the request succeeded.
Eventually (after removing like 5/6 scripts), when the total serialized payload dropped below the magical 2 MB threshold, the request succeeded. IME stopped throwing errors, and the PowerShell scripts showed up in the IME logs again.
This proved it. Once the Intune PolicyPayload size was under the limit of 2 MB, the IME completed the round trip and acknowledged the PowerShell script policies.
But the question still remains: Why is this happening suddenly, and why are people somehow experiencing this issue when nothing changed on their side?
What Changed?
After doing some research and looking at older traces, we got… we noticed something different in the PolicyRequest Payload. If I am not mistaken, in the past, we only had the PolicyBody (PowerShell scripts in plain text) coming down in the ResponsePayload when the IME needed to fetch the PowerShell script policies.
Nowadays (changed with the 2505 Intune Release?), we also have the encryptedpolicybody coming down in the JSON?
So I decided to create another PowerShell script that mimics the IME EncryptionHelper (Decrypt) function… (why not?)
Examining how that function retrieves the Intune MDM Device certificate to decode it made things a bit easier. I converted the IME Function to a PowerShell script to decode that information.
Guess what that Powershell script showed me when I executed it! Yes!! Exactly, the exact same PowerShell script we noticed in the PolicyBody itself, but this time encrypted.
It looks like Microsoft added the EncryptedPolicyBody to the PolicyRequest (PowerShell scripts IME Policy). With it, the whole JSON got at least two times bigger. With the JSON getting two times bigger… guess what happened? Exactly, the JSON exceeded 2MB, and with it, we got the error: The Length of the string exceeds the value set on the MaxJsonLength Property.
When we get this error, no PowerShell scripts will be deployed to our devices. So if you are stumbling into this issue, you know where to start looking!
8. Fixing the MaxJsonLength
We need Microsoft’s Intune service team to raise the allowed JSON payload size by setting maxJsonLength in their web config.
I expect Microsoft to eventually move away from the plaintext PolicyBody and only retain the EncryptedPolicyBody. Until then, if your PowerShell scripts aren’t running out of the sudden, start checking their combined payload size. You might be silently hitting the threshold wall.
Conclusion
If your PowerShell scripts aren’t running on newly enrolled Intune devices, you’re likely hitting the maxJsonLength limit. The recent addition of the encryptedPolicyBody doubled the payload size, pushing it past the 2MB threshold.
The Intune Management Extension fails silently, no scripts, no logs, just nothing.
Until Microsoft raises the limit, keep an eye on how much you’re pushing down