Deploying the Wazuh Agent on Windows Servers at Scale

The short answer: the Wazuh agent for Windows is a single MSI that installs and enrols from one msiexec line, so rolling it out to dozens of servers is a matter of choosing the right deployment variables, not of clicking through a wizard. This guide is for sysadmins who already have a Wazuh manager running and now need to put agents on Windows servers in a repeatable way: silent install, password-protected enrolment, agent groups, a verification step and a safe upgrade path. If you have not set up the manager yet, start with the Wazuh program page.

What we checked on 3 November 2026

Use the MSI version that matches your manager. A Wazuh agent must not be newer than the manager it reports to, so check the manager version before you copy the installer to anything.

Network requirements before you touch an endpoint

The agent only needs outbound connectivity to the manager. The documented ports are 1514/TCP for agent communication, 1515/TCP for enrolment through the agent configuration and 55000/TCP for enrolment through the Wazuh server API. All three are configurable. Test the path from a Windows server before the rollout:

Test-NetConnection 10.0.0.2 -Port 1514
Test-NetConnection 10.0.0.2 -Port 1515

If either test fails, fix the firewall first. Most agents that stay in the “Never connected” state in the dashboard are a blocked port or a wrong manager address, not a broken installer.

Step 1: Create groups on the manager first

New agents join the default group unless you assign another. Groups let you push a different agent.conf to different kinds of servers, so create them before enrolment and pass the name in the install command. On the manager, as root:

/var/ossec/bin/agent_groups -a -g Windows-Servers -q
/var/ossec/bin/agent_groups -l

Each group has its own file at /var/ossec/etc/shared/<GROUP_NAME>/agent.conf on the manager; it is empty until you add centralised settings. You can also create groups from Agents management > Groups in the dashboard or with POST /groups on the API.

Step 2: Turn on password enrolment

Without a password, anything that can reach port 1515 can ask to be enrolled. Wazuh documents a password method for exactly this reason. On the manager, add this to the <auth> section of /var/ossec/etc/ossec.conf:

<auth>
  <use_password>yes</use_password>
</auth>

Then create the password file, lock down its permissions and restart the manager:

echo "<CUSTOM_PASSWORD>" > /var/ossec/etc/authd.pass
chmod 640 /var/ossec/etc/authd.pass
chown root:wazuh /var/ossec/etc/authd.pass
systemctl restart wazuh-manager

If you skip the file, the enrolment service picks a random password at each manager restart and writes it to /var/ossec/logs/ossec.log, which is awkward for unattended rollouts. In a multi-node cluster, enable password authentication on every manager node, ideally with the same password.

Step 3: Silent install with deployment variables

Run this from an elevated prompt with the MSI in the working directory. Replace the address, group and password with your own values:

msiexec.exe /i wazuh-agent-4.14.9-1.msi /q ^
  WAZUH_MANAGER="10.0.0.2" ^
  WAZUH_REGISTRATION_SERVER="10.0.0.2" ^
  WAZUH_REGISTRATION_PASSWORD="TopSecret" ^
  WAZUH_AGENT_GROUP="Windows-Servers" ^
  WAZUH_AGENT_NAME="SRV-FILE01"
NET START WazuhSvc

In PowerShell the equivalent start command is Start-Service wazuhsvc. Two details from the deployment-variables page save time:

• If a value contains spaces, PowerShell needs triple quotes, for example WAZUH_REGISTRATION_PASSWORD="""TOP SECRET""".
• Add /l*v installer.log to write a verbose installer log, which is the first thing to read when a mass install fails on a few hosts.

The agent name defaults to the computer name, so you only need WAZUH_AGENT_NAME when names clash. Install without any variables if you want the files in place but enrolment done later.

Deployment variables worth knowing

Step 4: Roll it out to many servers

Wazuh itself ships the MSI and the variables; how the command reaches 50 servers is up to your tooling. Any method that can run msiexec with the same properties works: a PowerShell remoting loop, your software-distribution tool or a configuration-management run. A minimal remoting example, with the MSI copied to a share the servers can read:

$servers = Get-Content .servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
  Start-Process msiexec.exe -Wait -ArgumentList '/i \fs01deploywazuh-agent-4.14.9-1.msi /q WAZUH_MANAGER="10.0.0.2" WAZUH_REGISTRATION_SERVER="10.0.0.2" WAZUH_REGISTRATION_PASSWORD="TopSecret" WAZUH_AGENT_GROUP="Windows-Servers"'
  Start-Service wazuhsvc
}

Keep the enrolment password out of scripts in shared folders: read it from a secret store at run time. If you already manage Windows hosts with Salt Minion for Windows, the same command can be run through it. Wazuh also documents deployment with Ansible and Puppet if you use those.

Step 5: Verify the agents

On the manager:

/var/ossec/bin/agent_control -l
/var/ossec/bin/agent_control -i 001 | grep Status

In the dashboard, open Agents management > Summary: the statuses are Active, Disconnected, Pending and Never connected. A host that is “Never connected” after the install usually has a wrong manager address or a blocked port. On the endpoint, read ossec.log in the agent folder and look for the enrolment result.

Upgrading agents later

Upgrade the manager first, then the agents. From the manager, agent_upgrade -l lists outdated agents and agent_upgrade -a 001 002 upgrades the IDs you name; the agent restarts automatically. In a cluster, Wazuh recommends the API instead: GET /agents/outdated to list and PUT /agents/upgrade?agents_list=001,002 to start the upgrade.

Limitations

• The Wazuh documentation we read does not give a step-by-step Group Policy or Intune package; the MSI properties above are the supported interface.
• Older Windows, before Server 2008 or Windows 7, needs compatibility settings on the manager: either run wazuh-authd with -a or set <ssl_auto_negotiate> to yes in the auth section.
• The agent collects data; analysis, rules and alerting live on the manager, so a Windows agent alone is not a complete SIEM.

Who this approach fits

It suits teams that run their own Wazuh manager and need identical, scripted installs on a growing set of Windows servers. It is less suitable if you want a hosted service with no manager to maintain, or if your Windows estate is mostly unmanaged laptops where an MSI push is not realistic. For the wider picture of access and security tooling, see Identity and Access Management Tools.

FAQ

How do I install the Wazuh agent on Windows silently?

Run msiexec.exe /i wazuh-agent-4.14.9-1.msi /q WAZUH_MANAGER="10.0.0.2" from an elevated prompt, then start the service with NET START WazuhSvc.

Can the Wazuh agent run on Windows 11 and Windows Server?

Yes. The official guide lists systems from Windows XP up to Windows 11 and Windows Server 2022.

Where are the Wazuh agent files and config on Windows?

In C:Program Files (x86)ossec-agent on 64-bit systems, including ossec.conf, authd.pass and the logs.

Can I deploy the Wazuh agent with GPO or Intune?

Wazuh does not publish a dedicated guide for either in the pages we checked. Both tools can run an MSI with properties, so the command above is what you would package. Test on a pilot group first.

Is the Wazuh agent for Windows free?

Yes. It is free and open source under GPL-2.0, with no licence cost per agent.

How do I remove a decommissioned agent from the manager?

Find its ID with agent_control -l, then run /var/ossec/bin/manage_agents -r <ID> on the manager, or remove it from the dashboard agent list.

Last updated: 3 November 2026 · AdminHub Plus editorial team. Licence, version and platform details are checked against each developer's official documentation.