- Free Edition
- What's New?
- Key Highlights
- Suggested Reading
- All Capabilities
-
Log Management
- Event Log Management
- Syslog Management
- Log Collection
- Agent-less Log Collection
- Agent Based Log collection
- Windows Log Analysis
- Event Log Auditing
- Remote Log Management
- Cloud Log Management
- Security Log Management
- Server Log Management
- Linux Auditing and Reporting
- Auditing Syslog Devices
- Windows Registry Auditing
- Privileged User Activity Auditing
-
Application Log Management
- Application Log Monitoring
- Web Server Auditing
- Database Activity Monitoring
- Database Auditing
- IIS Log Analyzer
- Apache Log Analyzer
- SQL Database Auditing
- VMware Log Analyzer
- Hyper V Event Log Auditing
- MySQL Log Analyzer
- DHCP Server Auditing
- Oracle Database Auditing
- SQL Database Auditing
- IIS FTP Log Analyzer
- IIS Web Log Analyzer
- IIS Viewer
- IIS Log Parser
- Apache Log Viewer
- Apache Log Parser
- Oracle Database Auditing
-
IT Compliance Auditing
- ISO 27001 Compliance
- HIPAA Compliance
- PCI DSS Compliance
- SOX Compliance
- GDPR Compliance
- FISMA Compliance Audit
- GLBA Compliance Audit
- CCPA Compliance Audit
- Cyber Essentials Compliance Audit
- GPG Compliance Audit
- ISLP Compliance Audit
- FERPA Compliance Audit
- NERC Compliance Audit Reports
- PDPA Compliance Audit reports
- CMMC Compliance Audit
- Reports for New Regulatory Compliance
- Customizing Compliance Reports
-
Security Monitoring
- Threat Intelligence
- STIX/TAXII Feed Processor
- Threat Whitelisting
- Real-Time Event Correlation
- Log Forensics
- Incident Management System
- Automated Incident Response
- Linux File Integrity Monitoring
- Detecting Threats in Windows
- External Threat Mitigation
- Malwarebytes Threat Reports
- FireEye Threat Intelligence
- Application Log Management
- Security Information and Event Management (SIEM)
- Real-Time Event Alerts
- Privileged User Activity Auditing
-
Network Device Monitoring
- Network Device Monitoring
- Router Log Auditing
- Switch Log Monitoring
- Firewall Log Analyzer
- Cisco Logs Analyzer
- VPN Log Analyzer
- IDS/IPS Log Monitoring
- Solaris Device Auditing
- Monitoring User Activity in Routers
- Monitoring Router Traffic
- Arista Switch Log Monitoring
- Firewall Traffic Monitoring
- Windows Firewall Auditing
- SonicWall Log Analyzer
- H3C Firewall Auditing
- Barracuda Device Auditing
- Palo Alto Networks Firewall Auditing
- Juniper Device Auditing
- Fortinet Device Auditing
- pfSense Firewall Log Analyzer
- NetScreen Log Analysis
- WatchGuard Traffic Monitoring
- Check Point Device Auditing
- Sophos Log Monitoring
- Huawei Device Monitoring
- HP Log Analysis
- F5 Logs Monitoring
- Fortinet Log Analyzer
- Endpoint Log Management
- System and User Monitoring Reports
-
Log Management
- Product Resources
- Related Products
- Log360 (On-Premise | Cloud) Comprehensive SIEM and UEBA
- ADManager Plus Active Directory Management & Reporting
- ADAudit Plus Real-time Active Directory Auditing and UBA
- ADSelfService Plus Identity security with MFA, SSO, and SSPR
- DataSecurity Plus File server auditing & data discovery
- Exchange Reporter Plus Exchange Server Auditing & Reporting
- M365 Manager Plus Microsoft 365 Management & Reporting Tool
- RecoveryManager Plus Enterprise backup and recovery tool
- SharePoint Manager Plus SharePoint Reporting and Auditing
- AD360 Integrated Identity & Access Management
- AD Free Tools Active Directory FREE Tools
What is a Windows log collector?
A Windows log collector is a tool that centralizes Windows event log data from local and remote machines into a single, queryable repository. Windows ships with two native mechanisms for this: Event Viewer's manual export, and Windows Event Collector (WEC), which pulls events from source hosts using WS-Management over WinRM.
EventLog Analyzer builds on the same Windows Event Forwarding architecture, adds parsing and normalization so raw XML events become searchable fields, correlates events across machines in real time, and archives everything for compliance. It also collects event logs from distributed Windows devices or syslog from distributed Linux and Unix devices, switches, and routers for cross correlating events. For a broader picture of every log source supported by EventLog Analyzer, refer to the log collection page.
Windows event logs: What gets collected and why it matters
Windows sorts its events into four core channels for efficient event log management. Each one exists for a distinct reason, and each one answers a different kind of question when something goes wrong.
Windows security logs
The Security channel is the audit channel. Authentication attempts such as event ID 4624 for successful logons, 4625 for failed ones, and 4634 for logoffs fall here for event log auditing. So do other critical events for compliance auditing, such as privilege use (4672), account creation and modification (4720, 4738), group membership changes (4728, 4732), object access (4663(S)), and any change to the audit policy itself (4719). EventLog Analyzer collects such entries of the security log, indexes each field for search, and feeds the same data into framework-specific templates for compliance reporting.
Windows system logs
The System channel is where the operating system reports driver failures, service crashes, unexpected shutdowns, hardware errors, disk I/O problems, time-sync failures with the domain controller, boot-time issues, kernel-mode faults, and Windows Update problems. For IT operations, the system log is usually the first place to look when a server is unstable. For security teams, system events such as an unexpected service crash on a domain controller or repeated driver failures on a specific host act as the first sign of something that the security log will confirm minutes later.
Windows application logs
The Application channel is where installed software-related events such as SQL Server log failed queries and backup completions, IIS report startup and shutdown, and antivirus scans and detections are covered. Third-party applications also default to this channel when they don't ship their own dedicated log file.
The signal-to-noise ratio in application logs varies among different environments and requires advanced filtering to drill down critical issues. EventLog Analyzer's event filters let you keep the application entries that matter for troubleshooting and drop the routine noise before it hits the archive.
Windows setup logs
The Setup channel records events tied to installing, updating, and removing Windows itself, including feature installs, servicing operations, Windows Update actions, and role or feature changes on Windows Server. EventLog Analyzer collects setup logs alongside the other three channels by default.
Windows Event Forwarding: How remote log collection works
Windows has a native architecture for shipping events off the machines that produce them. It's called Windows Event Forwarding (WEF). In EventLog Analyzer, much of the collection happens through the same mechanism.
WEF uses WS-Management over WinRM to push events from source computers to a designated Windows Event Collector (WEC) service on a collector host. Subscriptions define which events get forwarded, from which source computers, to which log on the collector. Two subscription models exist, and the choice between them is the single most important WEF design decision.
Source-initiated vs. collector-initiated subscriptions
In source-initiated subscriptions, endpoints reach out to the collector. Configuration is deployed by Group Policy—one policy applied to an OU, and every machine in the OU starts forwarding. This is the model that scales. Domains with thousands of machines run source-initiated subscriptions.
In collector-initiated subscriptions, the WEC server reaches out to each source. Every source has to be enumerated explicitly. This setup works for a lab of 10 machines and is unmanageable for anything larger; it's mainly useful for non-domain environments and small workgroups.
Configuring WinRM for event forwarding
On each source machine:
- Enable WinRM by running winrm quickconfig. This starts the WinRM service and opens the default listener.
- Configure the collector service on the receiving host with wecutil qc. This registers the machine as a Windows Event Collector.
- Verify with winrm id -r:<source> from the collector.
- Create a subscription (via wecutil cs subscription.xml or the Event Viewer UI).
- For domain-wide rollout, wrap the source-side steps in a GPO and apply to the target OU.
EventLog Analyzer acts as the receiving side of this architecture. Events forwarded from source machines land in EventLog Analyzer's indexer, get parsed into fields, and become searchable within seconds with none of the manual subscription WEF requires on its own.
Agentless log collection
For event log collection, EventLog Analyzer does not require a separate agent to be installed on each machine from which logs are collected. Rather, the agent that collects Windows event log and syslog messages is present as part of the EventLog Analyzer server itself. The collector server does the work of reaching out over WMI or RPC to read events from the source and pull them across the wire.
The trade-off is that the agentless method assumes the network cooperates. If firewalls close the ports or if there's a WAN link with latency and packet loss between the collector and source, agentless breaks down. That's when agent-based collection applies, and as both modes feed into the same central index, there are not dual console issues.
Frequently asked questions
For a single machine, open Event Viewer (press the Windows key + R, then enter eventvwr.msc), navigate to the log you need under Windows Logs, and export it to EVTX or CSV. That works for one-off forensic pulls.
For anything beyond a single machine, that approach doesn't scale. The two options are native Windows Event Forwarding (WEF)—configure WinRM on source hosts (winrm quickconfig), register a collector with wecutil qc, and create a subscription that defines what gets forwarded—or a log management platform like EventLog Analyzer, which handles the forwarding architecture, adds parsing and normalization, and archives the data for compliance. Most enterprises land on the platform approach because native WEF gets unwieldy past a few dozen hosts.
Log collection means gathering the event records that devices, applications, and services generate—like logon attempts, transactions, errors, configuration changes, and network connections—and moving them from wherever they were written into a central place where they can actually be used. Every server, firewall, database, and application writes logs by default; on its own, that data stays stuck on the machine that produced it and gets overwritten as space runs out. Log collection is what turns that scattered, ephemeral data into a searchable, retainable asset.
The built-in tool is Event Viewer. Press the Windows key + R, type eventvwr.msc, and hit Enter. The tree on the left splits into two branches worth knowing about:
- Windows Logs: The four traditional channels include Application, Security, System, and Setup. Most authentication, OS, and installed-software events live here.
- Applications and Services Logs: There are dozens of newer channels for specific components, including PowerShell, Task Scheduler, WMI-Activity, Windows Defender.
On disk, the underlying files live at C:\Windows\System32\winevt\Logs\ as EVTX files. You can copy them off to another machine and open them in Event Viewer there, which is useful for offline forensic work. For anything beyond a single machine, though, Event Viewer stops being practical—that's where a log collector comes in.
Yes. The Windows security event log is the audit log—every authentication attempt, privilege use, and policy change lands there when log auditing is enabled. Whether you can rely on it long-term is a different question; local security logs roll over quickly and can be cleared by an attacker with admin rights. That's why centralized collection matters.
Not without a good reason and a policy behind it. Clearing local event logs destroys forensic evidence, breaks compliance audit trails, and can itself be a sign of malicious activity—event 1102 (security log cleared) is one of the highest-priority alerts in most SOCs. If disk space on endpoints is the problem, the answer is off-box archival, not deletion. Centralized collection followed by retention policy is the accepted approach.
