Both methods feed the same console and the same reports. The difference is what happens on the bad days: the closed firewall port, the branch office link that drops every evening, the laptop that goes home. Choose per device, not per habit.
EventLog Analyzer offers two ways to collect Windows logs. Agentless means the server reaches out and pulls events over WMI and RPC. Agent based means a small agent on each machine collects locally and pushes to the server. Vendor pages present both cheerfully; this page gives you the honest trade-offs so each device gets the method that will still be working in six months.
In agentless mode there is no software on the target machine at all. The collector built into the EventLog Analyzer server connects to each Windows device on a schedule, reads its event logs over WMI, and pulls them back. Setup is fast: add the device, give valid credentials, done.
The price is network cooperation. WMI and RPC need ports 135, 445 and 139 reachable, plus the dynamic RPC range, and the Windows Firewall on many machines blocks exactly those by default. On a tidy single-site LAN with a domain service account, agentless works well and stays the low-maintenance choice.
Put a firewall with tight rules between server and source, or a WAN link to a branch office with latency and packet loss, and agentless collection starts missing: polls time out, logs arrive in bursts, and gaps appear that look exactly like a quiet machine. The tool is not lying to you; the road is just bad.
Agentless also means the server does all the work for every device, so very large fleets concentrate load and credentials in one place. None of this makes it a bad method; it makes it a LAN method.
The agent sits on the device, reads its own logs locally, and forwards them to the server. Because collection is local, it does not care about inbound WMI ports on the device, and it can ride out short network interruptions instead of losing that window of events.
The costs are real too: something must be deployed, updated and occasionally troubleshooted on every machine, and a broken agent fails silently unless you watch the console's last-received times. Agent based is more moving parts in exchange for more resilience.
Firewalls, routers, switches and most Linux servers do not run the Windows agent at all. They send syslog to the server's listener on port 513 or 514, or the server fetches their logs by other supported means. For network devices the agent question never arises; the only discipline is making sure their syslog destination and your listener ports agree.
This is also why syslog sources are often the most reliable in the whole console: the device pushes, on a simple well-understood protocol, and either it arrives or the silence itself is the alarm.
Mixed estates are normal and supported; both methods feed one index, so reports and searches never care which road a log travelled.
See the device-adding flow in the full video, then use this page to decide the collection method for each machine you add.
▶️ Watch Full VideoIt is different, not simply worse. Agentless needs a service account with rights on every target and WMI/RPC ports open between server and devices. Agents avoid inbound management ports on devices but add software to trust and maintain. In a well-run domain, both are accepted practice; the network layout usually decides.
Yes. Devices are configured individually, and both methods feed the same index, reports and alerts. Many networks run agentless on the main LAN and agents only at branch offices or on critical servers.
Usually the Windows Firewall on the device, a network firewall closing the dynamic RPC range, or the WMI service on the target. Test from the server side, fix the specific blockage, and if the link itself is unreliable, that device is an agent candidate.