Windows Datasets

Windows datasets define collection rules for Windows devices (dataset type windows). Most collector types, including file log collection, are configured through the dataset creation wizard — see Management; the connection event and script execution collectors below are configured via device YAML. For the dataset and profile model, see Overview.

Collector Types

• Windows Security Events (windows_security_log_collector): Event category selector with four modes — ALL, MINIMAL, COMMON, or CUSTOM. Custom mode opens an XML editor for XPath filter expressions.
• Windows Event Logs (windows_event_log_collector): Basic mode selects predefined channels (Application, System) with severity level filters. Custom mode provides an XPath expression editor with optional DCR config import.
• Data Collection Rule Collector (data_collection_rule_collector): Custom-only XPath editor for Data Collection Rule queries. Supports importing DCR configuration that is automatically converted to XPath format.
• Windows Firewall Logs (windows_firewall_log_collector): Profile selection for firewall log collection — Domain, Private, and/or Public.
• Windows DNS Logs (windows_dns_log_collector): Include/exclude filter system with configurable conditions for DNS query fields (event ID, response code, question type, IP addresses, question name).
• Windows TCP Connections (windows_tcp_connection_collector): Established TCP connections with process attribution and destination geolocation.
• Windows Remote Connections (windows_remote_connection_collector): Remote login sessions (RDP, WinRM/WSMan, and console) correlated to network endpoints.
• Windows Script Execution (windows_execute_collector): Runs a script or executable and collects its standard output as log events.
• Windows Metrics (windows_metrics_collector): The host's performance counters, read on an interval — CPU, memory, the page file, disks, network interfaces, RDMA adapters, and the busiest processes — as ECS metric documents.
• Windows SCVMM Host Groups, Host Clusters, Hosts and Clouds (windows_scvmm_<model>_collector): What a System Center Virtual Machine Manager server manages, read from the VMM database on the VMM server. See Windows SCVMM Inventory.
• Windows Certificates (windows_certificate_collector): The certificates in a machine's, a service's or a user's stores, and in keystores, read on an interval as an inventory, each marked added, changed, unchanged or removed. See Windows Certificates.
• windows_wireguard_interface_collector: The WireGuard tunnels on the host, read on an interval as ECS metric documents. See Windows WireGuard.
• windows_wireguard_peer_collector: The peers of the host's WireGuard tunnels — endpoint, last handshake, and bytes received and sent — read on an interval as ECS metric documents. See Windows WireGuard.

Advanced Dataset Types

The backend supports additional dataset types that are not exposed in the UI: windows_main_log_collector, windows_system_log_collector, windows_application_log_collector, windows_object_access_log_collector, and windows_security_threat_analyzer. These are used internally and may appear in API responses or configuration exports.

Connection Event Collectors

The TCP connection (windows_tcp_connection_collector) and remote connection (windows_remote_connection_collector) collectors capture host network activity as ECS events. The TCP collector reports established TCP connections with process attribution and destination geolocation. The remote connection collector reports remote login sessions — RDP, WinRM/WSMan, and local console — enumerated from live host sessions and correlated against the current TCP snapshot. Both accept only a pipeline_name property for routing; collection cadence, connection caching, and country-level geolocation are handled automatically.

note

These collectors are configured via device YAML files under config/devices/ — they are not available in the dataset creation wizard.

