News and blog
NXLog main page
  • Products
    NXLog Platform
    Log collection
    NXLog Agent
    NXLog Community Edition
    Integrations
    Professional Services
  • Solutions
    Use cases
    Specific OS support
    SCADA/ICS
    Windows event log
    DNS logging
    MacOS logging
    Open Telemetry
    Cost reduction
    Industries
    Financial Services
    Government & Education
    Entertainment & Gambling
    Telecommunications
    Medical & Healthcare
    Military & Defense
    Law Firms & Legal Counsel
    Industrial & Manufacturing
  • Pricing
    Licensing
    Plans
  • Partners
    Find a Reseller
    Partner Program
    Partner Portal
  • Resources
    Documentation
    Blog
    White papers
    Videos
    Webinars
    Case Studies
    Community Program
    Community Forum
  • About
    Company
    Careers
  • Support
    Support portals
    Contact us

NXLog Platform
Log collection
NXLog Agent
NXLog Community Edition
Integrations
Professional Services

Use Cases
Specific OS support
SCADA/ICS
Windows event log
DNS logging
MacOS logging
Open Telemetry
Cost reduction
Solutions by industry
Financial Services
Government & Education
Entertainment & Gambling
Telecommunications
Medical & Healthcare
Military & Defense
Law Firms & Legal Counsel
Industrial & Manufacturing

Licensing
Plans

Find a Reseller
Partner Program
Partner Portal

Documentation
Blog
White papers
Videos
Webinars
Case Studies
Community Program
Community Forum

Company
Careers

Support portals
Contact us
Let's Talk
  • Start free
  • Interactive demo
Let's Talk
  • Start free
  • Interactive demo
NXLog search
  • Loading...
Let's Talk
  • Start free
  • Interactive demo
October 29, 2026 siem

Microsoft Sentinel on legacy Windows after the Log Analytics agent retirement

By João Correia

Share
ALL ANNOUNCEMENT COMPARISON COMPLIANCE DEPLOYMENT SECURITY SIEM STRATEGY RSS
Key takeaways
  • Microsoft retired the Log Analytics agent (MMA) on August 31, 2024, and can shut down its cloud ingestion services at any time after March 2, 2026.

  • The Microsoft Azure Monitor Agent (AMA) runs only on 64-bit Windows Server 2016 or later and Windows 10 1803 or later. It won’t install on Windows Server 2008, Server 2003, or any 32-bit Windows.

  • Windows Event Forwarding (WEF) and syslog forwarders help, but each has hard limits on these hosts.

  • NXLog Agent for 32-bit Windows sends events over TLS 1.2 to a relay, which writes them to Microsoft Sentinel through the Logs Ingestion API.

Most Microsoft Sentinel workspaces have a few Windows hosts that nobody can onboard: the Windows XP machine inside an ATM, the Windows Server 2003 host that runs a production line, the 32-bit Windows 7 PC attached to lab equipment. You can’t upgrade them, and the teams that own them won’t let anyone change them. If they’re in scope for PCI DSS or NIS2, your auditors still expect their logs.

What the Log Analytics agent retirement means for legacy Windows

Microsoft retired the Log Analytics agent, also known as the Microsoft Monitoring Agent (MMA), on August 31, 2024. Its migration guide says Microsoft can shut down the agent’s cloud ingestion services at any time after March 2, 2026. The only exception is an agent connected exclusively to an on-premises System Center Operations Manager (SCOM) installation.

For Windows 7, Server 2008, and 32-bit Windows, MMA was Microsoft’s last agent path into Microsoft Sentinel. Microsoft’s archived install guide lists Windows 7 SP1, Server 2008 SP2, and Server 2008 R2 SP1. Windows XP and Server 2003 were never on the list.

Custom scripts have their own deadline. Microsoft ended support for the HTTP Data Collector API on September 14, 2026. Its migration guide says ingestion continues, but only for clients that negotiate TLS 1.2 or later.

To find hosts that still depend on MMA, query the Heartbeat table, where MMA reports with the category Direct Agent:

Heartbeat
| where TimeGenerated > ago(90d)
| where Category == "Direct Agent"
| summarize LastHeartbeat = max(TimeGenerated)
    by Computer, OSType, OSName, OSMajorVersion, OSMinorVersion
