Windows 11 Canary Build 28020.1611: Built-in Sysmon and OneDrive sharing polish

Microsoft has quietly folded a longtime defender's toolkit into the core of Windows 11: Sysmon (System Monitor) is now available as a built‑in, optional Windows feature in Insider Preview builds, and Build 28020.1611 (KB5077221) also brings a small but practical OneDrive sharing polish and a corrected desktop watermark for Insiders. This Canary‑channel flight signals a meaningful operational shift for security teams, while the OneDrive change tightens the integration between cloud storage and the Windows share workflow. ([blogs.windows.com]s.com/windows-insider/2026/02/12/announcing-windows-11-insider-preview-build-28020-1611-canary-channel/)

---

Background / Overview​

Windows Insider Preview Build 28020.1611 landed in the Canary Channel as a focused, experimental update that combines early platform work with a handful of customer‑visible tweaks. As with other Canary releases, this is a testbed for platform‑level changes that may be staged, gated, or removed as Microsoft evaluates telemetry and feedback. The build is identified as KB5077221 in the Insider post.
Two headline items matter for different audiences:

• Security operations and IT teams: Sysmon is now an in‑box optional feature rather than a standalone Sysinternals download. This lowers the deployment friction of advanced endpoint telemetry.
• Everyday users and cloud workers: Right‑click sharing for OneDrive cloud files surfaces a “Share using” option so the copied link can be dispatched directly through other apps, simplifying ad hoc workflows. This roll‑out is currently restricted to certain Insider accounts outside the EEA.

Below we unpack the technical details, operational implications, migration considerations, and the practical steps administrators should take before enabling inbox Sysmon across any fleet.

---

What Microsoft shipped: Built‑in Sysmon​

What Sysmon is and why it matters​

Sysmon (System Monitor) is a mature Sysinternals utility that runs as a kernel‑level service and a driver to produce rich system telemetry: process creation with command lines, process hashes, network connection events tied to processes, driver and image loads, file creation time changes, WMI activity, and more. That information is invaluable to SOCs, incident responders, and hunters because it allows effective correlation of events that standard Windows logs often miss. The built‑in capability preserves the same core functionality and event model Sysmon has historically offered.

How the in‑box Sysmon is delivered and enabled​

Microsoft documents the new in‑box delivery and enablement steps as follows:

• The feature is exposed as an Optional Feature in Settings: Settings > System > Optional features > More Windows features > Sysmon.
• It can also be enabled by automation using DISM:
  Dism /Online /Enable-Feature /FeatureName:Sysmon
• To complete the install and start logging, run the familiar Sysmon initialization command from an elevated shell:
  sysmon -i

Important: If a standalone Sysmon instance was previously installed from the Sysinternals site, it must be uninstalled before enabling the built‑in feature to avoid conflicts. Microsoft explicitly calls this out in the Insider notes.

Where Sysmon writes its events​

The in‑box Sysmon writes events into the teams already use: Applications and Services Logs → Microsoft → Windows → Sysmon → Operational. That preserves compatibility with SIEM parsers and collector pipelines built around the classic Sysmon event schema. Multiple independent outlets confirm the event destination and parity with the traditional Sysinternals tool.

---

Operational impact: what this changes for IT and security teams​

Lower friction, better servicing​

Making Sysmon an optional inbox feature reduces operational overhead in several concrete ways:

• Administrators can enable the capability through existing Windows feature‑management workflows rather than distributing a separate binary to every endpoint. This simplifies provisioning and patching across large fleets.
• Updates to the service can be handled through the Windows servicing pipeline and Windows Update, reducing version skew and the risk of unmanaged legacy copies.

What doesn’t change​

Sysmon remains a , not a detection engine. It does not analyze or alert on events by itself — it provides structured data for SIEM, EDR, or hunting tools to consume. The configuration model is still XML‑based and existing Sysmon XML configurations remain usable once the inbox feature is enabled.

Increased telemetry volume — plan for cost and capacity​

A typical pitfall when enabling Sysmon at scale is under‑estimating the volume of events generated. Even moderate configurations that include command lines and network connection events can produce a high cardinality of logs. Before any broad rollout:

• Measure event rates in a representative pilot.
• Validate SIEM ingest costs and throttling behavior.
• Update retention and index plans to accommodate higher volumes.

The inbox delivery makes mass enablement simpler, but it also makes large misconfigurations easier to deploy — which is why conservative rollout and telemetry budgeting are critical.

---

Compatibility and migration: moving from standalone Sysmon​

Uninstall first, then enable​

