WinCollect deployment planning

Work with your Windows IT group and the QRadar® group to answer the following questions to plan your WinCollect deployment.

Which Windows endpoints do I need to collect data from?

  • What is the Windows Operating System?
  • Are these “high value” servers. High value servers typically generate high Events per Second (EPS) and have a higher importance (such as Domain Controllers or Web Servers).
  • Are you allowed to install a WinCollect Agent on this endpoint?
  • Will this endpoint require more configuration changes?
    • Point-of-sale (POS) devices are typically low EPS and rarely require updates.
    • A Domain Controller might require frequent configuration changes (for example, modify the event filter to configure which event IDs are collected).
Important: WinCollect is not supported on versions of Windows that have been moved to End Of Life by Microsoft. After software is beyond the Extended Support End Date, the product might still function as expected. However, IBM®® will not make code or vulnerability fixes to resolve WinCollect issues for older operating systems.

Where are these endpoints located?

  • Are the endpoints all in the same region, or are they distributed across geographies?
  • Are they in the same domain, child domains, or off the network?
  • What is their line of sight?
    • Which Console, Event Collector, or Event Processor do the endpoints have visibility to?

What data do I need to collect?

  • Which Event logs do you need to collect? Apart from the standard Windows logs (Application, System, Security), do you need data from applications and services logs such as Powershell or Sysmon? Application and services logs are collected by providing an XPath to the WinCollect Agent.
    • XPath queries are structured XML expressions that you use to retrieve customized events from the Windows event log.
  • In addition to event logs, identify any of the following logs you might want to collect:
    • IIS
    • IAS
    • ISA
    • DHCP
    • DNS Debug
    • Exchange
    • NetApp
    • Juniper SBR
    • File Forwarder (generic log file forwarder)
    Tip: These logs can be collected by a local Agent or a Remote agent.

How much will my EPS increase?

  • How much EPS will my endpoints generate?
  • How many Event Processors or Collectors will be required to handle this EPS?
    • How many events per second (EPS) are you licensed for?
    • How much EPS are the Event Processors and Collectors rated for?
  • What is the Average and Peak EPS generated by my endpoints?
    • It is important to estimate the Peak EPS for the endpoints. Your Event Collector might handle 40,000 EPS, but when employees log in at 8:00 AM, will this EPS spike to 80,000? And if so, for how long? Can your QRadar appliances handle these spikes, or do you need to spread out the load across 1 or more Event Collectors?
Tip: One option to control EPS is to throttle the agents to a certain EPS, so the Agent sends out only a specific number of events, regardless of what it collects. In this case, the Agent buffers the extra events to disk until the EPS rate decreases. Doing so limits the total EPS that might be sent to your Event Collector at any specific time. If you select this option, you need to understand the EPS rates that different endpoints generate. For example, you wouldn't want to throttle a Domain Controller to 2 EPS, as this server might send at a rate of 5-10 EPS. Then, the Agent would always be behind.
The following table provides estimates on the volume of EPS an endpoint might generate. These rates vary depending on several factors:
  • How many endpoints are communicating with the server (Domain Controller)
  • Level of Audit Logging configured
  • Applications that are installed and generating events
Table 1. Typical EPS rates for endpoints
Endpoint type Average EPS Peak EPS
Employee Endpoints Desktops & Laptops 0.005 0.05
Windows Domain Server 5 - 10 350
Web Servers (IIS, Apache) 5 - 10 350
Windows DNS Server 0.5 5
Database Server 0.5 10
Tip: It is best to get a sample of the EPS your endpoints are generating.

Do I install a managed or stand-alone configuration?

You can install WinCollect agents in an environment that is managed by QRadar, as a stand-alone agent, or a combination of both.

Managed

The WinCollect agent is managed by QRadar. Code updates and configuration changes are provided by the QRadar console to the agent installed on the Windows endpoint. This option requires TCP communication over port 8413 between the Windows endpoint and QRadar. Customers manage what data the agent will collect by adding log sources in the QRadar Console.

The agent also requires access to port 514 UDP or TCP to send the syslog data to QRadar. In smaller deployments that don't exceed the managed limitations, customers typically choose managed installation to maintain control of WinCollect code and configuration changes.

Current QRadar managed limitations
If you want to manage your WinCollect agents and associated log sources using QRadar, the recommended limit is 500 agents per console/managed host. For example, to install WinCollect on 1,200 endpoints in managed mode, divide the endpoints between the Console and Event Collectors/Processors.
  • 200 endpoints - Console
  • 500 endpoints - Event Processor/Collector 1
  • 500 endpoints - Event Processor/Collector 2

