Build a Targeted Windows Event Log Collector with PowerShell

Expected Outcome

A script queries explicit channels/Event IDs/time windows, writes normalized evidence, tracks the last successful collection boundary, and proves that scheduled reruns neither miss nor endlessly duplicate a seeded test event.

Assumptions

• Windows endpoint/server with read permission to the selected event channels

• An explicit operational question and small Event ID/channel set

• A local or protected UNC output path available to the scheduled-task identity

• A defined retention policy for generated evidence

Bill of Materials

• Windows operating system (Windows 10 or later)

• PowerShell (version 5.1 or later)

• Folder for log storage (e.g., C:\Logs)

• Folder for script storage (e.g., C:\Scripts)

Build Steps

1. Define the question and event scope

   Choose a narrow use case such as service failures, logon failures, or Windows Update events. Record channels, Event IDs/providers, target hosts, and lookback/bookmark behavior. Do not collect all logs merely because Get-WinEvent can.

2. Write one complete parameterized collector

   Use Get-WinEvent with FilterHashtable or a precise filter, normalize TimeCreated, MachineName, LogName, ProviderName, Id, Level, RecordId, and Message, and handle access/query failures explicitly.

3. Track an incremental boundary

   Store the last successful collection timestamp/record boundary separately from output. Use an overlap window if needed, then deduplicate by stable fields such as machine/log/record ID rather than silently dropping events.

4. Seed or identify a known event

   Generate a harmless known event where possible or select a specific existing event record, run the collector, and confirm the exact record appears with the expected fields.

5. Schedule under the real execution identity

   Use an absolute script/output path and the account that will run production collection. Confirm network paths, event-log rights, and PowerShell edition in that context.

6. Run twice and inspect duplicates/gaps

   Execute the scheduled collector twice across a known test event window. Prove the incremental logic includes new events without multiplying unchanged prior rows beyond the documented overlap behavior.

Validation

• Collector targets named logs/Event IDs/providers rather than every event

• A known event is present in output with correct machine/time/record ID

• Second run handles overlap/deduplication as designed

• Scheduled task produces the same schema as interactive execution

• Access/query errors appear as collection failures, not empty healthy results

• Generated CSV/JSON is described as evidence collection, not a SIEM/log-retention replacement

Troubleshooting

• No events: validate filter against Get-WinEvent interactively before changing scheduling

• Scheduled only fails: compare identity, rights, working directory, UNC authentication, and PowerShell edition

• Duplicates: inspect record ID/time boundary logic rather than shrinking the window blindly

Cleanup or Rollback

• Remove the lab scheduled task and disposable output if no longer needed

• Keep the final script/filter definitions under version control

Next Improvements

• Implement alerting mechanisms based on log contents using PowerShell or third-party tools.

• Integrate with a SIEM solution for centralized log management and analysis.

• Regularly review and update the PowerShell script to include additional logs as needed.