Microsoft requires removal of any previously installbefore enabling the built‑in feature. Practically, that means:

• Stop and uninstall the legacy Sysmon service across your estate via automation.
• Enable the inbox feature via DISM, PowerShell, or Settings.
• Initialize Sysmon with your hardened XML configuration: sysmon -i -accepteula -h sha256 -n -c <config.xml>.

Automating the uninstall and enabling steps is recommended for large fleets to avoid conflicts and maintain compliance during migration.

Configuration management and change control​

Because Sysmon’s XML defines what is collected and what noise is filtered, treat Sysmon configuration as a fiifact:

• Keep configs in source control and tie changes to change requests.
• Push config updates through the same deployment tooling you use for other OS components (Intune, SCCM, or your MDM).
• Test config changes in a lab or pilot group before applying widely.

Failing to control and version Sysmon configs leads to either alert fatigue or blind spots in detection.

---

Security, privacy, and compliance considerations​

Data minimization and legal review​

Sysmon captures fields that may have privacy sensitivity in some jurisdictions — notably command lines, file hashes, and IP addresses. Before you enable the feature broadly, perform a legal and privacy review to confirm that capturing those fields complions and your organization’s policies.

• Consider redaction and selective capture in your XML config where command lines include PII.
• Document retention and access controls for Sysmon logs, as they can be used for forensic reconstruction.

Access and monitoring controls​

Sysmon logs are useful for defenders but are also interesting from an attacker’s perspective. Ensure that:

• Event channels are protected with least‑privilege ACLs.
• Forwarded logs to SIEMs are encrypted in transit and access is tightly controlled.
• Alerting and monitoring rules are in place to detect unusual data exports o

Recommended rollout plan (practical, step‑by‑step)​

• Inventory & baseline: Identify endpoints, roles, and SIEM capacity. Flag any devices running standalone Sysmon.
• Lab validation: Enable the inbox feature on isolated test systems. Apply your hardened XML (or a conservative config) and measure event rates for 7–14 days.
• Pilot group: Choose representative endpoints (servers, developer workstations, SOC‑monitored hosts) and deploy via automation, monitoring ingestion pipelines and analyst workload.
• Triage & tune: Use the pilot to tune filters and reduce noisy event classes; rework detection content to leverage new observability.
• Ramp: Expand to security‑critical segments first, then to broader fleets only after capacity, cost, and alerting are stable.
• Full deployment: When ready, enable organization‑wide and bake Sysmon management into your OS baseline image and onboarding playbooks.

This staged approach limits false alarms and prevents surprise costs from SIEM ingestion spikes.

---

OneDrive sharing tweak: what changed and why it matters​

The UX change​

When right‑clicking a OneDrive cloud file and selecting Share → Copy link, the Windows share dialog now surfaces “Share using” options that let you directly send that link through installed apps (for example, mail clients or chat apps) without a separate copy‑and‑paste step. It’s a small improvement that reduces friction in common sharing scenarios and helps bridge cloud storage and desktop workflows. This capability is rolling out to Windows Insidcrosoft accounts outside the EEA at the time of the announcement.

Practical benefits​

• Faster sharing in the desktop environment — less clipboard juggling.
• Streamlined workflows for people who commonly send OneDrive links through mail or chat apps.
• Consistency with other share flows in Windows, making cloud links act like any other shareable content.

Risks and recommended user practices​

Convenience can be a vector for mistakes. The new flow increases the risk of inadvertently forwarding a link with overly permissive access (e.g., Anyone link vs Specific People). Recommendations for users and administrators:

• Train users to check link permissions and expiration settings before sharing.
• Encourage use of Specific People or authenticated links for sensitive documents.
• Consider conditional access or DLP controls to block insecure link types from being shared externally.

---

Canary channel notes and known issues​

Canary channel characteristics​

Remember that Canary is an early, experimental channel:

• Builds represent early platform changes that may be unstable.
• Features may be gated by Controlled Feature Rollout and appear only for subsets of Insiders even after the build installs.
• You cannot move from Canary to lower channels without a clean install of Windows; reverting often requires OS reimaging.

Known issue in this flight​

Microsoft notes a cosmetic issue: the desktop watermark in Build 28020.1611 initially showed the wrong build number for some Insiders. e corrected in a later build; in the meantime, use winver to confirm the accurate build string if you need to verify versions.

---

Cross‑checks and verification​

Key technical claims in this piece were verified against Microsoft’s official Insider blog and independent reporting:

• Microsoft’s Insider announcement documents the build, the enablement steps, the need to uninstall legacy Sysmon, and the OneDrive share change. ([blogs.windows.com](Announcing Windows 11 Insider Preview Build 28020.1611 (Canary Channel) outlets confirm event destinations, the unchanged Sysmon event model, and the operational implications for SIEM/EDR teams. See reporting from TechRepublic and TechSpot fvent channel behavior and deployment guidance.

Where documing, Microsoft says fuller guidance will be added to Windows documentation soon; until that arrives, administrators should treat the Insider notes and dures as the working guidance while validating in their own labs.

---

Strengths, trade‑offs, and potential risks​

deployment friction:** Making Sysmon optional and in‑box simplifies rollout, reduces dependency on external downloads, andconsistent.​

• Better observability: Organizations that adopt Sysmon more broadly will gain richer telemetry for threat detection and forensic investigations.
• Small UX win for sharing: The OneDrive share tweak addresses a common friction point for cloud file collaboration.

Trade‑offs and risks​

• Event volume and cost: Increased telemetry can raise SIEM ingestion and storage costs; conservative configs and telemetry budgeting are essential.
• Privacy and regulation: Command‑line capture and other fields can trigger privacy concerns or compliance obligations in some jurisdictions; legal review is required.
• Automation hazards: The easier enablement path makes it possible to deploy suboptimal configs at scale; change control must be enforced to avoid fleet‑wide problems.

---

What administrators should do next (quick checklist)​

• Audit current Sysmon installations and plan an automated uninstall of legacy copies.
• Spin up a lab image with the in‑box Sysmon enabled and test your hardened XML for event rate, noise, and SIEM parsing.
• Update ingestion and retention plans with your compliance and finance teams to account for expected volume increases.
• Educate users on OneDrive link permissions and monitor DLP/conditional access controls to prevent accidental oversharing.

---

Conclusion​

Build 28020.1611 is small in footprint but significant in implication: embedding Sysmon as an optional inbox feature marks a strategic move to make forensic‑grade telemetry a native part of Windows. For organizations that have long relied on Sysinternals tools for endpoint visibility, the change reduces operational friction and promises tighter servicing and lifecycle management. That said, the new path also raises immediate operational responsibilities — conservative configs, pilot deployments, ingestion planning, and legal review are non‑negotiable prerequisites to avoid surprises.
The OneDrive sharing adjustment is a sensible productivity refinement, but it underscores the perpetual trade‑off between convenience and data governance. Insiders and administrators should treat this Canary flight as an opportunity to validate capabilities in safe environments, tune policies and pipelines, and prepare for wider rollout when Microsoft moves the feature out of preview and into production channels.

---

Source: gHacks New Windows 11 Update Adds Built-In Sysmon and OneDrive Sharing Tweaks - gHacks Tech News

 

[ChatGPT]

Windows 11’s Canary build quietly folds a defender’s favorite into the operating system: Sysmon (System Monitor) is now available as an in‑box, optional Windows feature in Insider Preview build 28020.1611 (KB5077221), shipped to the Canary channel as a gated rollout — disabled by default and requiring an explicit enablement step by administrators or users. ([blogs.windows.com]s.com/windows-insider/2026/02/12/announcing-windows-11-insider-preview-build-28020-1611-canary-channel/)

Background / Overview​

Microsoft announced Windows 11 Insider Preview Build 28020.1611 to the Canary Channel on February 12, 2026, identifying the release as KB5077221 and calling out three customer‑visible items: the built‑in Sysmon capability, a small OneDrive sharing polish, and a desktop watermark fix. The Sysmon capability preserves the familiar Sysinternals feature set — process creation and command line capture, network connection correlation, image and driver loa, and more — while changing how the component is delivered, serviced, and managed.
This is a Canary‑channel experiment and Microsoft is rolling the option out gradually. That means not every Insider will immediately see the feature even after installing the build: server‑side gating and phased exposure remain in effect. Administrators, security teams, and IT pros should treat this as the start of a lifecycle change — not simply a cosmetic update to the tooling.

---

Wical facts​

Built‑in delivery model​

• Delivery: Sysmon is now delivered as an optional Windows feature included in the OS image and surfaced through Settings and Windows servicing workflows. This shifts Sysmon from a standalone Sysinternals ZIP/executable distribution to an in‑box component handled by the Windows feature management and update pipeline.
• Default state: The feature is disabled by default. Activating Sysmon requires explicit action by a local admin or enterprise management tooling.
• Enablement paths: Users or administrators can enable the optional feature via:
• Settings → System → Optional features → More Windows features → check Sysmon, then complete the installation by running the Sysmon initializer; or
• Command‑line automation: Dism /Online /Enable-Feature /FeatureName:Sysmon followed by sysmon -i from an elevated shell.

Compatibility and configuration​

• Uninstall prerequisite: If you already have the standalone Sysinternals Sysmon installed, uninstall it first to avoid driver and service conflicts before enabling the in‑box variant. Microsoft explicitly calls this out in the Insider flight notes.
• Configuration model: The in‑box Sysmon keeps the XML‑based configuration model that security teams use today, so existing Sysmon XML configs should be portable and usable after enabling the new feature. Events still land in the familiar Sysmon event channel in the Windows Event Log: Applications and Services Logs → Microsoft → Windownal.
• Functional parity: Microsoft and multiple independent outlets report that the built‑in implementation preserves the core capabilities and event model of the classic Sysinternals Sysmon: event IDs, structure, and telemetry types remain available, making it easier to maintain existing SIEM and EDR ingestion rules. However, this parity claim should be verified in environment testing before a wide rollout. ([techrepublic.com](Microsoft Starts Testing Built-In Sysmon Monitoring in Windows 11 matters: operational advantages

Making Sysmon an optional, in‑box feature changes several practical aspects of deployment and lifecycle management for defenders and IT teams.

• Simplified provisioning: Administrators can enable Sysmon across fleets with built‑in Windows management tools (DISM, Group Policy, Intune feature enablement workflows) rather than pushing a separate binary, which reduces distribution complexity.
• Consistent servicing: Because the component is integrated into Windows servicing, Microsoft can ship updates through the Windows Update pipeline and servicing stack — reducing version skew that historically resulted from manual or ad‑hoc Sysmon deployments. This should lower operational overhead for patching and compatibility testing.
• Better tooling integration: Sysmon as an in‑box feature appears in the same UI and management surface as other Windows components, enabling tighter automation via CM tools and standard OS lifecycle processes. This removes a class of custom packaging and signing problems that previously existed when distributing the standalone tool.

---

Risks and caveats: what to plan for before enabling​

The change looks positive at first glance, but there are non‑trivial operational, security, and privacy implications that deserve careful planning.

1) Driver/service conflicts and rollback complexity​

Because Sysmon installs a kernel driver and a service, switching from a standalone installation to the in‑box variant requires a clean driver and service to avoid conflicts. Poorly sequenced rollouts could create transient outages for monitoring collectors or generate duplicate telemetry that confuses ingestion pipelines. Test the uninstall‑then‑enable sequence in lab environments before mass deployment.

2) Configuration drift and version crosoft claims functional parity, the operational surface for Sysmon includes subtle behavior changes between versions (event formatting nuances, new event types, or driver changes). Organizations that rely on precise event shapes for detection logic should validate every relevant XML config and SIEM parser against the in‑box deployment. Treat the first weeks of any rollout as a high‑vigilance period for rule tuning. ([windowsreport.port.com/windows-11-beta-update-kb5074177-adds-built-in-sysmon-and-new-fixes/)​

3) Telemetry scale and ingestion cost​

Sysmon is intentionally verbose when configured for broad visibility. Turning it on across thousands of endpoints without careful filter planning can dramatically increase log volume and ingestion costs for SIEM/collector platforms, and may impact EDR performance. Use conservative pilot configurations, then iterate. Include storage and retention impact in your cost models.

4) Permissions, governance, and privacy​

Sysmon captures command lines, process arguments, file paths, and network connection metadata — all of which can include sensitive or regulated data. Enabling Sysmon broadside across user endpoints creates privacy and compliance obligations; data minimization, encryption in transit, and role‑based access to telemetry must be part of the deployment plan. Ensure legal and privacy teams sign off on telemetry collection baselines.

5) Testing on heterogeneous hardware and third‑party drivers​

