How to Deploy PowerShell Scripts in Microsoft Intune

What Is PowerShell Script Deployment in Intune?

Microsoft Intune includes a management extension that can execute PowerShell scripts on enrolled Windows 10 and Windows 11 devices. It is the modern equivalent of a startup or logon script in a traditional domain environment, where the same job would typically be handled by a Group Policy Object.

Configuration profiles and settings catalog policies should always be your first choice, because they are declarative, reportable, and self-healing. Scripts fill the gap for everything those policies cannot express: registry tweaks with no CSP, one-time cleanup tasks, custom logging, legacy application fixes, or vendor-specific configuration steps.

How the Intune Management Extension Works

The Intune Management Extension (IME) agent is installed automatically on a device the first time a PowerShell script or a Win32 app is assigned to it. The agent downloads the script, runs it, and reports the result back to Intune.

• Scripts are assigned to user or device groups, not to individual devices.
• By default, a script runs once per device and does not run again unless it is modified.
• Scripts can run in the system context or in the signed-in user's context.
• The agent checks for new or changed scripts roughly every hour, and after each reboot.
• Execution results are written to the device's IME log and surfaced in the Intune portal.

Requirements Before You Start

• Windows 10 version 1607 or later, or Windows 11.
• Devices enrolled in Intune (Entra joined, hybrid joined, or co-managed).
• For co-managed devices, the Client apps workload moved to Intune.
• An account with the Intune Administrator or Policy and Profile Manager role.
• A tested .ps1 file, saved as UTF-8 and under 200 KB.

Step 1 — Prepare and Test the Script

• Write the script so it can run unattended, with no prompts and no interactive input.
• Make the script idempotent, so a repeated run causes no damage.
• Add explicit exit codes: exit 0 for success, a non-zero value for failure.
• Write output to a log file under C:\ProgramData or the Windows event log.
• Test the script locally in the same context it will run in on the device.

Step 2 — Add the Script to Intune

• Sign in to the Microsoft Intune admin center.
• Go to Devices → Scripts and remediations → Platform scripts.
• Select Add and choose Windows 10 and later.
• Enter a descriptive name and a description that states what the script changes.
• Upload the .ps1 file.

Step 3 — Configure the Script Settings

• Choose whether to run the script using the logged-on credentials.
• Choose whether to enforce a script signature check.
• Choose whether to run the script in a 64-bit PowerShell host.

Step 4 — Assign the Script

• Assign the script to a device group for system-context tasks.
• Assign the script to a user group for per-user tasks.
• Add exclusion groups for pilot rings, servers, or sensitive devices.
• Review the assignment and select Add to publish.

Step 5 — Monitor Execution

• Open the script and review the device status and user status reports.
• Export the per-device results to identify failed executions.
• On a failing device, inspect C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log.
• Re-run a script by making a change to the file and re-uploading it.

Platform Scripts vs. Remediations vs. Win32 Apps

• Platform scripts — run once, best for one-time configuration.
• Remediations — a detection script plus a fix script on a recurring schedule, best for drift correction and continuous compliance.
• Win32 apps — packaged installers with detection rules, requirements, and dependency handling.

Security Considerations

A script that runs in the system context runs as SYSTEM on every assigned device. Treat script deployment as a privileged operation and control it accordingly.

• Never place plaintext passwords, tokens, or connection strings in a script.
• Restrict who holds the Intune roles that can create and assign scripts.
• Sign your scripts and enable the signature check where possible.
• Keep scripts in source control and review every change before upload.
• Roll out to a pilot ring before the whole fleet.
• Constrain what scripts can run on endpoints with application control (AppLocker or WDAC).
• Keep script-based attacks blocked with Defender Attack Surface Reduction rules.

Common Reasons a Script Fails

• The script expects user input or displays a dialog.
• The script assumes a mapped drive or a user profile that does not exist in system context.
• The 32-bit host is used when 64-bit registry paths are required.
• The script exits with a non-zero code even though it succeeded.
• The device has not checked in since the assignment was created.

Where This Fits in Your Hardening Program

Scripts are a tool, not a baseline. Use them to close gaps, and use policy for everything else. If you are still moving from on-premises management to Intune, it helps to understand how the old model worked first — see What Is ADMX? and What Is Group Policy Object (GPO)? — and then work through the Endpoint Security checklist, including Windows LAPS, which can be deployed through Intune as well.