Enabling TCP and remote connection collection on a Windows device, routing both to a pipeline...	devices: - id: 123458 name: windows-host type: windows status: true definitions: - name: windows_tcp_connection_collector status: true properties: pipeline_name: my-pipeline - name: windows_remote_connection_collector status: true properties: pipeline_name: my-pipeline
Each established TCP connection is emitted as an ECS event with process and destination geo...	{ "@timestamp": "2026-07-24T10:15:03.472Z", "event": { "kind": "event", "dataset": "windows.tcp_connection", "category": ["network"], "type": ["connection", "start"], "action": "established" }, "host": { "name": "windows-host", "ip_address": "10.0.0.20", "os": { "type": "windows", "version": "10.0.20348" } }, "network": { "transport": "tcp", "type": "ipv4" }, "source": { "ip": "10.0.0.20", "port": 51022 }, "destination": { "ip": "13.107.42.14", "port": 443, "geo": { "country_iso_code": "US", "country_name": "United States" } }, "process": { "name": "svchost.exe", "pid": 1284 }, "winlog": { "event_data": { "State": "established" } } }
A remote login session is emitted with the authenticated user, session type, and session metadata...	{ "@timestamp": "2026-07-24T10:12:55.000Z", "event": { "kind": "event", "dataset": "windows.remote_connection", "category": ["authentication", "session"], "type": ["start"], "action": "RDP" }, "host": { "name": "windows-host", "ip_address": "10.0.0.20", "os": { "type": "windows", "version": "10.0.20348" } }, "network": { "transport": "tcp" }, "user": { "name": "admin" }, "source": { "ip": "10.0.0.5", "geo": { "country_iso_code": "US", "country_name": "United States" } }, "destination": { "ip": "10.0.0.20", "port": 3389 }, "winlog": { "event_data": { "SessionID": 2, "SessionName": "admin@10.0.0.5", "SessionType": "RDP", "State": "Active" } } }

Script Execution

The windows_execute_collector runs a script or executable on the Windows host and collects its standard output as log events. Each execution is defined as an input with its own interpreter, arguments, schedule, and pipeline routing, so a single dataset can run multiple scripts.

note

This collector is configured via device YAML files under config/devices/. Scripts must be placed in the agent's user\scripts (operator-owned, survives upgrades) or package\scripts (product-shipped) directory; the path property is a file name only.

Input properties

Each entry under inputs: defines one script execution. Inputs share the standard dataset input frame (id, name, status) plus the following properties:

Field	Required	Type	Default	Description
path	Y	string	—	Script or executable file name (not a path). Resolved under the agent's scripts directories. Absolute paths and .. traversal are rejected.
interpreter	N	string	—	Interpreter that runs the script. Linux: sh, bash, or exe. Windows: ps1, cmd, or exe. exe runs path directly. There is no implicit default; if unset (or unrecognized), shell is used instead.
shell	N	string	—	Custom interpreter for the fall-through case (e.g. python3 or an executable path). On Windows with interpreter: ps1, selects the PowerShell edition: pwsh (7+), powershell (5.1), or unset (auto).
args	N	list	—	Arguments passed to the script or executable.
environment	N	map	—	KEY: VALUE pairs appended to the inherited process environment.
working_directory	N	string	inherit	Working directory for the child process.
timeout	N	int	120	Maximum run time in seconds. A non-positive value falls back to 120. On timeout, the entire child process group is terminated.
max_bytes	N	int	0	Cap on captured output in bytes. 0 means unbounded.
emit_on_error	N	boolean	false	When true, a non-zero exit code still emits the captured stdout. A timeout or a failure to start never emits, regardless of this setting.
execution_policy_bypass	N	boolean	false	Windows ps1 only. Adds -ExecutionPolicy Bypass to the PowerShell invocation.
cron	N	string	—	Per-input schedule (cron expression). An empty value or "0" runs the script on every collection cycle.
max_retries	N	int	1	Number of times a failed run is retried on subsequent collection cycles.
skippable	N	boolean	true	When true, missed schedule slots collapse into a single run. When false, each missed slot is replayed.
pipeline_name	N	string	—	Route the output to a specific preprocessing pipeline by name.
ignore_time	N	boolean	true	Skip time-based filtering on the emitted events.

Output

Captured stdout is converted to log events one line at a time:

• Trailing line terminators are trimmed once; if nothing remains, no events are emitted (an empty or whitespace-only run produces nothing).
• The remaining output is split on newlines, producing one event per line. A trailing carriage return on each line is stripped, so CRLF output is handled.
• Interior blank lines are preserved; only trailing blank lines from a final newline are dropped.
• stderr is never emitted as events. The exit code is logged and gates emit_on_error.

Example