Stand-alone

In a stand-alone installation, the WinCollect agent is not managed by QRadar. The only communication the agent has with QRadar is via TCP/UDP over port 514. To upgrade these agents, you need to reinstall the agent or use the patch installer to update the code. Currently the patch installer is a separate installation provided by IBM that includes code updates and the WinCollect Configuration Console.

To make configuration changes, you need to either install the WinCollect Configuration Console GUI tool or make changes directly to the agents' configuration. For large deployments, customers typically chose stand-alone installations, so they can control the installation and configuration using BigFix or Microsoft System Center Configuration Manager.

Changes to the configuration can be made using templates which will allow you to make changes to the Agent-Config.xml without editing the file directory. For more information, see https://www.ibm.com/community/qradar/2019/03/14/wincollect-7-2-8-stand-alone-change-configuration-with-templates/.

Note: The WinCollect Configuration Console GUI requires .NET 3.5.

How do I want to collect the events?

Local collection

Maximum EPS supported: 5,000 EPS

The WinCollect agent is installed on the endpoint in either a managed or stand-alone configuration and collects Windows event logs from the local endpoint. You can use this collection method on Windows hosts that are busy or have limited resources, such as domain controllers. Domain controllers typically have a heavier event per second (EPS) rate than member servers.

You can also use local collection when you don't want to worry about managing credentials and adding or subtracting endpoints as they come online. You must install agents on the endpoints as they are added to their network either manually or by using a BigFix® or Microsoft System Center Configuration Manager (SCCM) solution. The agent can also be included in a base image so that an agent is up and running when a new endpoint is deployed.
Note: When WinCollect agents collect events from the local host, the event collection service uses the local system account credentials to collect and forward events.

Remote collection

Maximum EPS supported: 2,500 events total, across 500 remote endpoints

The WinCollect agent is installed on the endpoint in either managed or stand-alone configuration and collects Windows event logs from the local endpoint and one or more remote endpoints. For remote collection, you must provide login credentials for a user with remote event log access. WinCollect agents that remotely poll other Windows endpoints systems require access to following remote ports:
Table 2. Ports used for remote collection
Port Protocol Usage
135 TCP Microsoft Endpoint Mapper
137 UDP NetBIOS name service
138 UDP NetBIOS datagram service
139 TCP NetBIOS session service
445 TCP Microsoft Directory Services for file transfers that use Windows share
49152-65535 TCP Default dynamic port range for TCP/IP
Tip: Some windows servers might have a different default dynamic range set for TCP. To check the default range on your server, use the following command: 
netsh int ipv4 show dynamicport tcp
Note: The MSEVEN protocol uses port 445. You can use the NETBIOS ports (137 - 139) for host name resolution. When the WinCollect agent polls a remote event log by using MSEVEN6, the initial communication with the remote computer occurs on port 135 (dynamic port mapper), which assigns the connection to a dynamic port. The default port range for dynamic ports is between port 49152 and port 65535. To allow traffic on these dynamic ports, enable and allow the two following inbound rules on the Windows server that is being polled:
  • Remote Event Log Management (RPC)
  • Remote Event Log Management (RPC-EPMAP)
The MSEVEN6 protocol exposes RPC methods for reading events in both live and backup event logs on remote computers. This protocol was originally made available for Windows Vista and replaces the MSEVEN protocol.
Tuning considerations when remote polling
For information about tuning profiles for remote polling, see Log source event rates and tuning profiles.

Windows Event Forwarding (WEF)

The WinCollect agent can use the built-in Microsoft function Windows Event Forwarding (WEF). WEF reads any operational (i.e., security) or administrative (i.e., Sysmon) event log on a device in your organization and forwards the events that you choose to a Windows Event Collector (WEC) server. You can install the WinCollect agent on the WEC Server and collect from the forwarded event log. Before sending these forwarded events to QRadar, the agent packages them in such a manner so they appear as they are coming directly from each of the endpoints. QRadar Automatically creates log sources for each endpoint that is sending logs to the Windows Event Collector (WEC) server.
Tip: In WinCollect V7.2.9 and later, you can specify all events to be sent to a single log source.
Highlights of WEF:
  • Events can be pushed or pulled from the WEC Server
  • Can be configured via GPO
  • Uses Windows Remote Management (Kerberos) to prevent man in the middle
  • Recommended to target certain event logs and event IDs (use Xpath)
  • Events are collected to one central event log file (EVTX file) that WinCollect can poll
For more information about Windows Event Forwarding, see: