Deploying Wazuh agents
on Windows endpoints

1. Scope and telemetry path

This guide covers onboarding a Windows workstation or server to an existing Wazuh manager. For the central platform setup, start with Wazuh all-in-one installation and validation. The same agent workflow applies when the manager runs in Docker, provided its ports are reachable from the endpoint.

Windows Event Log → Wazuh agent → Wazuh manager
                                      ├─ Rules → alerts → Filebeat → indexer → dashboard
                                      └─ Archives (optional) → received-event evidence

EventChannel collection covers Windows logs. File integrity monitoring, additional application logs, and Sysmon require their own configuration and validation; installing the agent does not automatically provide every telemetry source.

2. Prerequisites and network ports

• A supported Windows endpoint and an elevated PowerShell session.
• A working manager, indexer, and dashboard with sufficient capacity and synchronized clocks.
• A stable manager IP address or resolvable DNS name and a unique endpoint identity.
• A Windows agent release compatible with the manager. The manager must be the same version as or newer than the agent; do not install the newest MSI blindly on an older manager.
• Access to the official Wazuh installer and your environment's enrollment policy, including any password or certificate requirements.

TCP 55000 is the Wazuh API and is used by API-based enrollment workflows. It is not the event transport port and is not needed from the endpoint for the default 1515 enrollment procedure shown here. Restrict agent ports to the intended endpoint networks.

3. Validate the path to the manager

For a VirtualBox lab, place both VMs on the same host-only network. An optional second NAT adapter provides Internet access. Use the manager host's reachable host-only address, not a Docker-internal address or an isolated NAT address. These adapters are a lab choice, not a Wazuh requirement.

# Example lab address: replace with your reachable manager IP or DNS name.
$Manager = "192.168.56.101"
Test-NetConnection -ComputerName $Manager -Port 1514
Test-NetConnection -ComputerName $Manager -Port 1515

Both checks should report TcpTestSucceeded : True before initial enrollment. A ping can help diagnose routing, but ICMP may be blocked independently of TCP. An open TCP port proves a listener is reachable, not that enrollment credentials or event ingestion are working.

When the manager runs in Docker

On the Docker host, inspect the active Compose deployment:

docker compose ps
docker compose port wazuh.manager 1514
docker compose port wazuh.manager 1515

These commands assume the official Compose service name wazuh.manager; substitute your service name if different. Confirm TCP 1514 and 1515 are published on a host interface reachable by Windows, and that host and network firewalls allow the connections. Container listeners alone do not establish access from another VM.

4. Install the Windows agent

Download the compatible MSI from the official Windows agent installation page. The example uses a local file so the package version is an explicit deployment choice. Replace the filename placeholder and run in elevated PowerShell.

$Manager = "192.168.56.101"
$Msi = Join-Path $env:USERPROFILE 'Downloads\wazuh-agent-<version>-1.msi'
$InstallLog = Join-Path $env:TEMP 'wazuh-agent-install.log'
if (-not (Test-Path -LiteralPath $Msi)) {
    throw "Set the exact downloaded MSI path before continuing."
}
$Signature = Get-AuthenticodeSignature -FilePath $Msi
$Signature | Format-List Status, StatusMessage, SignerCertificate
if ($Signature.Status -ne 'Valid') {
    throw "Installer signature validation failed. Review the package source."
}
# Verify the displayed signer against the expected vendor before proceeding.
$MsiArgs = @(
    '/i', ('"{0}"' -f $Msi), '/qn', '/norestart',
    ('WAZUH_MANAGER="{0}"' -f $Manager),
    ('WAZUH_REGISTRATION_SERVER="{0}"' -f $Manager),
    ('WAZUH_AGENT_NAME="{0}"' -f $env:COMPUTERNAME),
    '/L*v', ('"{0}"' -f $InstallLog)
)
$Install = Start-Process -FilePath 'msiexec.exe' -ArgumentList $MsiArgs -Wait -PassThru
if ($Install.ExitCode -notin @(0, 3010)) {
    throw "MSI failed with exit code $($Install.ExitCode). Inspect $InstallLog"
}
if ($Install.ExitCode -eq 3010) {
    Write-Warning 'Windows Installer requests a restart; schedule it before final validation.'
}
Start-Service -Name WazuhSvc
Get-Service -Name WazuhSvc

/qn selects silent installation, /norestart prevents an automatic reboot, and -Wait avoids racing the installer with service startup. The MSI log is saved locally for diagnostics. Treat logs as operational data and redact environment details before sharing.

WAZUH_MANAGER selects the event destination. WAZUH_REGISTRATION_SERVER selects the enrollment endpoint; the default is the manager when omitted. This example uses one server for both. If your enrollment policy requires a password or certificate verification, use the corresponding documented deployment variables and approved secret handling rather than weakening the manager policy.

5. Verify service health and enrollment

On a standard 64-bit Windows installation, inspect the service, agent diagnostics, and transport connection:

$AgentRoot = Join-Path ${env:ProgramFiles(x86)} 'ossec-agent'
Get-Service -Name WazuhSvc
Get-Content -LiteralPath (Join-Path $AgentRoot 'ossec.log') -Tail 80
Get-NetTCPConnection -RemotePort 1514 -State Established -ErrorAction SilentlyContinue |
    Select-Object LocalAddress, RemoteAddress, RemotePort, State

Adjust the installation path if necessary. Check that the connection's remote address matches the intended manager. Read ossec.log for enrollment acceptance, connection establishment, and configuration errors. Do not copy or publish client.keys: it contains the agent's authentication material.

In the dashboard agent inventory, locate the endpoint by its configured name, record its agent ID, and confirm an active status and recent keepalive. On a package-installed manager, you can cross-check with:

sudo /var/ossec/bin/agent_control -l
sudo tail -n 80 /var/ossec/logs/ossec.log

For the official Docker deployment, run the manager check inside its container:

docker compose exec wazuh.manager /var/ossec/bin/agent_control -l

An active agent confirms the control/communication path. Continue with a known event to validate log collection.

6. Inspect Windows EventChannel collection

Wazuh's default Windows configuration collects the Application, Security, and System channels. Inspect ossec.conf in the agent installation directory and any centrally assigned group configuration before making changes.

Select-String -LiteralPath (Join-Path $AgentRoot 'ossec.conf') -Pattern 'eventchannel' -Context 2, 3

The relevant blocks inside <ossec_config> use this structure. These are reference examples: keep existing channel filters and do not paste duplicate blocks into an already configured agent.

<localfile>
  <location>Application</location>
  <log_format>eventchannel</log_format>
</localfile>
<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
</localfile>
<localfile>
  <location>System</location>
  <log_format>eventchannel</log_format>
</localfile>

If you change the local configuration, retain a backup, validate the XML, restart WazuhSvc, and check the agent log immediately. Security events also depend on Windows audit policy; a collector cannot forward an event the OS never generated. Sysmon requires a separate installation, configuration, and collection of Microsoft-Windows-Sysmon/Operational.

7. Prove delivery with a known event

Create and identify the local record

Run this harmless informational event test in elevated PowerShell. The timestamped marker makes the test distinguishable from older records:

$Marker = 'Wazuh-Onboarding-' + (Get-Date -Format 'yyyyMMdd-HHmmss')
eventcreate /L APPLICATION /T INFORMATION /SO WazuhConnectivityTest /ID 100 /D "$Marker"
Get-WinEvent -FilterHashtable @{
    LogName = 'Application'
    ProviderName = 'WazuhConnectivityTest'
    Id = 100
    StartTime = (Get-Date).AddMinutes(-5)
} | Select-Object TimeCreated, Id, ProviderName, Message

Record the marker, endpoint name, agent ID, and timestamp. Confirm the event exists locally before troubleshooting Wazuh. This is a collection test; it is not a simulated attack and may not match an alert-generating rule.

Distinguish received events from alerts

The usual wazuh-alerts-* view contains alerts, not every collected Windows event. Start by filtering the correct agent and time window. If the marker is absent, that alone does not prove a collection failure.

For a controlled lab, JSON archives can provide direct evidence of received events. They are disabled by default. To enable them temporarily, set <logall_json>yes</logall_json> in the manager's existing <global> block in /var/ossec/etc/ossec.conf, then restart the manager. In Docker, edit the persistent configuration used by your deployment, not an ephemeral copy. Archive retention consumes disk space and can include sensitive event content; size and restrict it before enabling.

# Package-installed manager; restart after updating the existing configuration.
sudo systemctl restart wazuh-manager
# Generate the Windows test event AFTER the manager is ready.
# Replace this example with the exact marker printed on Windows.
sudo grep -F 'Wazuh-Onboarding-20261112-140000' /var/ossec/logs/archives/archives.json

Check that the matching archive record has the expected agent.id, agent.name, timestamp, provider, and event ID. For Docker, inspect the same archive path inside the manager container. If archive forwarding is already configured, search wazuh-archives-* in the dashboard instead. Enabling manager archives alone does not enable dashboard archive indexing; Filebeat archive forwarding and an appropriate data view are also required.

A matching archive record proves Windows-to-manager delivery. A corresponding alert in wazuh-alerts-* proves the detection and alert-indexing path only when an applicable rule fires. Use an approved detection test for that separate check. After temporary archive validation, restore the previous logging setting and restart the manager if continuous archiving is not part of the deployment.

8. Troubleshoot the failing stage

Keep a small onboarding record: manager and agent versions, agent ID, service state, connectivity results, and a timestamped received-event sample. Document which stage was actually validated instead of treating an active badge as proof of all monitoring capabilities.

9. References and source note

• Wazuh — Windows agent installation
• Wazuh — Windows deployment variables
• Wazuh — component version compatibility
• Wazuh — agent connection checks
• Wazuh — Docker deployment utilities
• Wazuh — Windows EventChannel configuration
• Wazuh — event archives and indexing
• Microsoft — eventcreate command reference

Adapted and expanded from Connecting a Windows Endpoint to Wazuh. Commands and validation guidance were rewritten against official documentation. The steps describe a reproducible procedure rather than a claim of a newly executed endpoint deployment.