
Microsoft MVP (Enterprise Mobility, Security) - MCT
Dean Ellerby [MVP] published a concise YouTube walkthrough that highlights a small but meaningful change in Microsoft Intune: you can now deploy Win32 apps using a separate PowerShell script uploaded directly in the Intune console. This change means administrators no longer must bundle their installer script inside the IntuneWin package and rewrap the entire payload each time a script tweak is needed. Instead, Intune stores the script as part of the app configuration and executes it via the Intune Management Extension during installation. Consequently, routine script updates become faster and less error-prone.
Previously, any change to an install script required repackaging the entire Win32 payload, which cost time and created friction in testing and iteration. Now, administrators can upload or edit a PowerShell script in the app creation flow and keep static content untouched, allowing fast script-only updates without rebuilding the IntuneWin file. This separation reduces packaging overhead and simplifies complex deployments that rely on conditional logic or frequent updates. Moreover, the workflow preserves the existing detection, assignment, and reporting mechanisms administrators already rely on in the console.
When you add a Windows app (Win32) in Intune, the new option lets you select a PowerShell script as the installer in the Program section, while still uploading the .intunewin content as usual. The Intune Management Extension downloads the package, extracts metadata, writes the script to disk, and runs it under the chosen context (system or user) with standard execution handling and return-code-based reporting. Detection rules, uninstall commands, assignments, and timeout behaviors remain part of the app configuration so existing deployment controls continue to apply. Administrators will notice that the script becomes visible and editable in the portal, removing the need to touch the binary payload for script changes.
In his video, Ellerby demonstrates installing Chrome while applying a registry customization via an uploaded script, which shows the feature’s practical value for real deployments. To replicate that approach, you upload the .intunewin file, choose the PowerShell installer option, and then add a silent script that performs prerequisite checks, executes the installer, and writes detection keys or values. The portal enforces script size and execution constraints, so keep scripts concise, avoid interactive prompts, and exit with standard return codes to indicate success or failure. This pattern supports advanced flows like prechecks, conditional branch logic, and post-install validation without repackaging the full application every time.
Although this feature reduces repackaging work, it introduces new tradeoffs that teams must manage. For example, there are script size limits and execution timeouts that can constrain very large installers or long-running sequences, so teams may still need to bundle heavy payloads in the .intunewin and use the script only for orchestration. Additionally, separating scripts from payloads means tighter governance is required: scripts are easier to change, which can speed mistakes to production unless change-control and testing are enforced. Security reviewers will want to validate scripts and, when Multi-Admin Approval is enabled, ensure scripts are added or updated in line with approval policies.
Administrators should treat the uploaded script as a controlled artifact and adopt source control, testing, and staged rollout processes to limit risk. For reliability, include clear detection rules that match the installed state and build retry logic or idempotent behavior into scripts so repeated runs are safe. Where heavy installers are needed, continue packaging content into the IntuneWin file and use the script primarily for orchestration, configuration, or validation. Finally, monitor installation telemetry and test across contexts (system vs. user) and device states to uncover edge cases early.
Dean Ellerby’s video frames the update as a small UI change with an outsized impact on daily packaging work, which is accurate: removing the need to rewrap every script tweak streamlines maintenance and speeds iteration. However, teams should balance agility with governance, watch for script limits and timeouts, and keep robust testing and detection in place to avoid operational regressions. Overall, the enhancement tightens the gap between packaging and scripting, and it offers a practical way to reduce friction in complex Win32 deployments while retaining familiar Intune controls.
New Intune feature, Deploy app with PowerShell, Intune PowerShell deployment, Microsoft Intune PowerShell, Intune app deployment script, Win32 app Intune PowerShell, Automate Intune app deployment, Intune management PowerShell