To forward Windows Server 2000, 2003, and 2008 event logs, run an agent on each server to read the events and send them over TLS to a relay or your SIEM. Windows 2000 and Server 2003 need a collector for the legacy Event Logging API, such as NXLog Agent’s Event Log for Windows XP/2000/2003 input module. Server 2008 and 2008 R2 need one for the newer Windows Event Log API, such as the Event Log for Windows input module. Our 32-bit NXLog Agent package covers x86 editions, while 64-bit hosts use the standard NXLog Agent package.
Teams that still run these legacy Windows versions usually have a reason: a process historian, a payment gateway, or a lab instrument that can’t be recertified on a newer OS. This guide covers log forwarding on Windows Server 2003, Windows 2000 Server (often searched as "Windows Server 2000"), and Windows Server 2008 and 2008 R2, without changing the host OS. For Windows XP hosts, see how to forward Windows XP event logs to Splunk, Elasticsearch, and IBM QRadar.
Windows 2000 Server lost extended support on 13 July 2010, and Windows Server 2003 on 14 July 2015. Server 2008 and 2008 R2 followed on 14 January 2020, and their Azure-only Extended Security Updates ended on 9 January 2024.
The August 2024 joint guidance from the Australian Cyber Security Centre, CISA, the FBI, the NSA, and partners, Best practices for event logging and threat detection, includes legacy IT assets among the log sources to prioritize. Our posts on legacy Windows blind spots and securing them in place cover the business case.
Why Windows Server 2000, 2003, and 2008 need different log pipelines
These Windows versions differ in ways that determine how you collect and forward their logs:
- The event log API
-
Microsoft built the Event Logging API for Windows XP, 2000, and Server 2003, then redesigned event logging for Vista and Server 2008. NXLog Agent has a module for each API: the Event Log for Windows XP/2000/2003 input module for the legacy one, and the Event Log for Windows input module for the newer one.
- The security event IDs
-
For most security events, the Server 2008 ID is the legacy ID plus 4096. For example, 624 (user account created) became 4720. Logon events don’t map one-to-one: Microsoft merged two success IDs and ten failure IDs into 4624 and 4625, respectively. A SIEM rule that only looks for 4624 won’t see a single logon from a Server 2003 host.
- TLS support
-
Microsoft’s Schannel table shows no TLS 1.2 in the original Server 2008 and TLS 1.2 off by default in 2008 SP2 and R2. KB4019276 adds it to 2008 SP2 with registry changes but doesn’t cover Server 2003. Our 32-bit NXLog Agent package bundles its own OpenSSL, so TLS 1.2 works on every OS it supports.
- Architecture
-
Windows Server 2003 shipped in x86, x64, and Itanium editions, but every edition of 2008 R2 is 64-bit.
The following table shows how these differences apply to each version.
| Version | NXLog Agent module | NXLog Agent package | TLS 1.2 in the OS | Native WEF source |
|---|---|---|---|---|
Windows 2000 Server |
Event Log for Windows XP/2000/2003 ( |
32-bit |
No |
No |
Windows Server 2003 and 2003 R2 |
Event Log for Windows XP/2000/2003 ( |
32-bit (x86 editions only) |
No |
SP1 or later, with WinRM |
Windows Server 2008 |
Event Log for Windows ( |
32-bit or 64-bit |
SP2, with KB4019276 |
Built in |
Windows Server 2008 R2 |
Event Log for Windows ( |
64-bit |
Off by default |
Built in |
Can Windows Server 2003 forward event logs without an agent?
Partly. Server 2003 SP1 and later can act as a Windows Event Forwarding (WEF) source, but Microsoft documents Vista, Server 2008, and later as collectors. Server 2003 first needs WinRM: Microsoft offers version 1.1 for SP1 and later (KB 936059) and 2.0 for SP2 (Windows Management Framework Core). Windows 2000 can be neither a source nor a collector.
NXLog Agent’s Windows Event Collector input module can replace the Windows collector on any supported platform, including Linux. For 2008 hosts where you can’t install an agent, the Event Log for Windows input module can collect remotely over MSRPC, but that doesn’t reach 2000 or 2003.
If you’re planning to implement WEF on Windows Server 2008, read our breakdown of WEC scaling limits first.
Forward legacy logs through a relay to your SIEM
Run a lightweight agent on each legacy host, send everything to a relay on a supported OS, and let the relay forward to your SIEM. From blind spot to monitored covers this type of deployment.
Since NXLog Agent 6.14, the 32-bit package ships through the standard channels and includes:
-
The NXLog Transport output module, which sends compressed event batches over an encrypted connection, keeps every field intact, resends any batch the relay doesn’t acknowledge, and fails over between relays.
-
The Remote Management module, so legacy agents can also enroll in NXLog Platform.
The joint guidance recommends a central logging facility that forwards processed logs to the SIEM, and TLS 1.3 for logs in transit. Keep the TLS 1.2 legacy hop short and segmented, and use TLS 1.3 from the relay onward.
Size relays for your measured peak, not the average. Microsoft’s event log guidance (citing KB957662) lists approximate maximum logging rates of 1,000 events per second for 32-bit Server 2003 and 2,000 for 32-bit Server 2008, and NXLog Platform tracks each agent’s throughput.
Before you install: audit policy and event log size
The agent can only forward what the host records and keeps, so check the host’s logging settings first.
- The event log is your first buffer
-
When the relay is unreachable and the output queue fills, flow control pauses the input and the event log holds the backlog. Events it overwrites before the relay returns are lost. On Server 2003, Microsoft puts the practical limit at about 300 MB for all event logs combined, domain controller logs included. A persistent log queue protects events the agent has already read, and our guide to offline buffering covers sizing.
- Audit policy on 2000 and 2003
-
In Local Security Policy or Group Policy, turn on auditing for logon events, account logon events, account management, policy change, privilege use, process tracking, and system events. If a category isn’t audited, the host never writes its events to the log.
- Audit policy on 2008 and 2008 R2
-
Server 2008 introduced audit subcategories, but only R2 added them to Group Policy. On Server 2008, enable these with
auditpol: Logon, Logoff, Special Logon, Process Creation, Security System Extension, User Account Management, Security Group Management, and Audit Policy Change. Also confirm that Audit: Force audit policy subcategory settings to override audit policy category settings is on, which is the default.> auditpol /set /subcategory:"Logon" /success:enable /failure:enable > auditpol /set /subcategory:"Process Creation" /success:enable
Configure the agent on Windows Server 2000 and 2003
This NXLog Agent configuration collects the three core logs and forwards events to two relays over TLS 1.2. Run it on the host itself: the Event Log for Windows XP/2000/2003 input module builds message text from the DLL and EXE files for each event source registered locally, so a local agent gets complete descriptions.
<Extension charconv>
Module xm_charconv
</Extension>
<Input eventlog>
Module im_mseventlog
Sources Security, System, Application (1)
UTF8 TRUE (2)
ReadFromLast FALSE
</Input>
<Output relay>
Module om_batchcompress
Host relay1.example.com:2514
Host relay2.example.com:2514
UseSSL TRUE
SSLProtocol TLSv1.2 (3)
CAFile %CERTDIR%\ca.pem
CertFile %CERTDIR%\agent.pem
CertKeyFile %CERTDIR%\agent.key
PersistLogqueue TRUE
LogqueueSize 67108864
</Output>
<Route legacy_to_relay>
Path eventlog => relay
</Route>| 1 | On domain controllers, add Directory Service, DNS Server, and File Replication Service to the list of sources. |
| 2 | Convert event text to UTF-8. This needs the Character Set Conversion extension module declared above. Without it, event text stays in the local codepage. |
| 3 | This line pins TLS 1.2. Our 32-bit package supports it on every OS. |
Windows 2000 Server uses the same API, module, and configuration. We list Windows 2000 (x86) among our supported 32-bit platforms. Without WinRM, an agent on the host is the only option.
Configure the agent on Windows Server 2008 and 2008 R2
On x86 Windows Server editions, install the 32-bit NXLog Agent package. This Event Log for Windows query collects only the Security events from the mapping table below, plus critical, error, and warning System events. Reuse the relay output and route from the Server 2003 configuration.
<Input eventlog>
Module im_msvistalog
ReadFromLast FALSE
<QueryXML>
<QueryList>
<Query Id="0">
<Select Path="Security">*[System[(EventID=4624 or EventID=4625 or EventID=4634 or EventID=4648 or EventID=4672 or EventID=4688 or EventID=4697 or EventID=4719 or EventID=4720 or EventID=4732 or EventID=4740 or EventID=1102)]]</Select>
<Select Path="System">*[System[(Level=1 or Level=2 or Level=3)]]</Select>
</Query>
</QueryList>
</QueryXML>
</Input>Events 4688 and 4697 only appear if their audit subcategories are on, and Windows rejects queries with more than 22 clauses, so split the query if you extend it.
Every 2008 R2 edition is 64-bit, so use the 64-bit NXLog Agent package with the same configuration. R2 also lets you manage audit subcategories from a GPO.
Send Windows Server 2003 event logs to a SIEM over TLS
Put the processing on the relay, which runs a supported OS. It tags each event with its schema, adds a normalized action name, and forwards RFC 5424 syslog over TLS to your SIEM. If your SIEM is Microsoft Sentinel, see Sentinel on legacy Windows for the Logs Ingestion API path.
Normalize legacy event IDs at the relay
Microsoft lists old and new IDs side by side in Appendix L: Events to Monitor. These pairs matter most for detection:
| Activity | Windows 2000 and 2003 | Windows Server 2008 and later |
|---|---|---|
Successful logon |
528, 540 |
4624 |
Failed logon |
529-537, 539 |
4625 |
Logoff |
538 |
4634 |
Logon with explicit credentials |
552 |
4648 |
Special privileges assigned |
576 |
4672 |
New process created |
592 |
4688 |
Service installed |
601 |
4697 |
Audit policy changed |
612 |
4719 |
User account created |
624 |
4720 |
Member added to local group |
636 |
4732 |
Account locked out |
644 |
4740 |
Audit log cleared |
517 |
1102 |
Don’t rewrite EventID to the new number.
Microsoft’s Eric Fitzgerald advised against automation built on old-to-new ID charts because the schemas differ.
Tag the schema and add a shared action name, so one SIEM rule matches logon-failure from any of these versions.
Configure the relay to send syslog to your SIEM
This relay runs the 64-bit NXLog Agent on Linux. Map the remaining pairs from the table the same way.
<Extension json>
Module xm_json
</Extension>
<Extension syslog>
Module xm_syslog
</Extension>
<Input legacy_agents>
Module im_batchcompress
ListenAddr 0.0.0.0:2514
CAFile %CERTDIR%/ca.pem (1)
CertFile %CERTDIR%/relay.pem
CertKeyFile %CERTDIR%/relay.key
TLSConnectLog TRUE
<Exec>
if defined $FileName { $EventSchema = 'legacy'; $LogName = $FileName; } (2)
else { $EventSchema = 'modern'; $LogName = $Channel; }
if $LogName == 'Security'
{
if $EventID IN (528, 540, 4624) $EventAction = 'logon-success';
else if $EventID IN (529, 530, 531, 532, 533, 534, 535, 536, 537, 539, 4625) $EventAction = 'logon-failure';
else if $EventID IN (592, 4688) $EventAction = 'process-created';
else if $EventID IN (517, 1102) $EventAction = 'audit-log-cleared';
}
</Exec>
</Input>
<Output siem>
Module om_ssl
Host siem.example.com:6514
SSLProtocol TLSv1.3 (3)
CAFile %CERTDIR%/siem-ca.pem
CertFile %CERTDIR%/relay.pem
CertKeyFile %CERTDIR%/relay.key
OutputType Syslog_TLS
<Exec>
$Message = to_json();
to_syslog_ietf();
</Exec>
</Output>
<Route legacy_to_siem>
Path legacy_agents => siem
</Route>| 1 | The listener requires a client certificate by default and rejects untrusted ones, so every agent needs a certificate signed by your CA. |
| 2 | The Event Log for Windows XP/2000/2003 module sets $FileName, and the Event Log for Windows module sets $Channel. |
| 3 | If your SIEM can’t negotiate TLS 1.3, add TLSv1.2 to SSLProtocol. |
For JSON over TLS, set Exec to to_json() and drop OutputType.
Syslog extension module can also write Snare format, and the OpenTelemetry Exporter output module sends OpenTelemetry.
Verify the pipeline and manage agents in NXLog Platform
Test the full path once per OS version: an event on the host, TLS on the legacy hop, and normalized fields at the SIEM.
> msiexec /q /i nxlog-6.14.10493_windows_i686.msi NXP_ADDRESS="agents.example.com:5515" NXP_AGENT_LABEL="legacy-2003"
> eventcreate /t WARNING /id 999 /l APPLICATION /d "NXLog pipeline test"The command line arguments enroll the agent in NXLog Platform. The filename is current as of October 2026.
On Windows Server 2003, eventcreate writes only to the Application or System log, so test Security separately.
Fail a logon with a wrong password and look for event 529 (Windows Server 2000 and 2003) or 4625 (Windows Server 2008) at your SIEM, with EventAction set to logon-failure.
The relay’s log shows each agent’s TLS version, so expect TLSv1.2 from legacy hosts.
If nothing arrives, check C:\Program Files\nxlog\data\nxlog.log, and run sc control nxlog 201 to switch the agent to debug logging until the service restarts.
Enrolled agents appear in NXLog Platform, where you can push configuration changes and watch throughput.
What this setup doesn’t fix
None of these servers have received public security updates since January 2020, and logging doesn’t change that. At the very least, put them on their own network segment, and use firewall rules to allow only the traffic they need.
The agent also has its own limits. Our 32-bit package bundles older OpenSSL builds where newer ones won’t run, with best-effort CVE coverage for OpenSSL 1.0.2 and 1.1.1. The OpenSSL project stopped public fixes for 1.1.1 on 11 September 2023, and the package gets updates at most twice a year.
Let the agent reach only the relay and NXLog Platform. Then use what the logs show about each server’s connections and logons to plan its migration or isolation.
Manage your legacy hosts with NXLog Platform
With an agent on each host and a relay that does the processing, Windows Server 2000, 2003, and 2008 feed the same SIEM as the rest of your fleet. Want to see how NXLog Platform manages agents and relays? Start your free trial.
FAQ
- Does Windows Server 2003 support syslog?
-
Not natively. It writes to the Windows Event Log through the Event Logging API. An agent such as NXLog Agent reads the log and can send each record as a syslog message.
- Can Windows Server 2003 send logs over TLS 1.2?
-
Not through the OS. Microsoft’s TLS 1.2 update (KB4019276) covers Server 2008 SP2, not Server 2003. An agent with its own TLS library can, and our 32-bit package bundles OpenSSL for TLS 1.2.
- Can I convert Windows Server 2003 event IDs by adding 4096?
-
Only as a lookup aid. It works for most pairs, such as 624 to 4720. However, it fails for some logon IDs: 540 (successful logon) maps to 4624, and 530-537 and 539 (failed logons) map to 4625. It also fails for 612 (audit policy changed), which maps to 4719, and for 517 (audit log cleared), which maps to 1102.