Kernel driver compatibility varies with OEM firmware and third‑party drivers. Add Sysmon activation to driver compatibility test cases, especially for specialized hardware (medical devices, industrial endpoints, or custom drivers) and ensure recovery tooling covers driver signature or boot‑time issues. Canary builds are early — do not assume universal compatibility.

---

Practical rollout guidance: checklist and steps​

Below is a suggested rollout plan security teams can adapt. Treat this as operational playbook, not policy.

Pre‑deployment checklist​

• Inventory endpoints to identify operating system builds, management tools, EDR agents, and existing standalone Sysmon installs.
• Identify a pilot group representing typical hardware classes, software stacks, and geographies.
• Confirm SIEM/EDR ingestion pipelines and storage capacity for increased event volume.
• Draft a privacy/data retention policy specific to Sysmon telemetry and obtain approvals.
• Prepare rollback and remediation playbooks (how to uninstall in‑box Sysmon, reinstall previous versions, and revoke collected telemetry access).

Pilot steps (recommended)​

• Choose a small, representative pilot cohort (20–200 endpoints).
• Uninstall any standalone Sysmon on pilot machines.
• Enable the in‑box feature using automation or manual steps:
• Dism /Online /Enable-Feature /FeatureName:Sysmon
• Then run: sysmon -i <your-config.xml> from an elevated command line.
• Validate event delivery to your SIEM: check event channel path — Applications and Services Logs → Microsoft → Windows → Sysmon → Operational.
• Monitor collector performance, event rates, and detection logic for 7–14 days and iterate configuration to reduce noise.
• Update deployment scripts to include uninstall steps for old Sysmon versions and to push a hardened XML config.

Fleet rollout (post‑pilot)​

• Stage the rollout by business unit and OS image type.
• Automate the enablement through Intune, SCCM, or preferred management tool; include the post‑enablement sysmon -i command as part of the feature enable workflow.
• Monitor telemetry ingestion and tune rules and retention policies.
• Include Sysmon enablement in your standard OS image/refresh process to avoid unmanaged devices falling out of visibility.

---

Configuration recommendations (tactical)​

• Start with a baseline XML config that focuses on evidence‑grade events: process creation with command line, network connections, image load/hashes, driver loads, and file creation time changes. Avoid enabling extremely chatty options (like verbose file events) until you can measure the cost.
• Implement exclusion rules for known good scanners, software updaters, and legitimate background services to reduce noise.
• Use centralized configuration and version control for Sysmon XML files; push configuration changes through the same CI/CD channels you use for other detection content.
• Tag endpoints and telemetry sources in your SIEM to track where in‑box Sysmon was enabled and which configuration version is active.

---

Integration with EDR and SIEM​

Sysmon is a telemetry producer, not a detection engine. Effective value comes from integrating the structured events into detection logic, automated playbooks, and threat hunting queries.

• Map Sysmon event IDs to your SIEM schema and maintain a translation layer if necessary.
• Update threat hunting content and EDR correlation rules to account for any slight format differences introduced.
• Use aggregated Sysmon telemetry for host‑behavior baselining and to enrich alerts produced by EDR.

---

OneDrive sharing polish and watermark fix (brief)​

Alongside Sysmon, the KB5077221 Canary flight introduces a minor OneDrive UX change: when right‑clicking a OneDrive cloudy link*, a new Share using* option surfaces to let users send the link through other apps. This rollout is restricted initially to Microsoft‑account signed‑in Insiders outside the EEA. The build also contains a cosmetic fix to correct an incorrect desktop watermark showing the wrong build number. These are small quality‑of‑life updates compared with the operational significance of built‑in Sysmon.

---

How this changes the defender playbook long term​

• Reduction in third‑party distribution pain: mainstreaming Sysmon into Windows reduces the administrative friction of standardizing telemetry across an estate. Expect faster onboarding of devices in as the feature matures and lands in broader channels.
• Shift toward OS‑native telemetry management: security operations teams will increasingly treat Sysmon like other OS components — managed by Windows Update, audited as a feature, and included in baseline images and build pipelines. This opens possibilities for more integrated, policy‑driven telemetry governance.
• New governance and compliance workstreams: as collection becomes easier, organizations must balance the operational gains against privacy, compliance, and data‑minimization requirements. Expect Security, Privacy, and Legal teams to collaborate earlier in the telemetry lifecycle.

---

Verification, testing and what to watch next​

• Verify event parity for the critical event IDs your detection stack depends on. Run side‑by‑side comparisons of the standalone Sysmon and the in‑box variant in a controlled testbed to validate event formats and content.
• Watch Microsoft’s documentation for the official Sysmon in‑box guidance and any changelogs; the Insider blog note promises documentation to follow, and the Windows Insider blog post is the authoritative record for the Canary flight details.
• Expect Microsoft to iterate: Canary is the earliest public preview channel. Features and behaviors can change as Microsoft collects telemetry and feedback. rent behavior is final until it reaches broader channels with formal documentation.

---

Quick reference — commands and checks​

• Enable the feature (administrative shell):
• Dism /Online /Enable-Feature /FeatureName:Sysmon
• Then (elevated): sysmon -i <config.xml>
• Verify event path: Applications and Services Logs → Microsoft → Windows → Sysmon → Operational.
• Uninstall old standalone Sysmon before enabling to prevent conflicts.
• Use conservative XML configuration to limit log volume during initial rollout.

---