| extend DaysSilent = datetime_diff('day', now(), LastHeartbeat)
| order by DaysSilent desc

Match the lookback to your workspace retention, because a host whose uploads stopped before the window starts won’t appear. OS version 6.0 is Windows Vista or Server 2008, and 6.1 is Windows 7 or Server 2008 R2, per Microsoft’s version reference.

Does the Microsoft Azure Monitor Agent run on Windows Server 2008?

No. Microsoft’s AMA supported operating systems page, last updated August 31, 2026, starts with Windows Server 2016 and Windows 10 1803 and states that Microsoft doesn’t support x86 on any operating system. Servers outside Microsoft Azure also need Microsoft Azure Arc, and Microsoft’s 32-bit support article notes that extensions such as AMA don’t work on 32-bit Microsoft Azure VMs.

Windows version Log Analytics agent (retired) Azure Monitor Agent NXLog Agent

Windows 2000, XP, Server 2003 (32-bit)

Not supported

Not supported

32-bit package

Windows Server 2008 SP2

Supported until retirement

Not supported

32-bit (x86) or 64-bit (x64) package

Windows Server 2008 R2 SP1, Windows 7 SP1 (64-bit)

Supported until retirement

Not supported

64-bit package

Windows 7, 8, and 10 (32-bit)

x86 installer, now retired

Not supported

32-bit package

NXLog Agent coverage comes from our supported platforms list.

What Microsoft still offers for legacy Windows

Microsoft Sentinel has no agent of its own. It collects Windows data through AMA, so a host that can’t run AMA needs another path. Microsoft offers two.

Windows Event Forwarding to an AMA collector

Source machines forward events to a Windows Event Collector (WEC) running AMA, and the Windows Forwarded Events connector streams them into Microsoft Sentinel. Windows XP SP2 and Windows Server 2003 SP1 or later can be WEF sources once you add WinRM. On those hosts, expect these limits:

  • To forward the Security log, WinRM must run as Local System, an elevation Microsoft says has security implications.

  • WEF traffic is Kerberos-encrypted inside a domain. Outside one, it needs HTTPS, and Windows Server 2003 can’t negotiate TLS 1.2.

  • The collector must run Windows Server 2016 or later, Arc-enabled on-premises.

  • The connector writes to WindowsEvent, while many built-in analytics rules query SecurityEvent.

  • WEF carries event logs only, and collectors have scaling limits of their own.

Syslog or CEF through a Linux forwarder

The Syslog and CEF via AMA connectors put AMA on a Linux forwarder. Windows doesn’t emit syslog, so each legacy host still needs an agent that does. Microsoft’s setup script opens port 514 for TCP and UDP, and TLS from your sources is a manual rsyslog or syslog-ng job.

How the routes compare, including unofficial scripts:

Route XP and Server 2003 Legacy-hop encryption Lands in Main limit

WEF to an AMA collector

Yes, with WinRM

Kerberos in a domain, no TLS 1.2 on Server 2003

WindowsEvent

Event logs only

Syslog or CEF via AMA

Only with an agent on the host

Plain TCP or UDP unless you add TLS

Syslog or CommonSecurityLog

Flattens event structure

Data Collector API script

Not with the built-in TLS stack

TLS 1.2

Classic custom table

Support ended September 14, 2026

NXLog Agent for 32-bit Windows and a relay

Yes

TLS 1.2 through bundled OpenSSL

SecurityEvent or a custom table

A relay tier to run

Why TLS 1.2 blocks a direct path from Windows XP and Server 2003

Both Microsoft APIs a legacy host could call directly now require TLS 1.2. Microsoft Azure Monitor began enforcing it on Logs Ingestion API endpoints on March 1, 2026, the same day the Data Collector API endpoint stopped accepting older versions.

Schannel, the TLS stack built into Windows, has no TLS 1.2 on Windows XP or Server 2003. Microsoft added it to Windows Server 2008 SP2 in July 2017, deactivated by default. The same update, KB4019276, covered Windows XP-based embedded editions such as POSReady 2009, but not standard Windows XP or Server 2003.

