Deploying Sysmon with Intune: Win32 App and Remediations

I already wrote about what a sensible Sysmon configuration looks like; this post is about getting it onto several hundred machines without touching any of them. To deploy Sysmon with Intune you package the binary and the configuration as a Win32 app, give it a detection rule that survives version updates, and — the part most guides skip — set up a Remediation so the configuration does not silently drift for the next two years. The packaging is the quick half. Keeping the config current is the actual problem.

Key Takeaways

• The reliable way to deploy Sysmon with Intune is a Win32 app (.intunewin) containing the binary, the configuration XML, and a small install script — not a one-shot platform script.
• The detection rule should check for the Sysmon64 service or driver, because Intune re-evaluates it and will reinstall automatically if someone removes the agent.
• Sysmon stores a hash of its active configuration in the registry, which makes config drift detectable — an Intune Remediation can compare it and reapply the XML on a schedule.
• Sysmon writes to its own event channel, so the deployment is only useful once Microsoft-Windows-Sysmon/Operational is being forwarded or ingested somewhere central.
• Sysmon and Defender for Endpoint coexist without conflict; the point of Sysmon in an Intune-managed fleet is feeding a SIEM you control, not replacing EDR.

Environment

• Windows 11 23H2, Entra-joined and enrolled in Microsoft Intune.
• Sysmon 15.21 from the Sysinternals suite (Sysmon64.exe).
• A configuration XML based on sysmon-modular — the merged build, which you can trim further as described in my Sysmon configuration post.
• Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe) for packaging.
• Windows Enterprise E3 licensing for the Remediations feature in Step 4.

The Problem

On a domain with Group Policy, Sysmon deployment is a solved problem — a startup script or a GPO-deployed scheduled task and you are done. An Entra-joined, Intune-only fleet has neither, and the two obvious Intune mechanisms both have a catch. A platform PowerShell script runs once per user/device and does not re-run when you fix a bug in it, which is a poor fit for an agent that needs occasional binary and config updates. A Win32 app handles install, upgrade, and reinstallation properly — but its detection rule only answers "is Sysmon installed", not "is Sysmon running the config I published last month".

That second question is the one that bites. Sysmon behaves as whatever configuration it was last given. Ship version 1 of your XML in the app, improve the XML in month three, and every machine installed before that keeps filtering events with the old rules until reinstall — invisibly, because the service is up and the detection rule is green. So the design here is deliberately two-part: the Win32 app owns the binary, and a Remediation owns the configuration.

The Solution

Step 1 — Package Sysmon as a Win32 app for Intune

Create a source folder with three files: Sysmon64.exe (from the official Sysinternals download — do not redistribute from anywhere else), your sysmonconfig.xml, and an install wrapper:

# install.ps1 — runs as SYSTEM in the Intune agent context
$dir = Split-Path $MyInvocation.MyCommand.Path

# Copy the config somewhere stable so Remediations can reapply it later
New-Item -ItemType Directory -Path 'C:\ProgramData\Sysmon' -Force | Out-Null
Copy-Item "$dir\sysmonconfig.xml" 'C:\ProgramData\Sysmon\sysmonconfig.xml' -Force

& "$dir\Sysmon64.exe" -accepteula -i 'C:\ProgramData\Sysmon\sysmonconfig.xml'
exit $LASTEXITCODE

Then wrap the folder with the Content Prep Tool:

.\IntuneWinAppUtil.exe -c .\SysmonSource -s install.ps1 -o .\Output

The -accepteula flag matters — in the SYSTEM context there is no one to click the dialog, and without the flag the install hangs until Intune times it out. Copying the XML to C:\ProgramData\Sysmon is not decorative either; it is what makes Step 4 possible.

Step 2 — Install command, uninstall command, detection rule

In the Intune portal (Apps → Windows → Add → Windows app (Win32)), the app settings that matter:

• Install command: powershell.exe -ExecutionPolicy Bypass -File install.ps1
• Uninstall command: Sysmon64.exe -u force — the force keyword removes the driver even if the service is wedged.
• Install behavior: System.
• Detection rule: file exists — C:\Windows\Sysmon64.exe. Sysmon copies itself there during installation, so the check is stable across config changes and independent of your source folder.

Do not use a registry version check as the detection rule unless you enjoy repackaging the app for every Sysmon point release. The file-exists rule means an upgrade is a deliberate act (new app version supersedes the old) while day-to-day compliance stays green.

The Sysmon Win32 app in Intune: the install command, the Sysmon64.exe -u force uninstall, and Install behavior set to System — the packaging half of the deployment.

Step 3 — Assign and verify the Sysmon deployment

Assign the app as Required to a pilot device group first. On a pilot machine, confirm the service, the driver, and — most importantly — that events are flowing:

Get-Service Sysmon64, SysmonDrv | Select-Object Name, Status

Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -MaxEvents 5 |
    Select-Object TimeCreated, Id, LevelDisplayName

On my pilot device the first five entries were Event ID 1 (process creation) and Event ID 3 (network connection) within seconds of the service starting, which is the expected sign of life. A running service with an empty channel usually means the configuration XML failed to parse — Sysmon64 -c with no arguments prints the active config and will tell you if it is running on schema defaults.