Final analysis: pragmatic optimism with disciplined rollout​

Microsoft’s move to make Sysmon an optional, in‑box Windows feature is operationally sensible and, in the medium term, beneficial to defenders. Delivery through the Windows servicing pipeline can reduce deployment pain, ensure more consistent versions, and make high‑fidelity endpoint telemetry more accessible to organizations of all sizes. That said, the change is not purely technical — it is organizational. The most common failure mode will be rushing to enable across a broad estate without pilot testing, configuration discipline, or privacy governance.
The right response for IT and security teams is methodical: inventory, pilot, validate, and automate. Test for compatibility, quantify ingestion and cost impacts, and treat the first weeks of production rollout as a high‑attention period for tuning detection logic and managing noise.
For defenders, in‑box Sysmon promises better operational hygiene; for risk and privacy teams, it raises questions that must be answered before you flip the switch across your fleet. Start planning now — but do not skip the engineering and governance steps that make telemetry both useful and sustainable.

---

Conclusion: KB5077221’s Canary delivery of built‑in Sysmon marks a meaningful shift in how Windows will surface and manage host telemetry. The feature looks ready to simplify provisioning and alignment between OS servicing and security telemetry, but success depends on disciplined rollout, careful configuration, and cross‑team governance. Security teams should plan pilots immediately, validate SIEM/EDR behavior, and coordinate privacy and compliance reviews before broad enablement.

---

Source: Windows Report https://windowsreport.com/windows-11-canary-build-kb5077221-adds-built-in-sysmon/

 

[ChatGPT]

Microsoft has quietly folded a defender’s favorite into Windows itself: the latest Windows 11 Insider Preview Canary build (Build 28020.1611 / KB5077221) exposes native Sysmon support as an optional, inbox feature and ships a compact set of OneDrive sharing and sync refinements that together signal a sharpened focus on built‑in telemetry, diagnostics, and cloud productivity. ([blogs.windows.com]s.com/windows-insider/2026/02/12/announcing-windows-11-insider-preview-build-28020-1611-canary-channel/)

Background / Overview​

Microsoft announced the Canary‑channel preview on February 12, 2026, and called out three customer‑visible items: built‑in Sysmon, a OneDrive sharing polish, and a corrected desktop watermark. The experimental rollout is gated and disabled by default — Insiders must explicitly enable the feature.
The change is more than convenience: Sysmon (System Monitor) has been one of the most relied‑upon tools for high‑fidelity endpoint telemetry. Historically distributed as a standalone Sysinternals download, Sysmon’s migration into Windows as an optional feature represents how defenders can provision, update, and support forensic‑grade logs across devices. Independent reporting and community notes confirm Microsoft’s intent to preserve Sysmon’s event model while changing delivery and servicing.

---

What exactly landed in Canary (the essentialier:** Windows 11 Insider Preview Build 28020.1611 (Canary), referenced as KB5077221 in Microsoft’s announcement.​

• Headline feature: Built‑in Sysmon delivered as an Optional Feature inside Windows. It is disabled by default and must be enabled via Settings or command line.
• Enablement paths:
• GUI: Settings > System > Optional features > More Windows features → check Sysmon.
• Command line / automation: Dism /Online /Enable-Feature /FeatureName:Sysmon then finish with sysmon -i.
• Compatibility note: If a standalone Sysmon (from Sysinternals) is already installed, Microsoft requires it to be uninstalled before enabling the in‑box variant to avoid driver/service conflicts.
• OneDrive polish: Copy link via File Explorer now surfaces a “Share usied OneDrive link can be dispatched through other apps from the Windows Share UI. This experience is rolling out to Microsoft‑account‑signed Insiders outside the EEA.

---

Technical deep dive: What “native Sysmon” means​

The Sysmon model — unchanged, but relocated​

Sysmon’s core functionality — process creation/ter command line), network connection attribution, image/driver loads, file and registry events, WMI activity, and tamper detection — remains conceptually the same. The inbox variant preserves the familiar event IDs and writes to the same Windows Event Log channel that defenders already use: Applications and Services Logs → Microsoft → Windows → Sysmon → Operational. That means existing SIEM and EDR ingestion pipelines should work in principle, but teams must validate field‑level parity in practice.

Packaging and servicing changes​

Instead of shipping as a separate Sysinternals ZIP, Sysmon’s binary and kernel driver are now bundled and governed by Windows feature management and the OS servicing pipeline. Updates can flow through Windows Update/WSUS/Intune, reducing version skew and manual distribution overhead. The component remains optional and disabled has intentionally left administrative control in the hands of organizations. (blogs.windows.com)

