A community where customers and the community can provide feedback to make a better product for everyone! For more details on how we prioritize requests, please see:
Configure the allowed maximum runtime of a Win32 application
Sadjied Idoe
Oct 6, 2026
We have now run into this exact limitation with a real-world Patch My PC Cloud Custom App.
We are deploying Adobe Photoshop 27.10 from an Adobe Admin Console package using:
setup.exe --silent
PatchMyPC-ScriptRunner starts the installer correctly under SYSTEM, but terminates the EXE after exactly 30 minutes. We have reproduced this on multiple installation attempts:
Attempt 1
10:11:07 – EXE started
10:41:07 – Aborted due to timeout.
Attempt 2
11:18:48 – EXE started
11:48:48 – Aborted due to timeout.
The Intune Win32 application itself has Installation time required configured to 60 minutes, so the ScriptRunner timeout effectively overrides the longer runtime allowed by Intune.
Adobe's installation logs confirm that the installer was still actively processing the package when ScriptRunner timed out. After the timeout, the continuing Adobe process subsequently lost access to package content in the IMECache and the Adobe installation eventually failed with exit code 127.
This is particularly problematic for large enterprise installers such as Adobe Photoshop, where installation legitimately can take longer than 30 minutes.
It would be very helpful if the ScriptRunner maximum runtime could either:
respect Intune's configured installation time, or
expose a configurable timeout per Custom App.
A configurable value of 60/90/120 minutes would make these large Custom Apps much more practical without requiring packaging workarounds.
Currently, Script Runner appears to enforce a hidden 30-minute timeout. This creates a constraint for custom application deployments, especially during OOBE when larger Windows image customisations are required.
Given that the win32 applications 60-minute deployment time is not being honoured, this should be better treated as a product improvement to align with expected behaviour, rather than a feature request.
We have now run into this exact limitation with a real-world Patch My PC Cloud Custom App.
We are deploying Adobe Photoshop 27.10 from an Adobe Admin Console package using:
setup.exe --silentPatchMyPC-ScriptRunner starts the installer correctly under SYSTEM, but terminates the EXE after exactly 30 minutes. We have reproduced this on multiple installation attempts:
Attempt 1
10:11:07 – EXE started
10:41:07 –
Aborted due to timeout.Attempt 2
11:18:48 – EXE started
11:48:48 –
Aborted due to timeout.The Intune Win32 application itself has
Installation time requiredconfigured to 60 minutes, so the ScriptRunner timeout effectively overrides the longer runtime allowed by Intune.Adobe's installation logs confirm that the installer was still actively processing the package when ScriptRunner timed out. After the timeout, the continuing Adobe process subsequently lost access to package content in the IMECache and the Adobe installation eventually failed with exit code 127.
This is particularly problematic for large enterprise installers such as Adobe Photoshop, where installation legitimately can take longer than 30 minutes.
It would be very helpful if the ScriptRunner maximum runtime could either:
respect Intune's configured installation time, or
expose a configurable timeout per Custom App.
A configurable value of 60/90/120 minutes would make these large Custom Apps much more practical without requiring packaging workarounds.
Currently, Script Runner appears to enforce a hidden 30-minute timeout. This creates a constraint for custom application deployments, especially during OOBE when larger Windows image customisations are required.
Given that the win32 applications 60-minute deployment time is not being honoured, this should be better treated as a product improvement to align with expected behaviour, rather than a feature request.