NXLog Agent for 32-bit Windows doesn’t depend on Schannel. The package bundles the latest OpenSSL version compatible with each supported OS, so TLS 1.2 works on all of them. NXLog covers CVEs in the bundled OpenSSL 1.0.2 and 1.1.1 builds on a best-effort basis and updates the package around twice a year. Keep the legacy hop inside your network and end it at a relay you patch on a normal schedule.

How to get Windows Server 2003 logs into Microsoft Sentinel

The setup has two tiers. NXLog Agent for 32-bit Windows on each legacy host sends events over TLS 1.2 to a relay. NXLog Agent on a Linux or 64-bit Windows relay maps the fields and writes to Microsoft Sentinel with the Microsoft Azure Logs Ingestion output module through the Logs Ingestion API and a data collection rule (DCR). The relay needs a Microsoft Entra app registration, not AMA or Microsoft Azure Arc.

The legacy host can’t handle the Microsoft Azure side itself. The 32-bit package doesn’t include the required output module, and the Microsoft Azure Sentinel output module it includes uses the workspace ID and shared key of the Data Collector API, which Microsoft no longer supports.

Two-tier log collection from legacy Windows hosts through an NXLog Agent relay into Microsoft Sentinel
Figure 1. Two-tier collection from legacy Windows into Microsoft Sentinel

NXLog’s sizing guidance puts one relay at about 5,000 events per second and 50 to 100 collectors, depending on each host’s volume. Size for peak load and test with your own volume.

Step 1: Configure the agent on Windows Server 2003 and XP

On pre-Windows Vista hosts, the Event Log for Windows XP/2000/2003 input module reads the legacy Event Log API. Add this to the default nxlog.conf, which already defines %CERTDIR%:

<Input windows_events>
    Module             im_mseventlog
    Sources            Application, Security, System
    ReadFromLast       TRUE (1)
</Input>

<Output relay>
    Module             om_batchcompress
    Host               relay-1.example.local:2514 (2)
    Host               relay-2.example.local:2514
    UseSSL             TRUE
    SSLProtocol        TLSv1.2
    CAFile             %CERTDIR%/ca.pem
    CertFile           %CERTDIR%/agent-cert.pem
    CertKeyFile        %CERTDIR%/agent-key.pem
    PersistLogqueue    TRUE (3)
    LogqueueSize       104857600
</Output>

<Route windows_events_to_relay>
    Path               windows_events => relay
</Route>
1 Set ReadFromLast to FALSE to backfill the existing log.
2 The two Host lines fail over between relays. The NXLog Transport output module resends any batch the relay doesn’t acknowledge.
3 PersistLogqueue keeps queued events on disk through outages and reboots up to the 100 MiB soft limit set by LogqueueSize. Our offline buffering guide covers the sizing trade-offs.

For 32-bit Windows Vista or later hosts (Windows Server 2008 and Windows 7, 8, and 10), use the Event Log for Windows input module instead and point both Host lines at port 2515.

Step 2: Prepare Microsoft Sentinel

Our Microsoft Sentinel integration guide walks through the Microsoft Azure side. You need:

  • A Microsoft Entra app registration with a certificate or client secret for the relay.

  • A data collection endpoint (DCE).

  • A custom table, LegacyWindowsEvent_CL, with columns that match the relay output in Step 3.

  • A DCR with two data flows. Custom-LegacyWindowsEvent goes to the custom table unchanged, and Custom-VistaSecurityEvent goes to the built-in SecurityEvent table, which accepts Logs Ingestion API data.

  • The Monitoring Metrics Publisher role for the app on the DCR, which can take up to 30 minutes to apply.

Step 3: Configure the relay

The relay configuration follows our relay pattern. The NXLog Transport input module requires a client certificate by default, so each legacy agent authenticates with its own certificate. This is the 32-bit Windows path:

<Extension json>
    Module               xm_json
</Extension>

<Input legacy_agent> (1)
    Module               im_batchcompress
    ListenAddr           0.0.0.0:2514
    AllowIP              192.168.10.0/24
    CAFile               /opt/nxlog/cert/ca.pem
    CertFile             /opt/nxlog/cert/relay-cert.pem
    CertKeyFile          /opt/nxlog/cert/relay-key.pem
    TLSConnectLog        TRUE (2)