Running a PowerShell health-check script every five minutes, bypassing the execution policy, and routing its output to a pipeline...	devices: - id: 123459 name: windows-host type: windows status: true definitions: - name: windows_execute_collector status: true inputs: - id: 4001 name: Service Health status: true properties: path: service-health.ps1 interpreter: ps1 execution_policy_bypass: true cron: "*/5 * * * *" timeout: 30 pipeline_name: my-pipeline
Each line of standard output becomes a separate log event...	{ "message": "Spooler Running" } { "message": "W32Time Running" }

File Log Collection

The windows_file_log_collector collects lines from arbitrary log files on Windows hosts. It supports glob path expansion, lookback-based backfill, multiline parsing, include/exclude filtering, character-set decoding, and per-pipeline routing. The path syntax uses Windows-style paths (e.g. C:\Logs\*\app-*.log).

note

File log datasets can be created through the dataset creation wizard (Windows File Logs) or configured via device YAML files under config/devices/ using the schema below.

Device-level property

Field	Required	Type	Default	Description
file_log_concurrency	N	int	8	Maximum number of inputs processed in parallel per device. A zero or negative value resolves to 8.

Input properties

Each entry under inputs: defines one file log source. Inputs share the standard dataset input frame (id, name, status) plus the following properties:

Field	Required	Type	Default	Description
path	Y	string	—	File path or glob pattern. Supports wildcards (e.g. /var/log/myapp/*.log, C:\Logs\*\app-*.log).
start_date	N	int	300	Lookback window in seconds: only files modified within this window are read. A negative value (e.g. -1) disables time-based filtering. 0 is not a way to narrow the window — it resolves to the 300 default.
ignore_cache	N	boolean	false	Skip the persisted file-position cache (re-read from the start).
ignore_old_date	N	boolean	false	Skip old-date filtering.
ignore_retention	N	boolean	false	Skip retention filtering.
ignore_time	N	boolean	false	Skip time-based filtering.
date_format	N	string	—	Custom timestamp layout using Java-style tokens (e.g. yyyy-MM-dd HH:mm:ss). Used to extract an event timestamp from each line.
line_parser	N	object | string	—	Multiline detection rules. See Line parser.
filter_mode	N	string	exclude	include or exclude. Synonyms: inclusive/allow (include), exclusive/deny (exclude).
filter_rules	N	array	—	Include/exclude rules. See Filter rules. Alias: filters.
encoding	N	string | int	—	Character encoding for the file. Accepts an alias (e.g. utf-8, windows-1252) or a numeric decoder ID. See Encoding aliases.
pipeline_name	N	string	—	Route matched lines to a specific preprocessing pipeline by name.

Line parser

line_parser controls how multi-line log entries are reassembled. It accepts either an object or a bare string shorthand.

Accepted type values:

Value	Aliases	Behavior
regex	1	A regex pattern detects where a new entry begins.
newline	new_line, 2	Each raw line is a separate entry.
string	prefix, 3	Lines beginning with a literal string mark a new entry.

Object fields:

Field	Required	Type	Description
type	N	string | int	One of the values above. If omitted and regex is set, regex is assumed.
regex	N	string	Pattern used by regex, or the literal prefix used by string/prefix. Compiled with Go's RE2 engine, which does not support lookarounds or backreferences.
value	N	string	Alias for regex.
date_based	N	boolean	Merge continuation lines using date boundaries detected via date_format.
has_space	N	boolean	Treat leading whitespace on a line as a continuation of the previous entry.

A bare string at line_parser: is treated as type: regex with that pattern:

line_parser: '^\d{4}-\d{2}-\d{2}'

Filter rules

filter_rules is an array of include/exclude rules applied to the content of each record, after line parsing. The effect of each match (keep or drop) is determined by filter_mode. These rules select content; the files themselves are selected by path.

Each rule accepts:

Field	Required	Type	Description
type	N	string | int	regex (1) or string (2). If omitted, inferred from which field is set.
regex	N	string	Regex pattern matched against the record. Compiled with a .NET-compatible engine, so lookarounds and backreferences are available — unlike line_parser.regex, which uses RE2.
source	N	string	Literal text matched against the record, with optional leading and trailing wildcards. Not a file path — use path to select files.
value	N	string	Alias for source.

A bare array of regex strings is also accepted and is equivalent to type: regex for each entry.

A string rule matches its text literally: regex metacharacters carry no special meaning, so *[error]* looks for the six characters [error] rather than a character class. Wildcards are positional and only recognized at the ends:

source	Matches a record that
*text*	contains text
text*	starts with text
*text	ends with text
text	contains text

An interior * is matched as a literal asterisk and reported in the Console Logs — use type: regex for pattern matching. A source that is empty once its wildcards are removed matches nothing.

A rule the reader cannot use — an invalid regex, or a string rule with an empty literal — is reported and then discounted. When no rule in the set is usable, filtering is inactive and no record is dropped, including under filter_mode: include.

Encoding aliases

encoding accepts a numeric decoder ID or one of the following aliases. Dashes, underscores, dots, and spaces are ignored during alias lookup, so utf-8, utf_8, and UTF 8 all resolve identically.

Alias(es)	ID
utf8	1
utf8bom	2
utf16be	3
utf16le	4
utf16bebom	5
utf16lebom	6
gbk	11
latin1, iso88591	15
windows1250, cp1250	50
windows1251, cp1251	51
windows1252, cp1252	52
windows1256, cp1256	56

The EBCDIC code pages (IDs 40--42) end lines with NEL (0x15), not LF, so they are not split into lines correctly. No alias maps to them.

Upgrading

Earlier versions accepted encoding but did not apply it to plain-text log files, which were read as raw bytes. A UTF-16 or code-page source therefore arrived garbled. If you compensated downstream, for example with a processor that strips NUL bytes or re-encodes the text, remove that workaround when you upgrade. The file is now decoded correctly, and the workaround will corrupt the correctly decoded text.

Example

Collecting IIS access logs on Windows with Western European encoding, rolling over daily log files by glob...

devices: - id: 123456 name: iis-windows type: windows status: true properties: file_log_concurrency: 1 definitions: - name: windows_file_log_collector status: true inputs: - id: 2001 name: IIS Logs status: true properties: path: C:\inetpub\logs\LogFiles\W3SVC1\*.log start_date: 300 line_parser: type: regex regex: '^\d{4}-\d{2}-\d{2}' encoding: windows-1252 pipeline_name: my-pipeline

Windows Metrics

The windows_metrics_collector reads the host's performance counters on the agent at a fixed interval: CPU, memory, the page file, disks, network interfaces, RDMA adapters, and the busiest processes. The counters are found by their index rather than their name, so they read the same on a Windows host in any display language.

note

Windows Metrics datasets can be created through the dataset creation wizard (Windows Metrics, under the Windows category) or configured via device YAML files under config/devices/.

Wizard fields

The Dataset configuration step asks for:

Field	Required	Behavior
Interval (seconds)	N	Leave empty to read every 60 seconds. At least 10.
Parts to read	Y	At least one part must be ticked. All eight are ticked by default, and with every part ticked, all of them are read.
Pre-processing pipeline	N	The pipeline the dataset's records enter, as on every dataset.

The wizard writes interval only when one is entered, and items only when a part is left out. An untouched dataset therefore follows the agent's defaults.

Properties

Field	Required	Type	Default	Description
interval	N	int	60	Seconds between readings. At least 10. A restart or a failover keeps the schedule: the next reading is due one interval after the last.
items	N	string[]	every part	The parts to read, as listed below.
pipeline_name	N	string	—	Route the dataset's records to a specific preprocessing pipeline by name.

Part	Console label	One document per
cpu	CPU usage	reading
memory	Memory usage	reading
swap	Page file usage	reading
filesystem	File system usage	logical disk
diskio	Disk I/O	physical disk
network	Network traffic	network interface
rdma	RDMA traffic	RDMA adapter
processes	Busiest processes	busy process

The busiest processes are the 25 that use the most CPU and the 25 with the most private memory. A host without RDMA adapters writes no RDMA document.

Output

Each reading writes ECS metric documents with event.dataset set to windows.<part> — for example windows.cpu or windows.diskio.

Example

Reading CPU, memory, and disk I/O every 30 seconds, leaving the other parts out...

devices: - id: 123462 name: windows-host type: windows status: true definitions: - name: windows_metrics_collector status: true properties: interval: 30 items: - cpu - memory - diskio pipeline_name: my-pipeline

Windows SCVMM Inventory

Four datasets read what a System Center Virtual Machine Manager (VMM) server manages, one dataset per kind of object. They run on the Windows agent of the VMM server and read the VMM database. Nothing they find is registered as a device: VMM's hosts and clusters are records of these datasets. The integration they replace registered them as devices.

note

SCVMM datasets can be created through the dataset creation wizard, under the Windows category, or configured via device YAML files under config/devices/.

Dataset	Collector	event.dataset	One record per
Windows SCVMM Host Groups	windows_scvmm_host_group_collector	windows.scvmm.host_group	host group, with its path from All Hosts
Windows SCVMM Host Clusters	windows_scvmm_cluster_collector	windows.scvmm.cluster	host cluster
Windows SCVMM Hosts	windows_scvmm_host_collector	windows.scvmm.host	virtualization host
Windows SCVMM Clouds	windows_scvmm_cloud_collector	windows.scvmm.cloud	private cloud

Wizard fields

The Dataset configuration step asks for:

Field	Required	Behavior
Interval (seconds)	N	Leave empty to read every 3600 seconds. At least 10.
Pre-processing pipeline	N	The pipeline the dataset's records enter, as on every dataset.

Properties

Field	Required	Type	Default	Description
interval	N	int	3600	Seconds between readings. At least 10. A restart or a failover resumes from the dataset's last reading.
pipeline_name	N	string	—	Route the dataset's records to a specific preprocessing pipeline by name.

Where they read

The datasets read the VMM database, using the connection string VMM keeps in its registry, under HKLM\Software\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings\Sql.

On a highly available VMM, assign the datasets to every node. Only the node where SCVMMService is running reads, so a failover moves the reading with it. The other nodes write nothing.

A server without VMM reads nothing. This is not an error: the agent says so once in its log, as a warning.

Database access

The agent signs in with Windows authentication, as the account its service runs as. That is LocalSystem by default:

• A SQL Server on another host sees LocalSystem as the VMM server's computer account, for example DOMAIN\VMM01$. On a highly available VMM, each node signs in with its own computer account.
• A SQL Server on the VMM server itself sees LocalSystem as NT AUTHORITY\SYSTEM.

That login needs SELECT on four tables: dbo.tbl_BTBS_HostGroup, dbo.tbl_ADHC_HostCluster, dbo.tbl_ADHC_Host and dbo.tbl_Cloud_Cloud. Granting SELECT on those four tables alone is the least privilege. The db_datareader role also grants it, but it can read every table and view in the VMM database.

Output

Each reading writes ECS inventory documents with event.kind set to state, one per object, and the VMM server that read them as host. Objects are identified by their VMM ids. From a dataset's second reading on, event.action marks each object added, changed or unchanged. An object that has gone since the last reading is written once more, marked removed.

Example

Reading VMM's hosts and host clusters every 30 minutes, routing both to a pipeline...

devices: - id: 123463 name: vmm01 type: windows status: true definitions: - name: windows_scvmm_host_collector status: true properties: interval: 1800 pipeline_name: my-pipeline - name: windows_scvmm_cluster_collector status: true properties: interval: 1800 pipeline_name: my-pipeline

Windows Certificates

The windows_certificate_collector reads the certificates in the certificate stores — the local machine's, and a service's or a user's it names — and in the keystores it names, on the agent, as an inventory: one record per certificate and store, or certificate and keystore file. The certificate a service presents over the network is in every result of a TLS Check and an HTTP Check instead, under tls.server.x509.*, with the certificate of its chain that expires first.

Two things go unseen without it:

• A server certificate expiring on a host no check reaches. It is a record whose days_left runs low.
• A root added to the machine's trusted roots, which is how TLS interception is planted (MITRE ATT&CK T1553.004, Install Root Certificate). It is a record marked added.

note

Windows Certificates datasets can be created through the dataset creation wizard (Windows Certificates, under the Windows category) or configured via device YAML files under config/devices/.

Dataset	Collector	event.dataset	Definition id	One record per
Windows Certificates	windows_certificate_collector	windows.certificate	1127	certificate and store

Wizard fields

The Dataset configuration step asks for:

Field	Required	Behavior
Interval (seconds)	N	Leave empty to read every 3600 seconds. At least 10.
Certificate stores	N	A multi-select of the seven usual stores, each under the name certlm.msc shows it by, with the store's own name in brackets — for example Trusted Root Certification Authorities (Root). Leave empty to read all seven.
Pre-processing pipeline	N	The pipeline the dataset's records enter, as on every dataset.

Properties

Field	Required	Type	Default	Description
interval	N	int	3600	Seconds between readings. At least 10. A restart or a failover resumes from the dataset's last reading.
certificate_stores	N	string[]	My, Root, CA, AuthRoot, TrustedPeople, TrustedPublisher, Disallowed	The stores to read, a list or one comma-separated text. A local machine store by name (My, WebHosting), as certutil and PowerShell (Cert:\LocalMachine\<name>) know it, in any case; a service's as Services\<service>\<store> (Services\MSSQLSERVER\My); a user's as Users\<SID>\<store>. A store name is letters, digits, spaces, -, _, ., at most 64; a service name at most 256 characters with no slash; a SID S-1- and numbers. Any other name leaves the dataset unread, with a warning.
include_archived	N	boolean	false	List each store's archived certificates too (a renewed certificate's old one), each with archived: true.
keystore_paths	N	string[]	—	The PKCS #12 and JKS keystores to read, a list or one comma-separated text, each a file, a directory, or a glob of either (C:\certs\*.pfx): a directory is walked for its .p12, .pfx, .jks, .keystore and .truststore files; a file a path names is read whatever it is called (a JDK's cacerts). See Keystores.
keystore_password	N	string	—	The keystores' password, one for all: plain text, ${ENV_VAR}, or $secret{...}. A reference keeps it out of the dataset's settings.
pipeline_name	N	string	—	Route the dataset's records to a specific preprocessing pipeline by name.

How the stores are read

The stores are read through the Windows certificate API, so the dataset needs neither WMI nor PowerShell. A store of the local machine is the one certlm.msc shows. A service's store is the one its account sees as its own, and a user's the one the user sees as Current User's. LocalSystem, which the agent runs as, may read both for any service and any user.

• Only certificates are read. Of a private key, only whether the machine holds one is asked, never the key.
• A certificate that does not parse is still written, by its fingerprints and its store, with error.message saying why. A certificate planted in a trust store must not go unseen because it is malformed.
• A root of Microsoft's root programme is written under both Root and AuthRoot, since Windows lists AuthRoot's certificates among Root's. Windows installs such a root by itself, into AuthRoot, the first time a certificate that chains to it is verified, as the dataset itself does (see Chain Verification). So a root marked added under both stores is usually Windows' own doing, and one added under Root alone was put there by hand, by a group policy, or by a program.
• A store of the local machine that cannot be read leaves the dataset unread, with a warning naming it. A reading without one store's certificates would otherwise mark every one of them removed.
• A user whose registry hive is not loaded is passed over, with a warning. Windows loads a user's hive while the user is signed in, or while a service runs as the user. A service's or a user's store that cannot be read for another reason is passed over the same way. What the last reading read of them is kept, neither written nor marked removed.
• With include_archived, a certificate a store keeps archived is written with archived: true. The others say nothing of it.
• The keystores keystore_paths names are read as on Linux: see Keystores.

Chain Verification

Each certificate says whether its chain verifies against the machine's trust store at the reading, as chain.trusted, and when it does not, why, as chain.status. The statuses, and what is and is not checked, are the same on every host: see Chain Verification on the Linux Datasets page. On Windows:

• Chains are verified by Windows' own verifier. It may fetch an issuer the machine does not hold from the address the certificate names, and installs a root of Microsoft's root programme into AuthRoot when a chain reaches one. So the dataset itself can cause the AuthRoot additions described above.
• A certificate of the Disallowed store has no chain: the store distrusts it, whatever its chain.

Output

Each reading writes ECS inventory documents with event.kind set to state and event.dataset set to windows.certificate, one per certificate and store, or certificate and keystore file, with the certificate's fields under windows.certificate. A keystore's certificate is also written with its file as ECS's file.

Field	Description
store	The store the certificate is in (Services\Netlogon\My, Users\<SID>\Root).
friendly_name	The name the certificate was given in the store.
archived	true for a certificate the store keeps archived, read with include_archived. The others have none.
has_private_key	Whether the machine holds the certificate's private key; on a keystore's certificate, whether the keystore holds it.
keystore.type, keystore.alias, keystore.trusted	On a keystore's certificate: pkcs12 or jks; the entry's alias, left out when it has none; and whether the keystore holds it as a trusted certificate.
subject.distinguished_name, subject.common_name	The subject's whole name, and its common name as a list of one.
issuer.distinguished_name, issuer.common_name	The issuer's, the same way.
serial_number	Upper-case hex, without leading zeros.
not_before, not_after	RFC 3339, in UTC.
days_left	The whole days the certificate has left at the reading, rounded down: one that expired an hour ago has -1.
version_number	3, or 1 for the oldest roots.
signature_algorithm	For example SHA256-RSA, ECDSA-SHA384, or SHA1-RSA.
public_key_algorithm, public_key_size	RSA, ECDSA or Ed25519, and the key's size in bits.
public_key_curve, public_key_exponent	An elliptic key's curve (P-256), an RSA key's exponent (65537).
alternative_names	The DNS names, then the IP addresses, the e-mail addresses, and the URIs.
key_usage	For example digital_signature, key_encipherment, cert_sign, or crl_sign.
extended_key_usage	For example server_auth, client_auth, or code_signing, and any other by its object identifier (1.3.6.1.4.1.311.20.2.2, smart card logon).
is_ca	Whether its basic constraints say it is a CA's. A version 1 root has none, and says false.
self_signed	Whether it names itself as its issuer. The signature is not verified.
hash.sha1, hash.sha256	Its fingerprints, in upper-case hex. hash.sha1 is the thumbprint certlm.msc and PowerShell show.
chain.trusted, chain.status	Whether its chain verifies against the machine's trust store at the reading, and when it does not, why: unknown_authority, expired, not_yet_valid, not_authorized_to_sign, name_constraints, incompatible_usage, too_many_intermediates, insecure_algorithm, unhandled_critical_extension, no_trust_store, or error. Left out where the chain is not verified. See Chain Verification.

From a dataset's second reading on, event.action marks each certificate added, changed, unchanged or removed:

• A certificate is known by its store and its fingerprint, so a renewed certificate is the old one removed and the new one added, never one changed.
• days_left is left out of what a reading compares, so a day passing changes no certificate.
• Changing certificate_stores, include_archived or keystore_paths starts a fresh baseline: the first reading after the change marks nothing, rather than writing every certificate the dataset no longer reads as removed.

Solaris, AIX and macOS have certificate datasets of their own: see Solaris, AIX, and macOS Datasets.

Example

Reading the seven usual stores every hour, routing the records to a pipeline...

devices: - id: 123464 name: windows-host type: windows status: true definitions: - name: windows_certificate_collector status: true properties: certificate_stores: - My - Root - CA - AuthRoot - TrustedPeople - TrustedPublisher - Disallowed interval: 3600 pipeline_name: my-pipeline

Windows WireGuard

The windows_wireguard_interface_collector and windows_wireguard_peer_collector read the WireGuard tunnels on the host and their peers, as the Linux WireGuard datasets read a Linux host's, with the same fields by the same names — see WireGuard on the Linux Datasets page.

The agent reads the tunnels of WireGuardNT, the kernel driver WireGuard for Windows installs, and those of a userspace implementation, over its named pipe. An interface and a peer are two schemas, so they are two datasets. A device may be assigned either or both, and the two read the host in one listing when they are due together.

Collector	event.dataset	Definition id	One record per
windows_wireguard_interface_collector	windows.wireguard_interface	1850	tunnel
windows_wireguard_peer_collector	windows.wireguard_peer	1851	peer of each tunnel

Nothing has to be set up on the host. WireGuardNT and the named pipes answer an administrator alone, which the agent is as LocalSystem. WireGuard for Windows runs each tunnel as a service of its own, which makes the tunnel's adapter when it starts and takes it away when it stops: a stopped tunnel is not listed, and a host with no tunnel up writes nothing, which is no error.

Properties

Both datasets take the same properties:

Field	Required	Type	Default	Description
interval	N	int	60	Seconds between readings. At least 10.
filter	N	object	—	Which tunnels it reads, by their names, under the interface scope: filter.interface.include and filter.interface.exclude. With none, it reads every tunnel. The peers dataset reads the peers of the tunnels its own filter keeps, and may follow an interfaces dataset's filter instead.
pipeline_name	N	string	—	Route the dataset's records to a specific preprocessing pipeline by name.

Output

Every document carries the same host.* fields as the host's other metrics documents, with event.kind metric, event.module windows, and event.category network.

The interfaces dataset writes one document per tunnel, in the order of their names. Its fields are under windows.wireguard_interface:

Field	Description
name	The tunnel's name.
type	Where the tunnel runs: windows_kernel for WireGuardNT's, userspace for a userspace implementation's.
public_key	The tunnel's public key. Left out for a tunnel that has no key yet.
listen_port	The UDP port it listens on, 0 when it has none.
firewall_mark	Its firewall mark, 0 when it has none.
peer_count	How many peers it has.
received_bytes, sent_bytes	The bytes its peers received and sent, summed.
received_bytes_per_sec, sent_bytes_per_sec	The rates of those, as below.

The peers dataset writes one document per peer of each tunnel, in the order of the tunnels' names and of the peers' public keys. Its fields are under windows.wireguard_peer:

Field	Description
interface	The name of the tunnel the peer belongs to.
public_key	The peer's public key.
allowed_ips	The addresses the peer may send from, as a list of CIDR ranges.
endpoint	Where the peer was last heard from, or where it is configured to be, as address:port. Left out for a peer never heard from and configured nowhere.
last_handshake	When the last handshake was made, in UTC.
seconds_since_handshake	How long before the reading the last handshake was made.
received_bytes, sent_bytes	The bytes received from the peer and sent to it since the tunnel came up.
received_bytes_per_sec, sent_bytes_per_sec	The rates of those, as below.
persistent_keepalive	The keepalive interval in seconds, 0 when none is sent.
protocol_version	The WireGuard protocol version. Left out when the implementation does not say it.

The endpoint is also the document's source.address, source.ip, and source.port, with network.transport udp. last_handshake and seconds_since_handshake are left out for a peer no handshake was made with since the tunnel came up.

received_bytes_per_sec and sent_bytes_per_sec are what was received and sent since the dataset's last delivered reading, per second, to two decimals; none on a first reading, for a new interface or peer, or for a counter that went back.

Private and preshared keys are never written

No document holds a tunnel's private key or a peer's preshared key.

Example

Reading the host's WireGuard tunnels every five minutes, and the peers of the office tunnel every minute...

devices: - id: 123465 name: windows-wireguard type: windows status: true definitions: - name: windows_wireguard_interface_collector status: true properties: interval: 300 pipeline_name: my-pipeline - name: windows_wireguard_peer_collector status: true properties: interval: 60 filter: interface: include: ["office"] pipeline_name: my-pipeline