Get Windows Events Into Sentinel

Why Windows events come first

Choosing the right connector

Not all data connectors are equal. The exam tests whether you can select the right connector based on the data source requirements.

Data Source	Recommended Connector	Why
Azure VMs (Windows)	Windows Security Events via AMA	Direct agent-based collection with DCR filtering
On-premises Windows servers	Windows Security Events via AMA (with Azure Arc)	Arc extends AMA to non-Azure machines
Large on-prem estate with existing WEF	Windows Event Forwarding + AMA on collector	Centralise events first, then forward to Sentinel
Microsoft Defender for Endpoint devices	XDR connector (built-in)	Device events flow through Defender XDR automatically
Azure platform logs	Diagnostic settings	Not Windows events — covered in the next module

💡 Exam tip: the legacy MMA connector

The older Microsoft Monitoring Agent (MMA) connector still appears in some documentation. It is deprecated. The exam expects you to recommend AMA for new deployments.

If a question mentions “an organisation is migrating from MMA to the current recommended agent,” the answer is Azure Monitor Agent (AMA).

Windows Security Events via AMA

The Azure Monitor Agent (AMA) is the modern, recommended way to collect Windows events. It uses Data Collection Rules (DCRs) to control exactly what gets sent to Sentinel.

How it works

1. Install AMA on the Windows machine (Azure VMs get it automatically; on-prem machines need Azure Arc)
2. Create a Data Collection Rule that specifies which event IDs or categories to collect
3. Associate the DCR with the target machines
4. Events flow from the machine → AMA → Log Analytics workspace → Sentinel

Data collection rule filtering

DCRs let you filter events at the source — before they even leave the machine. This saves ingestion costs and reduces noise.

Preset	What It Collects	Events per Day (approx.)
Minimal	Critical security events only (failed logins, privilege escalation)	Low
Common	Most security-relevant events (logins, logoffs, account management, policy changes)	Medium
All Events	Every event from the Security log	High (can be very noisy)
Custom (XPath)	Specific Event IDs you define using XPath queries	You control

💡 Scenario: Anika's DCR strategy for 40 clients

Anika at Sentinel Shield manages ingestion for 40 MSSP clients. She cannot send “All Events” for every client — the cost would be astronomical.

Her DCR strategy:

• All clients get “Common” as the baseline — covers authentication, account changes, and policy modifications
• Financial services clients get a custom DCR adding Event ID 4688 (process creation) for threat hunting
• Healthcare clients get a custom DCR adding object access events for PHI compliance
• Small businesses get “Minimal” — just failed logins and privilege escalation

Each client’s DCR is associated with their specific machines via Azure Arc. One machine can only be associated with one DCR for a given data type.

Custom XPath filtering

For precise control, you write XPath queries in the DCR to select specific Event IDs:

Security!*[System[(EventID=4624 or EventID=4625 or EventID=4672 or EventID=4688)]]

This collects only:

• 4624 — successful logon
• 4625 — failed logon
• 4672 — special privileges assigned
• 4688 — new process created

Everything else stays on the machine.

Windows Event Forwarding (WEF)

WEF is Microsoft’s built-in mechanism for centralising Windows events before they reach Sentinel. It uses a collector server that pulls events from source machines.

When to use WEF

• Large on-premises environments with thousands of servers where installing AMA on every machine is impractical
• Environments that already have a WEF infrastructure in place
• Scenarios requiring event aggregation before cloud ingestion (reduces direct internet connections)

WEF architecture

Source machines → push events → WEF Collector → AMA on collector → Sentinel

The collector server runs the Windows Event Collector (WEC) service and has AMA installed. Source machines push events to the collector using subscriptions configured via Group Policy.

AMA direct is simpler; WEF is better for large on-prem environments

Feature	AMA (Direct)	WEF + AMA (via Collector)
Agent required on each machine	Yes — AMA on every source	No — only AMA on the collector
Filtering	DCR-based (XPath) at source	WEF subscription filters + DCR on collector
Best for	Azure VMs, Arc-connected on-prem, smaller environments	Large on-prem estates, air-gapped networks, existing WEF setups
Latency	Near real-time (seconds)	Slightly higher (depends on WEF subscription interval)
Management	Azure Policy can auto-deploy AMA + DCR	Group Policy manages WEF subscriptions
Recommended by Microsoft	Yes — preferred for new deployments	Yes — for large-scale on-prem with existing WEF

💡 Exam tip: WEF is NOT deprecated

Unlike MMA, WEF is still a supported and recommended approach for specific scenarios. The exam may present a scenario with 5,000 on-premises servers and ask the best approach. If AMA on every machine is impractical, WEF + AMA on a collector is the answer.

Question

What is a Data Collection Rule (DCR) and why does it matter?

Click or press Enter to reveal answer

Answer

A DCR defines which events to collect from a source machine using the Azure Monitor Agent. It filters events at the source before ingestion, reducing costs and noise. You can use presets (Minimal, Common, All Events) or custom XPath queries for specific Event IDs.

Click to flip back

Question

When should you use WEF instead of AMA direct?

Click or press Enter to reveal answer

Answer

Use WEF when: 1) You have a large on-premises estate where installing AMA on every machine is impractical. 2) WEF infrastructure already exists. 3) You need to aggregate events before cloud ingestion. WEF uses a collector server with AMA to forward centralised events to Sentinel.

Click to flip back

Question

What replaced the Microsoft Monitoring Agent (MMA) for Windows event collection?

Click or press Enter to reveal answer

Answer

The Azure Monitor Agent (AMA). MMA is deprecated. AMA is the recommended agent for new deployments, using Data Collection Rules for granular filtering.

Click to flip back

Knowledge Check

Anika needs to collect only failed logon events (Event ID 4625) and process creation events (Event ID 4688) from a client's servers. Which approach should she use?

AInstall AMA with the 'All Events' preset — then filter in SentinelBConfigure Windows Event Forwarding to send only those eventsCInstall AMA with a custom DCR using XPath filtering for Event IDs 4625 and 4688DUse the Microsoft Monitoring Agent with a saved search

Check Answer

Knowledge Check

James at Pacific Meridian has 5,000 on-premises Windows servers in a datacenter with an existing WEF infrastructure. What is the most efficient way to get their security events into Sentinel?

AInstall AMA on all 5,000 servers using Azure ArcBConfigure each server to send events directly to the Log Analytics workspace APICUse the Microsoft Monitoring Agent on all serversDKeep the existing WEF infrastructure, install AMA on the WEF collector server, and forward events to Sentinel

Check Answer

🎬 Video coming soon

Next up: Windows events are flowing. Now let’s connect the rest — Syslog from Linux, CEF from firewalls, and Azure activity logs.