</Input>

<Output microsoft_sentinel>
    Module               om_azuremonitor
    URL                  https://<dce-name>.<region>-1.ingest.monitor.azure.com
    TenantId             <tenant-id>
    ClientId             <app-client-id>
    CertThumbprint       <certificate-thumbprint>
    CertKeyFile          /opt/nxlog/cert/entra-app-key.pem
    DcrImmutableId       <dcr-immutable-id>
    StreamName           Custom-LegacyWindowsEvent
    OutputRequestSize    1000000 (3)
    <Exec>
        $out_template = ( 'TimeGenerated'     => $EventTime,
                          'OriginalEventTime' => $EventTime, (4)
                          'Computer'          => $Hostname,
                          'Channel'           => $FileName,
                          'EventID'           => $EventID,
                          'EventType'         => $EventType,
                          'Provider'          => $SourceName,
                          'Category'          => $Category,
                          'AccountName'       => $AccountName,
                          'AccountDomain'     => $Domain,
                          'RecordNumber'      => $RecordNumber,
                          'Message'           => $Message );
        $raw_event = to_json($out_template);
    </Exec>
</Output>

<Route legacy_agent_to_microsoft_sentinel>
    Path                 legacy_agent => microsoft_sentinel
</Route>
1 Receives events from Windows 2000, XP, and Server 2003 agents.
2 TLSConnectLog records the negotiated TLS version for each agent connection, which gives auditors evidence for the legacy hop.
3 OutputRequestSize keeps requests under the API’s 1 MB per-call limit.
4 Microsoft Azure Monitor replaces a TimeGenerated value more than two days old with the receive time. After a long outage, use OriginalEventTime for the real event time.

For Windows Vista or later hosts, add a second listener on port 2515 and a second Microsoft Azure Logs Ingestion output module instance for the Custom-VistaSecurityEvent stream. Map EventData fields such as TargetUserName, LogonType, and IpAddress to their SecurityEvent columns, so that built-in rules can query the new rows.

Make legacy events work with Microsoft Sentinel analytics

Built-in content won’t match pre-Windows Vista events because Windows Vista renumbered the Security events. As Microsoft’s Eric Fitzgerald explained, for almost all events, the new ID is the old ID plus 4096. Successful logon event IDs 528 and 540 became 4624, and logon failure event IDs 529-537 and 539 became 4625.

He also warns against automating a blanket mapping, because many events don’t map one-to-one. So keep pre-Windows Vista events in their own table, map only the event IDs you’ve checked, and parse fields at query time. Save this as a workspace function named LegacyWindowsSecurity:

LegacyWindowsEvent_CL
| where Channel == "Security"
| extend ModernEventID = case(
    EventID in (528, 540), 4624,
    EventID in (529, 530, 531, 532, 533, 534, 535, 536, 537, 539), 4625,
    EventID == 517, 1102,
    long(null))
| extend LogonType = toint(extract(@"Logon Type:\s*(\d+)", 1, Message)),
         TargetUserName = trim(@"\s+", extract(@"User Name:\s*([^\t\r\n]+)", 1, Message))

Event ID 517 is the exception to the +4096 rule. On Windows Server 2003, it records a cleared audit log, which is event ID 1102 on Windows Vista and later. Other events keep an empty ModernEventID until you map them. Build detections on the function. This one flags bursts of failed logons:

LegacyWindowsSecurity
| where ModernEventID == 4625
| summarize FailedLogons = count() by Computer, TargetUserName, bin(TimeGenerated, 10m)
| where FailedLogons >= 10

Catch hosts that go quiet

NXLog Agent doesn’t write to the Heartbeat table, so check freshness from the data itself. On hosts that are quiet by design, add a Mark input module instance, which sends a marker every 30 minutes by default.

LegacyWindowsEvent_CL
| summarize LastSeen = max(TimeGenerated) by Computer
| where LastSeen < ago(2h)
| order by LastSeen asc

Keep legacy hosts in your Microsoft Sentinel coverage

Microsoft no longer has an agent for Windows 7, Server 2008, or 32-bit Windows, and WEF and syslog forwarders close only part of the gap. A 32-bit agent and a relay give you TLS 1.2 on the legacy hop, a disk buffer for outages, and events your analysts can query, while the Azure-facing side runs on a server you can patch.

Want to try it on your legacy hosts? Start free with NXLog Platform and deploy NXLog Agent on a test host and a relay.

FAQ

Does the Microsoft Azure Monitor Agent support Windows Server 2008 R2?

No. AMA starts at Windows Server 2016 and doesn’t support x86. Windows Server 2008 and 2008 R2 relied on the Log Analytics agent, which Microsoft retired on August 31, 2024.

How do I send Windows Server 2003 event logs to Microsoft Sentinel?

Install NXLog Agent for 32-bit Windows, collect events with the Event Log for Windows XP/2000/2003 input module, and forward them over TLS 1.2 to a relay. The relay writes to Microsoft Sentinel with the Microsoft Azure Logs Ingestion output module through the Logs Ingestion API.

Will built-in Microsoft Sentinel rules detect activity on Windows XP and Server 2003?

Not without normalization. Windows versions before Vista use different event IDs and a different schema, such as 528 and 540 instead of 4624 for successful logons. Map the IDs you need in a KQL function and build detections on it.

NXLog Platform is an on-premises solution for centralized log management with
versatile processing forming the backbone of security monitoring.

With our industry-leading expertise in log collection and agent management, we comprehensively
address your security log-related tasks, including collection, parsing, processing, enrichment, storage, management, and analytics.

Start free Contact us
  • Microsoft Sentinel
  • Windows
  • Telemetry collection
Share

Facebook Twitter LinkedIn Reddit Mail
Related Posts

Making the most of Windows Event Forwarding for centralized log collection in 2026
7 minutes | July 8, 2026
DNS Log Collection on Windows
9 minutes | May 28, 2020
Enterprise IIS log analysis software: top tools, use cases, and NXLog Agent integration
17 minutes | May 7, 2026

Stay connected:

Featured posts

Announcing NXLog Platform 1.15
October 8, 2026
Announcing NXLog Platform 1.14
August 19, 2026
Announcing NXLog Platform 1.13
June 9, 2026
Enterprise IIS log analysis software: top tools, use cases, and NXLog Agent integration
May 7, 2026
Announcing NXLog Platform 1.12
April 21, 2026
How to visualize telemetry data flow and volume with NXLog Platform
March 23, 2026
Security dashboards go dark: why visibility isn't optional, even when your defenses keep running
February 26, 2026
Building a practical OpenTelemetry pipeline with NXLog Platform
February 25, 2026
Announcing NXLog Platform 1.11
February 23, 2026
Adopting OpenTelemetry without changing your applications
February 10, 2026
Linux security monitoring with NXLog Platform: Extracting key events for better monitoring
January 9, 2026
2025 and NXLog - a recap
December 18, 2025
Announcing NXLog Platform 1.10
December 11, 2025
Announcing NXLog Platform 1.9
October 22, 2025
Gaining valuable host performance metrics with NXLog Platform
September 30, 2025
Security Event Logs: Importance, best practices, and management
July 22, 2025
Enhancing security with Microsoft's Expanded Cloud Logs
June 10, 2025

Categories

  • ANNOUNCEMENT
  • COMPARISON
  • COMPLIANCE
  • DEPLOYMENT
  • SECURITY
  • SIEM
  • STRATEGY
  • Products
  • NXLog Platform
  • NXLog Agent
  • NXLog Community Edition
  • Integration
  • Professional Services
  • Licensing
  • Plans
  • Resources
  • Documentation
  • Blog
  • White Papers
  • Videos
  • Webinars
  • Case Studies
  • Community Program
  • Community Forum
  • Compare NXLog Platform
  • Partners
  • Find a Reseller
  • Partner Program
  • Partner Portal
  • About NXLog
  • Company
  • Careers
  • Support Portals
  • Contact Us

Follow us

LinkedIn Facebook YouTube Reddit
logo

© Copyright NXLog Ltd.

Privacy Policy • General Terms of Business