Configuration and operational model​

• XML‑based configurations are still supported. Existing Sysmon XML rulesets should be portable, enabling familiar tuning of what getows.com]
• Activation remains a two‑step operation: enable the Optional Feature (Settings or DISM/PowerShell) and then run the Sysmon CLI to install and apply configs (e.g., sysmon -i config.xml).
• Event pipeline continues to target the standard Sysmon event channel for compatibility with collectors and SIEMs.

---

Why Microsoft moved Sysmon in‑box — benefits and operational wins​

Embedding Sysmon into Windows is primarily an operational improvement, with tangible security benefits.

• Simplified deployment at scale. Admins can enable Sysmon with standard Windows management tools instead of packaging and distributing a separate executable across thousands of endpoints. This reduces packaging complexity and the risk of unsigned or incorrectly Consistent servicing. Updates to the component can be distributed through Microsoft’s servicing channels, shrinking the instrumentation gap that appears when devices run different Sysmon versions.
• Better management integration. The feature appears in Windows’ feature surface, making Intune/Group Policy/WSUS automation simpler and enabling standard lifecycle workflows for defenders.
• erage. Organizations that never deployed Sysmon because of operational costs can now consider enabling robust host telemetry with far less work.

These are real wins for security operations, threat hunting, and incident response teams — but the operational simplicity comes with technical responsibilities, which we examine next.

---

Notable risks, caveats, and what defenders must plan for​

Switching to an inbox Sysmon has tradeoffs. Below are the most important risks and mitigation considerations.

1) Log volume, telemetry costs, and ingestion planning​

Sysmon can generate very high event volumes when configured broadly. If you enable Sysmon fleet‑wide without a careful filtering strategy, expect:

• Increased local disk usage for event stores,
• Network egress spikes if you forward events to a cloud SIEM,
• Higher costs for cloud ingestion and storage.

Action: model expected event rative pilot group, tune XML configs to reduce noise, and update retention policies and ingestion quotas before wide deployment.

2) Schema and field parity — validate, don’t assume​

Microsoft promises functional parity, but even small differences in field names or enrichment logic can break detection rules and parsers. Treat parity as a hypothesis to be validated.
Action: run side‑by‑side tests comparing events from your existing standalone Sysmon and the inbox variant; verify every field your detection stack depends on.

3) Conflicts with existing Sysmon installations​

Microsoft requires uninstalling standalone Sysmon before enabling the built‑in feature to avoid driver/service conflicts.
Action: build a migration plan that uninstalls the legacy agent, enables the inbox feature, installs sysmon (sysmon -i) with your vetted XML, and verifies stability. Automate and stage the process via Intune/SCCM when possible.

4) Privacy, compliance, and governance​

More telemetry at the OS level increases the surface for privacy or regulatory concerns — particularly when Sysmon events contain command lines, file paths, usernames, or network endpoints.
Action: engnd compliance teams early. Define acceptable collection scope, anonymization/pseudonymization needs, and retention limits. Ensure DLP and conditional access policies account for new link‑sharing behavior in OneDrive.

5) Performance and stability concerns​

Although Sysmon has been used in production for years, the inbox variant introduces a new servicing path and potential for bugs tied to driver updates or OS interactions.
Action: pilot the feature on first and monitor for CPU/kernel driver issues, event log overflow, or application regressions. Keep a rollback plan ready.

---

OneDrive tweaks: a subtle but useful polish​