Then plan where the events go. Locally logged Sysmon telemetry has near-zero detection value; forward the channel with Windows Event Forwarding or an agent into your SIEM. The event IDs worth prioritising are in the essential Windows Event IDs guide.

The sign of life to look for: a Sysmon Event ID 1 (ProcessCreate) in the Microsoft-Windows-Sysmon/Operational channel with hash, command line, and parent process populated.

Step 4 — Stop config drift with an Intune Remediation

Sysmon records the SHA256 of its running configuration in the registry under HKLM:\SYSTEM\CurrentControlSet\Services\SysmonDrv\Parameters (the ConfigHash value). That gives a Remediation something honest to compare. The detection script hashes the XML you staged in Step 1 and checks it against the running value:

# detect.ps1 — exit 1 triggers remediation
$xml = 'C:\ProgramData\Sysmon\sysmonconfig.xml'
if (-not (Test-Path $xml)) { exit 1 }

$expected = (Get-FileHash $xml -Algorithm SHA256).Hash
$running  = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\SysmonDrv\Parameters' -ErrorAction SilentlyContinue).ConfigHash

if ($running -and $running -match $expected) { exit 0 } else { exit 1 }

# remediate.ps1 — reapply the staged configuration
& 'C:\Windows\Sysmon64.exe' -c 'C:\ProgramData\Sysmon\sysmonconfig.xml'
exit $LASTEXITCODE

Publish both under Devices → Scripts and remediations, run daily as SYSTEM. Now updating the fleet's configuration is: push a new XML to the staging path (a small update to the Win32 app, or a separate script), and the next remediation cycle reapplies it everywhere the hash no longer matches. One caveat to note before you rely on it: the registry stores the hash with an algorithm prefix and formatting that has changed between Sysmon releases, so test the string comparison on your build before trusting the green checkmarks — that is exactly the kind of thing to verify on the pilot group rather than read in a blog post, including this one.

Remediations require Windows Enterprise licensing (E3/E5 or the education equivalents). If you do not have it, the fallback is bumping the Win32 app version with each config change — cruder, but it works with any Intune license.

The config-drift remediation in Intune: the detection and remediation scripts attached, running daily as SYSTEM — the half that keeps the configuration honest, not just the binary present.

Step 5 — Upgrading the Sysmon binary

For a new Sysmon release, update Sysmon64.exe in the source folder, repackage, and upload it as a new version of the same app — Intune reinstalls over the top, and Sysmon's installer handles the in-place upgrade of the service and driver. This is the same lifecycle as any other Win32 app in the tenant, which is the point of doing it this way instead of a script: the mechanisms you already use for security baselines and attack surface reduction rules cover the telemetry agent too.

Frequently Asked Questions

Can I deploy Sysmon with a plain Intune PowerShell script instead of a Win32 app?

It works for a one-time install, but platform scripts run once and are not re-evaluated, so there is no reinstall if the agent is removed and no sane path for updates. The Win32 app model gives you detection-based reinstall, versioned upgrades, and an uninstall command. For an agent you intend to keep for years, the packaging effort pays for itself quickly.

Do I need Sysmon if the fleet already runs Defender for Endpoint?

They solve different problems and coexist fine. Defender for Endpoint keeps its telemetry in Microsoft's pipeline; Sysmon writes to a local event channel that you can forward to any SIEM on your terms, with field-level control over what gets logged. If all your detection lives in Defender XDR, Sysmon adds little; if you run Sentinel, Splunk or Elastic, it adds the endpoint depth those platforms otherwise lack.

How do I update the Sysmon configuration on devices after deployment?

Running Sysmon64 -c newconfig.xml applies a new configuration without reinstalling the service. At fleet scale, that is what the Remediation in Step 4 automates: stage the new XML, let the hash comparison notice the mismatch, and the remediation script reapplies it on the next cycle.

How can I tell whether Sysmon is actually running my configuration?

Sysmon64 -c with no arguments prints the active configuration and its hash, and the same hash sits in the registry under SysmonDrv\Parameters. If the output shows schema defaults instead of your rules, the XML failed to load — usually a schema-version mismatch between the config and the binary.

Does uninstalling Sysmon require a reboot?

Normally no — Sysmon64 -u stops and removes the service and driver in place. The force variant handles the stuck cases. A reboot only becomes relevant when the driver cannot unload cleanly, which in my experience is rare on client Windows.

Conclusion

None of this is complicated once you know which Intune primitive owns which part of the lifecycle: Win32 app for the binary, detection rule for presence, Remediation for configuration truth. The guides that stop at "wrap it in an intunewin and assign it" leave out the part that determines whether the telemetry is still trustworthy a year later, and with Sysmon the configuration is the product.

The deployment itself is an afternoon including pilot testing. Budget the real time for the configuration content and for making sure the event channel actually lands in your SIEM — a perfectly deployed agent logging locally to 500 machines nobody reads is compliance theater with extra steps.

Related Posts

• Sysmon Configuration for Windows Security Monitoring — what to put in the XML this post deploys.
• Windows Event Forwarding Setup for Centralised Security Logs — getting the Sysmon channel off the endpoints.
• Deploying Attack Surface Reduction Rules with Intune — the prevention-side companion to this telemetry rollout.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.