In previous sections of this guide, we explored how Windows IIS and SQL Server logging works. In this section, we’ll complement those concepts by diving into centralizing Windows logs. Specifically, we’ll cover:
- What Windows Event Collector is.
- How to configure a collector-initiated Windows Event Collector subscription to send logs from one Windows Server to another.
- How to centralize Windows logs with CrowdStrike Falcon® LogScale.
Windows Event Collector
The Windows Event Collector uses the Windows Remote Management (WinRM) protocol to enable centralized logging. In simple terms, Windows Event Collector provides a native Windows method for centralizing the types of logs you can capture in Windows Event Viewer locally.
Collectors aggregate event log records from one or more source computers based on event subscriptions. There are two types of subscriptions: source initiated and collector initiated. Source-initiated subscriptions are more scalable because you can configure them via a group policy without knowing the specific sources in advance. Event Collector supports plaintext HTTP and encrypted HTTPS for shipping logs from a source to a collector.
How to use Windows Event Collector to send logs to a collector
For our demo configuration, we’ll use two Windows Server 2019 Datacenter servers running in Azure to create a collector-initiated subscription.
Demo configuration is not production-ready. Note that we’re using HTTP to transmit logs in our demo configuration. This configuration isn’t hardened for production use. While our demo can help you get started with Windows Event Collector, it’s not recommended for production.
To follow along, you’ll need:
- Two Windows servers (a “collector” and a “source”) in the same domain. For our configuration, we’ll use two Windows Server 2019 Datacenter servers running in Azure. Most modern Windows Server operating systems with a graphical user interface (aka “Desktop Experience”) should work similarly.
- WinRM enabled. WinRM is enabled by default on modern Windows Servers (but not desktop operating systems). You can enable it with the
Configure the subscription on the collector
First, we’ll configure a subscription on the collector server.
1. Launch Windows Event Viewer on the collector server.
2. Click Subscriptions in the left menu.
3. If this is your first time working with subscriptions, Event Viewer will prompt you to start and/or configure the Windows Event Collector Service to automatically start. To proceed with the configuration, click Yes to answer the pop-up below.
You should then see a blank Subscriptions table.
4. Right-click on Subscriptions, then click Create Subscription…
5. In the Subscription Properties pop-up, give your subscription a Subscription name and Description (optional). Leave the Destination log set to Forwarded Events.
6. Ensure the Collector initiated radio button is selected and then click Select Computers…
7. In the Computers pop-up, use the Add Domain Computers… button to add the second server.
8. Click the Test button to test connectivity to the second server.
9. Click the Select Events… button to select events to forward to our subscription.
10. For our example, we’ll forward PowerShell logs. Make these selections to follow along:
- Check the Critical, Warning, Error, and Information boxes for Event Level.
- Select the By log radio button.
- Select Windows Powershell in the Event logs drop-down.
11. Then, click OK.
12. Click Advanced…
13. In the Advanced Subscription Settings pop-up, select the Specific User radio button and add a user and password for an account that can read event logs on the source machine. Then click OK.
Note: You can use the Machine Account option by adding the collector computer to the Event Log Reader role on the source computer. This option may be preferable in production environments.
14. With all our configurations made, click OK in the Subscription Properties pop-up.
You should see an Active subscription in the Subscriptions list with 1 source computer.
Configure Event Forwarding on the source server
With the subscription configured on the source server, we’ll make the corresponding Event Forwarding policy on the source server.
1. On the source server, launch Local Group Policy Editor (gpedit.msc) and navigate to Computer Configuration → Administrative Templates → Windows Components → Event Forwarding.
2. Right-click Configure target Subscription Manager and click Edit.
3. Click the Enabled radio button.
4. Click the Show… button next to SubscriptionManagers.
5. Add a value in this format to point to the collector server with a refresh rate of 60 seconds:
For example, if the fully qualified domain name (FQDN) of the collector server is
collector.local, then use:
Then click OK.
6. Click Apply, then click OK.
Test the subscription
With the configuration in place, we can begin to test the subscription. Note that logs can take up to 15 minutes to start forwarding to the collector. You can test the subscription by generating PowerShell application logs of information level or higher (e.g., by launching PowerShell on the source server) and then checking the Forwarded Events log in Event Viewer on the collector server.
Centralizing Windows logs using Falcon LogScale with open-source log shippers
Centralizing Windows logs with native tools is useful in some cases, but it isn’t ideal for every environment. For example, if you’re responsible for multiple machines running different operating systems, centralizing only your Windows logs doesn’t give you a central location for analyzing logs from other sources.
Shipping logs to a log management platform like CrowdStrike Falcon LogScale solves that problem. Windows administrators have two popular open-source options for shipping Windows logs to Falcon LogScale:
- Winlogbeat enables shipping of Windows Event logs to Logstash and Elasticsearch-based logging platforms. If you’d like to get started with Winlogbeat, check out Importing Logs from Winlogbeat into Falcon LogScale.
- Metricbeat is a lightweight metrics shipper that supports a variety of modules for metrics such as network stats, CPU usage, memory, and disk I/O. To get started with Metricbeat on Falcon LogScale, check out the LogScale Metricbeat log shipper documentation. Note that versions 8.1.0 and later of Metricbeat require
setup.ilm.enabled: false and output.elasticsearch.allow_older_versions: true to be set in the metricbeat.ymlconfiguration file.
These open-source log shippers, and a log management platform like Falcon LogScale, enable administrators to gain visibility into their Windows infrastructure without decentralizing their central logging from *nix-based systems.