Scripts and remediations¶

When no setting exists for what you need, scripts fill the gap. Intune has three ways to run code on devices, each suited to a different job.

Find platform scripts and remediations under Devices > Manage devices > Scripts and remediations.

Windows platform scripts¶

• Delivered and run by the Intune Management Extension (IME), which installs automatically when you assign a script, Win32 app or remediation.
• Run as SYSTEM by default, or as the signed-in user if you select Run this script using the logged on credentials.
• Choose 64-bit PowerShell unless the script needs the 32-bit host. The default runs in a 32-bit process, which sees the 32-bit registry view and SysWOW64, a classic source of "works on my machine".
• A script runs once. Intune only reruns it if you change the script content. Failed scripts are retried a limited number of times.
• You see success or failure in the portal, but not the output. Write your own log file if you need detail.

macOS shell scripts¶

• Need the Intune management agent, which installs automatically.
• Run as root or as the signed-in user.
• Can run once or repeat (every 15 minutes up to weekly), with a maximum number of retries if they fail.
• Logs are in /Library/Logs/Microsoft/Intune/ on the Mac.

Remediations¶

Remediations (formerly Proactive remediations) pair a detection script with an optional remediation script, run them on a schedule, and report results, including script output. They're the most useful automation tool in Intune for Windows.

Requirements¶

• Devices are Entra joined or hybrid joined, and enrolled in Intune or co-managed. Enterprise, Pro and Education editions are supported.
• Users need Windows Enterprise E3 or E5, Windows Education A3 or A5, or Windows VDA per user. These are included in Microsoft 365 E3, E5, F3, A3 and A5.
• An Intune Administrator must confirm the licensing requirement the first time Remediations is used.

How the scripts must behave¶

Schedule and reporting¶

• The client fetches Remediations policy after a restart, after a user signs in, and every 8 hours.
• Schedules can be once, hourly or daily. Prefer daily (or less often) for anything heavy: every script costs CPU and battery.
• Recurring scripts report only when the result changes, plus a full report every 7 days.
• You can run a remediation on demand on a single device from the device page (... > Run remediation), which is handy for service desk fixes. The device must be online.

Example: keep feature updates flowing¶

Windows feature updates silently stop when the Microsoft Account Sign-In Assistant service (wlidsvc) is disabled, which some hardening scripts do. This pair detects and fixes it.

# Exit 1 = issue found (remediation runs). Exit 0 = healthy.
$service = Get-Service -Name 'wlidsvc' -ErrorAction SilentlyContinue

if ($null -eq $service) {
    Write-Output 'wlidsvc not present'
    exit 0
}

if ($service.StartType -eq 'Disabled') {
    Write-Output 'wlidsvc is disabled'
    exit 1
}

Write-Output "wlidsvc start type is $($service.StartType)"
exit 0

try {
    Set-Service -Name 'wlidsvc' -StartupType Manual -ErrorAction Stop
    Write-Output 'wlidsvc set to Manual'
    exit 0
}
catch {
    Write-Output "Failed to change wlidsvc: $($_.Exception.Message)"
    exit 1
}

Settings for this package: run as SYSTEM, 64-bit PowerShell, daily schedule.

Good script hygiene¶

• Idempotent: running it twice must be safe.
• Silent: no prompts or windows. Scripts run where no one can answer.
• Fast: long-running scripts block other IME work. Move heavy jobs into a Win32 app.
• No secrets: scripts are stored in plain text in Intune and cached on devices. Never embed passwords, keys or tokens.
• Logged: write to a log under C:\ProgramData\<YourOrg>\Logs\ so the service desk can see what happened.
• Signed where you can, and enforce signature checks for sensitive scripts.
• Protected: put Windows scripts behind Multi Admin Approval. A malicious script assigned to all devices runs as SYSTEM everywhere.

For ready-made, reviewed scripts, the community IntuneAutomation library is a good starting point. Read and test any script before you deploy it.

Where to look when a script misbehaves¶

Learn more¶

• Remediations
• Use PowerShell scripts on Windows devices
• Remediation script samples