The Canary build also refines the OneDrive share UX within File Explorer. When a user right‑clicks a OneDrive cloud file and chooses Copy link, the share flow now surfaces a “Share using” list — letting the link be sent through other apps via the This is a productivity usability fix intended to reduce friction when sharing cloud links from File Explorer. Microsoft confirmed the experience is rolling out to Microsoft‑account‑signed Insiders outside the EEA. ([blogs.blogs.windows.com/windows-insider/2026/02/12/announcing-windows-11-insider-preview-build-28020-1611-canary-channel/)
Beyond the UI change, community and Beta reports describe fixes addressing OneDrive sync and instability scenarios (e.g., app freezes when working with files on OneDrive or Dropbox) and performance improvements when handling large folders. These soft improvements matter because they reduce friction for everyday users while organizations adapt to more seamless cloud‑native file handling.

---

Practical enablement and migration checklist for IT teams​

Below is a practical, actionable checklist administrators can follow when evaluating and planning a rollout of the built‑in Sysmon feature.

• Pilot selection and scope
• Identify a small, representative pilot fleet (50–200 endpoints) that mirrors desktop/server roles.
• Ensure pilot systems run the Insider build that surfaces the feature (Canary/Dev/Beta var
• Inventory and uninstall legacy Sysmon
• Audit endpoints for existing Sysmon installations.
• Uninstall the standalone Sysmon to avoid driver/service conflicts before enabling the inbox feature.
• Plan ingestion and retention
• Estimate event rates and plan SIEM ingestion, retention, and storage costs.
• Update retention and archiving policies to account for higher telemetry volume.
• Prepare and validate XML configurations
• Reuse existing XML files as a starting point, but validate event field parity.
• Tune rules to reduce noise (exclude benign processes, refine network capture scope).
• Enable and install (pilot)
• Enable the Optional Feature via DISM/GUI or automate via Intune/PowerShell:
• Dism /Online /Enable-Feature /FeatureName:Sysmon
• Elevated: sysmon -i config.xml
• Verify events in Applications and Services Logs → Microsoft → Windows → Sysmon → Operational.
• Validate end‑to‑end ingestion and detections
• Confirm SIEM parsers accept events and that detection rules trigger as expected.
• Run known‑good and simulated malicious scenarios to measure detection fidelity.
• Scale gradually and monitor health
• Move from pilot → controlled production → full rollout while event volumes, and user impact.
• Keep a rollback path to uninstall the inbox feature if unacceptable regressions occur.
• Coordinate cross‑functional governance
• Engage privacy, legal, compliance, and SOC teams to finalize retention, access, and data handling rules.

---

Recommended Sysmon configuration guidance (high level)​

• Start conservative: capture Event ID 1 (Process Create) and Event ID 3 (Network Connection) with filtering for known‑good software. Avoie monitoring across all paths initially.
• Use allow/deny lists: explicitly allow high‑volume benign software and deny noisy telemetry sources where possible.
• Apply modular configs: maintain separate XML modules for proces update them through your configuration management system.
• Implement phased enrichment: only enable resource‑heavy logging (file hashes, image loads) in high‑risk cohorts.

Note: these are general best practices; tailor settings to your environment’s threat model and storage capacity.

---

How this shapes the Windows security landscape​

Bringing Sysmon inside Windows is part of a larger trend: operating systems shipping deeper, opinionated telemetry to make detection and response more accessible. The net effect for enterprise defenders should be:

• Improved baseline visibility — fewer endpoints without host telemetry.
• Lower operational friction — simpler distri- Greater opportunity for standardization — centralized management of telemetalso raises new responsibilities: telemetry governance, ingestion budglidation to avoid broken detection rules. If Microsoft follows through with documentation and smooth servicing, this could be one of the more consequential platform changes for defenders in recent Windows cycles.

---

What to watch next​

• Documentation release. Microsoft said documentation will be added to Windows pages soon. Teams should watch for the official docs to confirm exact field mappings and supported Event IDs.
• Parity validation. Expect community testing and SOC reports to surface edge casichment diverge from the classic Sysmon. Treat any parity differences as breaking‑change risks for detection packs.
• Rollout cadence. The feature is gated via Microsoft’s Controlled Feature Rollout; not every Insider will see it immediately. Monitor Windows Update and Insider channels for broader availability across Beta/Dev/Canary.
• OneDrive behavior refinement. Watch for behavioral changes tied to the “Share using” flow and confirm corporate DLP/conditional access policies account for the new share delivery paths.

---

Bottom line and recommendations​

Microsoft’s move to package Sysmon as an optional, native Windows feature is a pragmatic operational step with significant upside for defenders and IT teams. It lowers the bar for deploying forensic‑grade telemetry and aligns Sysmon with Windows servicing and management paradigms. That said, organizations must treat the change as a controlled migration project.

• Pilot first, validate schema parity, and measure event volumes.
• Engage compliance and privacy stakeholders before enabling wide collection.
• Prepare ingestion and retention plans to avoid unexpected costs.
• Uninstall legacy Sysmon before enabling the in‑box feature and automate the migration.

If you are an Insider who wants to test this now, enable the Optional Feature and apply a conservative XML config in a lab environment. If you are an enterprise defender, start the conversations and pilots today: native Sysmon is a platform change that — if managed well — can materially improve your detection posture with less day‑to‑day overhead.
Microsoft’s Canary build is an early indicator, not a final release; features may evolve as feedback arrives. Still, the direction is clear: Windows is becoming more opinionated about what telemetry it can and should provide, and Sysmon’s move into the OS signals a meaningful step toward richer, native endpoint visibility.

---

Source: thewincentral.com Windows 11 Canary Build Adds Native Sysmon Support & more