The temptation on day one is to add all 200 devices and watch the graphs explode. Resist it. A log project succeeds in the order you add sources, and the right order follows one question: where does the evidence you actually need live?
Every log source you add costs attention, disk and, past the free limit, licence count. Adding them in the right order means the tool answers real questions in week one instead of drowning you in workstation noise. Domain controllers first, the firewall second, your important servers third, and everything else only when the first three are quiet and understood. Here is the reasoning, step by step.
Almost every investigation in a Windows network is really an identity question: which account, from which machine, at what time. Domain controllers hold those answers. Logon successes and failures, account lockouts, group changes and policy changes all land on the DCs first.
Two or three DCs also fit comfortably inside even the five-source free edition, which means you can prove the tool's value on the most important evidence before spending anything.
Your firewall is the only witness to everything entering and leaving: VPN logons from home, blocked connection attempts, and traffic to suspicious destinations. It speaks syslog, so point it at the server on port 514 and it starts reporting within minutes, with no agent and no credentials to manage.
With DCs and the firewall together, you can already answer the classic Monday-morning question end to end: the account logged in through the VPN at 11 PM, then reached the file server. That is a real investigation, from two sources.
Once identity and the border are covered, add the servers that hold things people care about: file servers, the accounting or ERP server, mail and database servers. These are where file access auditing and application logs turn the console from a logon tracker into a data story.
Remember the dependency: file access reports are empty until the server's audit policy is actually recording object access. Adding the source and enabling its auditing are one job, not two.
Workstation logs are genuinely useful for spotting a compromised PC, but they are the noisiest, most numerous and least centrally revealing sources you own. Adding 150 PCs on day one mostly buys you disk usage, alert noise and a licence conversation you were not ready for.
Start with a handful of high-risk or high-value workstations if you must, and expand only when the earlier layers are tuned. A small, working system beats a complete, ignored one every time.
Each layer gets a few days of watching before the next arrives. That pause is where you learn what normal looks like on your network, fix the chatty audit setting, and notice the source that silently stopped sending. Rollouts that skip the pause end with a console nobody trusts.
Write the order down and share it with whoever approved the project. When someone asks why their server is not in yet, a written plan with dates ends the argument better than a shrug.
The video shows the install and the device-adding screens. Use this order when you reach that step, and your first week will already be useful.
▶️ Watch Full VideoYou can, and many people do, but the usual result is noise, fast disk growth and alerts nobody has tuned yet. Adding in layers, identity first, means each new source lands in a console you already understand, and problems are spotted while they are still small.
Yes. A syslog device sending logs to EventLog Analyzer is a log source just like a Windows server, and it counts toward the free edition's five sources and toward licensed counts. That is another reason the firewall is worth adding early: it earns its slot.
Small networks often run one box as DC, file server and application host. Add it first anyway: you get identity, data and application evidence from a single source, and the firewall as source two completes the basic picture.