Deploying and tuning Sysmon at scale

The audit policy and Sysmon baseline explains what Sysmon records and why you want it. Installing it on one machine takes a minute. Running it on thousands of machines, with a configuration that finds attacks without burying your SIEM, is a different job. This guide covers that job: choosing a configuration, tuning it with data, deploying and updating it at scale, and making sure you notice when it stops working.

Before you start: standalone or built-in

Sysmon is now also built into Windows 11 and Windows Server 2025 as an optional feature, off by default. On Windows 11 24H2 and 25H2 it arrived with the February 24, 2026 preview update (KB5077241) and the cumulative updates after it. You enable it with Enable-WindowsOptionalFeature -Online -FeatureName Sysmon (or Dism /Online /Enable-Feature /FeatureName:Sysmon), then run sysmon -i with your configuration. It uses the same XML configuration format and logs to the same Sysmon Operational channel, and Windows Update services its binaries. Three practical points:

• Standalone Sysmon and the built-in feature can't run on the same host. Uninstall the Sysinternals version before you enable the built-in one.
• The built-in version localizes the rendered event message. Parse the event XML fields, not the message text, or your pipeline breaks on non-English systems.
• Everything below about configuration, tuning and monitoring applies to both.

Step 1: choose a configuration strategy

Most teams fork sysmon-modular or SwiftOnSecurity into their own repository, keep upstream as a remote, and apply local changes as a thin layer on top. If Defender for Endpoint is deployed, sysmon-modular's variant designed to complement MDE avoids collecting what MDE already records well. See EDR block mode and passive mode for how MDE fits alongside other tools.

Keep one base configuration and add per-role overlays: workstations, member servers, domain controllers and internet-facing servers have different normal behaviour. A domain controller should never spawn a browser; a developer laptop spawns compilers all day.

Examples of what the overlays typically change:

• Workstations: keep process creation, network and DNS events broad; exclude browser and collaboration app noise precisely.
• Domain controllers: include process access to lsass.exe in detail, keep network events for unusual processes, and exclude the heavy but expected LDAP and replication traffic from system processes.
• Web and application servers: log every child process of the web server or database service, since those almost never spawn shells legitimately.
• Jump servers and PAWs: more verbose than anywhere else, because their activity is admin activity by definition and worth reviewing.

Check that the schemaversion in the file matches what your binary supports:

Sysmon64.exe -s | Select-Object -First 5   # prints the schema supported by this binary

Step 2: understand the rule engine before tuning

Tuning mistakes usually come from misreading how Sysmon evaluates rules:

• Each event type has an onmatch="include" or onmatch="exclude" filter. An event type with an empty include filter logs nothing; one with an empty exclude filter logs everything.
• Inside a RuleGroup, groupRelation="or" means any condition matches; groupRelation="and" means all must match. Use and groups to make exclusions precise.
• Name your rules. The name attribute appears as RuleName in the event, which is how analysts see why something was logged (for example a technique ID).

A precise exclusion looks like this:

<RuleGroup name="Exclude agent update checks" groupRelation="and">
  <NetworkConnect onmatch="exclude">
    <Image condition="is">C:\Program Files\Contoso Agent\agent.exe</Image>
    <DestinationPort condition="is">443</DestinationPort>
  </NetworkConnect>
</RuleGroup>

And a targeted include for credential theft:

<RuleGroup name="" groupRelation="or">
  <ProcessAccess onmatch="include">
    <TargetImage name="technique_id=T1003.001,technique_name=LSASS Memory" condition="is">C:\Windows\system32\lsass.exe</TargetImage>
  </ProcessAccess>
</RuleGroup>

Pair that LSASS rule with LSA protection and Credential Guard: the configuration tells you someone tried, the protection makes the attempt fail.

Step 3: measure, then cut noise

Pilot on 20 to 50 machines per role for a week, with the Sysmon log raised well above its small default:

wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:1073741824   # 1 GB

Then find where the volume comes from:

$ev = Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -MaxEvents 50000

# Volume per event ID
$ev | Group-Object Id | Sort-Object Count -Descending | Select-Object Count, Name

# Top processes for network connections (event 3)
$ev | Where-Object Id -eq 3 | ForEach-Object {
  ([xml]$_.ToXml()).Event.EventData.Data | Where-Object Name -eq 'Image' | ForEach-Object '#text'
} | Group-Object | Sort-Object Count -Descending | Select-Object -First 15 Count, Name

Do the same in your SIEM across the whole pilot. The usual top offenders are event 3 (network), 7 (image load), 10 (process access), 11 (file create), 12/13 (registry) and 22 (DNS), driven by browsers, security agents, backup software and updaters.

Rules for cutting noise safely:

1. Exclude by full path, never by name. Image end with chrome.exe excludes any file an attacker names chrome.exe. Image is C:\Program Files\Google\Chrome\Application\chrome.exe does not.
2. Never exclude user-writable locations such as C:\Users\, C:\ProgramData\ or %TEMP%. That's where attackers stage tools.
3. Combine fields. Exclude a process and a destination port, or a source and a target image for process access, not just the process.
4. Prefer signatures for image loads. Event 7 carries Signed and Signature; excluding Microsoft-signed DLLs from Microsoft-signed processes cuts most of the volume.
5. Keep security value first. Before removing an event type, write down which detection depends on it. Sysmon 1, 3, 10, 11, 13 and 22 feed most detection content.
6. Watch file deletion. FileDelete (event 23) with an archive directory copies every deleted file and can fill disks. FileDeleteDetected (event 26) logs without archiving and is usually enough.

Step 4: deploy and update at scale

Sysmon installs a driver and a service, and copies itself to %windir%. Deploy it through the tool you already trust for software: Configuration Manager, an Intune Win32 app, or a GPO-launched scheduled task. The logic is the same: install if missing, upgrade if the binary changed, reload the configuration if the file changed.

$pkg    = 'C:\ProgramData\CorpSysmon'
$binary = Join-Path $pkg 'Sysmon64.exe'
$config = Join-Path $pkg 'sysmonconfig.xml'
$marker = Join-Path $pkg 'applied.sha256'

if (-not (Get-Service -Name Sysmon64 -ErrorAction SilentlyContinue)) {
    & $binary -accepteula -i $config
} elseif ((Get-Item "$env:windir\Sysmon64.exe").VersionInfo.FileVersion -ne
          (Get-Item $binary).VersionInfo.FileVersion) {
    & "$env:windir\Sysmon64.exe" -u force
    & $binary -accepteula -i $config
}

$hash = (Get-FileHash $config).Hash
if (-not (Test-Path $marker) -or (Get-Content $marker) -ne $hash) {
    & $binary -c $config
    Set-Content -Path $marker -Value $hash
}

Configuration changes with -c apply without a reboot or a gap. Binary upgrades by uninstall and reinstall leave a short monitoring gap; check the release notes of each version for the supported upgrade path, and schedule upgrades rather than letting them happen at random.

Release process:

• Configuration in source control, reviewed like firewall rules.
• Validate the XML on a test machine with -c before release; a broken file is rejected and the old configuration stays active, which can hide the fact that your change never landed.
• Ring the rollout: pilot, then 10 %, then everyone, watching event volume at each step.
• Avoid putting the configuration on a share every user can read. It tells attackers exactly what you don't log.

The -d switch installs the driver under a different name and renaming the executable changes the service name. That hides Sysmon from the laziest scripts only; it is not a control, and it complicates your own health checks.

What breaks

• SIEM ingestion costs jump if the first configuration is too verbose. Pilot before fleet rollout, always.
• Performance issues are rare but real with broad image-load or registry includes on busy servers such as Exchange, SQL or file servers.
• Coexistence: some security products monitor the same kernel callbacks. Test with your EDR and backup agents.
• Stale configurations: hosts that missed an update keep running old rules silently unless you check.

Step 5: monitor Sysmon itself

A Sysmon that stopped two weeks ago looks exactly like a quiet host. Detect:

• Sysmon event 4 (service state changed), 16 (configuration changed) and 255 (error).
• Service stops in the System log from the Service Control Manager.
• Hosts with no Sysmon events in the last few hours, while they still send other logs.
• Configuration drift: add the configuration hash to your inventory and compare across the fleet.

Verify it

On a test host, check the running configuration and trigger known events:

Sysmon64.exe -c                                   # shows the active configuration and hash
Resolve-DnsName example.com                       # expect event 22
Test-NetConnection example.com -Port 443          # expect event 3 if not excluded

Confirm those events arrive in the SIEM with the right RuleName, delivered through Windows Event Forwarding or your agent. Then run the same test through your detection content, for example the unmanaged PowerShell rule from detecting malicious PowerShell. For the event IDs Windows logs without Sysmon, see the security event ID reference; more on Sysmon and logging on the audit and logging topic page.

Checklist

• Standalone versus built-in Sysmon decided per OS build
• Configuration forked from a maintained project, in source control, with per-role overlays
• Pilot measured per event ID and per process before fleet rollout
• Exclusions use full paths and combined fields; no user-writable folders
• Sysmon log sized for local buffering; events forwarded
• Automated install, upgrade and configuration reload with ringed rollout
• Sysmon health (4, 16, 255, service stops, silent hosts, config hash) monitored
• Tuning reviewed quarterly against detection content