PowerShell is one of the most useful tools available to Windows administrators. Combine it with Microsoft Intune and you can execute administrative tasks across managed Windows devices without manually connecting to each computer.

This is particularly useful in cloud-managed environments where employees may be working remotely and devices are no longer continuously connected to a traditional corporate network.

PowerShell scripts can be used for tasks such as:

Changing Windows configuration
Creating registry values
Removing unwanted software
Configuring applications
Collecting troubleshooting information
Creating files and folders
Detecting configuration problems
Automating repetitive administrative tasks

In this guide, we’ll look at the basic process for deploying a PowerShell script through Intune.

Step 1: Create Your PowerShell Script

First, create and test the PowerShell script locally.

For example, let’s create a simple registry value:

$Path = "HKLM:\SOFTWARE\Company"

if (!(Test-Path $Path)) {
    New-Item -Path $Path -Force
}

New-ItemProperty `
    -Path $Path `
    -Name "ManagedByIntune" `
    -Value "True" `
    -PropertyType String `
    -Force

This script creates:

HKLM\SOFTWARE\Company

and then creates a value named:

ManagedByIntune

Before deploying any PowerShell script through Intune, test it on a test device. Never assume that a script that works interactively will behave exactly the same way when Intune executes it.

Step 2: Add the Script to Intune

Sign in to the Microsoft Intune admin center.

Navigate to the Windows scripting area and create a new PowerShell script deployment.

Upload your .ps1 file.

Give the script a descriptive name, for example:

Windows – Set Company Registry Configuration

Adding a useful description is also important, particularly in environments where several administrators manage Intune.

For example: Creates the corporate registry configuration required on managed Windows endpoints.

Step 3: Configure Script Execution

Intune provides several settings controlling how a PowerShell script executes.

One important decision is whether the script should run using the logged-on user’s credentials.

If your script modifies user-specific settings, running in the user’s context may be appropriate.

For system-wide modifications, such as writing to protected areas under HKLM, administrative context is generally required.

You should also pay attention to the PowerShell architecture used to execute the script.

A script touching applications or registry locations affected by 32-bit versus 64-bit redirection needs to be tested accordingly.

Step 4: Assign the Script

Next, configure assignments.

You can assign the deployment to appropriate user or device groups.

For production environments, I recommend using a controlled deployment strategy.

For example:

Stage 1: IT testing devices
Stage 2: Pilot users
Stage 3: Small production group
Stage 4: Wider production deployment

Avoid deploying newly written administrative scripts to every device immediately.

A successful exit code doesn’t necessarily mean the resulting Windows configuration is exactly what you intended.

Step 5: Monitor the Deployment

After deployment, use Intune reporting to monitor execution.

Look for:

• Successful executions
• Failed executions
• Devices that haven’t received the deployment
• Unexpected behavior on pilot devices

If a script reports an error, don’t immediately assume that Intune itself is broken.

The problem could come from:

• PowerShell syntax
• Permissions
• Execution context
• 32-bit versus 64-bit behavior
• Missing dependencies
• Network connectivity
• The script’s assumptions about the endpoint

Troubleshooting Intune PowerShell Scripts

For Windows endpoint troubleshooting, the Intune Management Extension is particularly important.

IME logs can provide information about script and application processing on the endpoint.

When troubleshooting a failed deployment, I normally think of the problem in layers:

1. Did the device receive the assignment?

Confirm that the device or user is actually targeted.

2. Did Intune attempt to execute it?

Check the deployment status and endpoint logs.

3. Did PowerShell execute successfully?

Test the script manually using the relevant execution context where practical.

4. Did the script produce the expected result?

This is different from simply asking whether the script ran.

For example, if your script creates a registry value, verify that the value actually exists.

Add Logging to Your Scripts

For more complicated scripts, logging can save significant troubleshooting time.

For example:

$Log = "C:\ProgramData\Company\Logs\IntuneScript.log"

$Folder = Split-Path $Log

if (!(Test-Path $Folder)) {
    New-Item -ItemType Directory -Path $Folder -Force
}

"Script started: $(Get-Date)" | Out-File $Log -Append

try {

    # Your configuration here

    "Configuration completed successfully." |
        Out-File $Log -Append

    exit 0

}
catch {

    "ERROR: $($_.Exception.Message)" |
        Out-File $Log -Append

    exit 1
}

This gives you another source of information when troubleshooting.

Final Thoughts

PowerShell and Microsoft Intune work extremely well together.

PowerShell gives administrators flexibility, while Intune provides centralized cloud-based deployment and management.

However, scripts should be treated like production code.

Test them, document them, use clear exit codes, implement logging where appropriate, and roll them out gradually.

A five-line PowerShell script can change thousands of computers when deployed through Intune.

That is powerful, but it also means testing matters.