Host Agent

[akcmjr]

I wanted to install a host agent on Windows, but it is not possible.
It appears that the install-host-agent.ps1 file is not present on the Pulse server installed as a Proxmox container. I cannot find the api directory either.

[rcourtman]

install-host-agent.ps1 is served over HTTP. Hit http://your-pulse-ip:7656/install-host-agent.ps1 (replace your-pulse-ip with the actual address) or copy the command under Settings → Agents → Host agents, which matches docs/HOST_AGENT.md.

There is no api directory on disk. /api/* is handled by the Go router and only exists as HTTP routes.

If curl http://your-pulse-ip:7656/install-host-agent.ps1 fails, confirm the Pulse container is v4.26.0 or newer and that you are actually reaching it on port 7656. If it still returns 404, capture the container logs around that request.

[akcmjr]

I have version 4.26.4 and I am using port 7655, not 7656, which is not responding.The request from a Firefox browser on Windows http://10.0.1.87:7655/install-host-agent.ps1 returns a 404 error.
Attached are the tcpdump traces of the command.

[rcourtman]

install-host-agent.ps1 has been part of Pulse since v4.26.1 on 23 October 2025 and the router flags it as a public endpoint so authentication never blocks it. The script is served directly from /opt/pulse/scripts/install-host-agent.ps1.

Port 7655 is the expected production port. A 404 there means the handler is missing from the binary that is currently serving that port, which usually happens when an older pre v4.26.1 container is still running even if a newer image was pulled.

Please confirm what version is actually responding on that port by running:

curl http://10.0.1.87:7655/api/version

If the server runs inside Docker and port forwarding is involved, you can also check from inside the container:

docker exec pulse pulse version

If those commands both report v4.26.4, share the container logs that show the 404 for /install-host-agent.ps1 so the next step can focus on what is intercepting the route.

[akcmjr]

I confirm that I installed the update this morning.
Attached are the logs showing error 404.

[rcourtman]

A 404 from /install-host-agent.ps1 means the server cannot open /opt/pulse/scripts/install-host-agent.ps1. The handler is public and just serves that file, so the request only fails when the file is missing or unreadable on the running container or host.

Run docker exec pulse ls -l /opt/pulse/scripts/install-host-agent.ps1 (or the equivalent command for your deployment) to confirm the script is actually there. If that command prints No such file or similar, the runtime filesystem is missing the script.

Most reports trace back to either a bind mount or volume that hides /opt/pulse/scripts or to an upgrade that only replaced the pulse binary but left the rest of the image or installation untouched. Remove any custom mount on /opt/pulse/scripts or replace the container completely with docker-compose pull followed by docker-compose up -d so the baked-in scripts return. If you built from source or copied just the binary, you need the full release artifacts or the build output from scripts/build-release.sh so the scripts directory gets staged alongside the binary.

Once /opt/pulse/scripts/install-host-agent.ps1 exists on the running instance, the endpoint stops returning 404.

[akcmjr]

The installation scripts are present in /opt/pulse/scripts.
I started the installation on my Windows 11 PC, but the script does not launch. Is this a compatibility issue?

[rcourtman]

That message means Windows grabbed a copy of the host agent that does not match the hardware. The download endpoint falls back to whatever file it finds, so if your Pulse container only has the Linux build it will serve that and Windows shows "Cette application ne peut pas s'exécuter sur votre PC."

Open an elevated PowerShell window and run Get-CimInstance Win32_OperatingSystem | Select OSArchitecture, then share the result so I know which build is needed.

If that command reports ARM64 (Surface Pro X, Copilot+ PC, Snapdragon), native Windows ARM support will be part of the release that goes out today. Pull the new Pulse container once it is published so the server hosts pulse-host-agent-windows-arm64. After the update, rerun the installer and it should fetch the correct binary.

If the command reports 64-bit (x64 or amd64) this fallback should not happen. In that case I need the exact URL you ran and any prompt output so I can trace why it returned the wrong file.

[akcmjr]

Here is the command line I executed
irm http://10.0.1.87:7655/install-host-agent.ps1 | iex
The windowspowershell window closes automatically when it encounters an error.
In the screenshot, the files are present in /opt/pulse/bin and the script successfully downloads the pulse-host-agent file.

[rcourtman]

I just reran the installer on a fresh Windows Server 2022 64-bit VM. The script downloaded pulse-host-agent.exe (6,473,728 bytes), the SHA256 matched the server binary exactly, and the agent runs and reports its version. So the download endpoint and installer are fine in that environment, which means your machine is doing something different.

I still need the exact Windows architecture from Get-CimInstance Win32_OperatingSystem | Select OSArchitecture. Only the amd64 build exists today, so 32 bit Windows or Windows on ARM without x64 emulation will reject it immediately.

After the script finishes downloading, please run Get-FileHash "$env:ProgramFiles\Pulse\pulse-host-agent.exe" -Algorithm SHA256 and Get-Item "$env:ProgramFiles\Pulse\pulse-host-agent.exe" | Select Length. If the hash doesn't match the server or the size isn't roughly 6.5 MB, the download was corrupted or replaced, which would cause the "Cette application ne peut pas s'exécuter sur votre PC" dialog before the agent even starts.

[akcmjr]

Hello
Here are the requested command lines

[rcourtman]

Looks like the 6 533 304 byte file you ran is actually the Linux amd64 agent. That size matches the Linux build exactly, while the current Windows amd64 agent is 6 473 728 bytes and its SHA256 is 356b70b3a3ad8b8606e0e164942b6938dde0ac4e531b6f7930fa23d88baab5d2. When the download endpoint is called without the platform and arch query parameters it falls back to whatever binary matches the server's own operating system, so the browser quietly handed you the Linux ELF even though it had a .exe extension.

The installer script avoids this by always requesting /download/pulse-host-agent?platform=windows&arch=amd64 and then it checks the PE header before proceeding. Please rerun it with irm http://10.0.1.87:7655/install-host-agent.ps1 | iex. That will pull the right build automatically.

If you would rather download manually, use http://10.0.1.87:7655/download/pulse-host-agent?platform=windows&arch=amd64. After the download, run a SHA256 check and confirm it equals 356b70b3a3ad8b8606e0e164942b6938dde0ac4e531b6f7930fa23d88baab5d2 before executing the binary.

[akcmjr]

I have always used this command to install the agent.
I just downloaded it manually, specifying the platform and architecture, and it is still the Linux agent that downloads. I just checked its size and signature.
On Friday, since it couldn't find the agent that was causing my problem, I did a complete reinstallation on a Proxmox container.
Do I need to do it again?

[rcourtman]

It should never hand you the Linux build when both platform and arch are supplied, so the most likely problem is that the Windows files inside your container are missing or symlinked to the Linux binary. Need direct confirmation from the container shell.

Run

ls -l /opt/pulse/bin/pulse-host-agent-windows-*
file /opt/pulse/bin/pulse-host-agent-windows-amd64

The first command should show real files for amd64 arm64 and 386 plus the .exe targets. The second command must report a Windows PE executable, not ELF. If either command fails or reports ELF that means the Windows build was never copied into this container image.

After that confirm the container is the current release by running cat /opt/pulse/VERSION or checking Settings > About. If it is older than the latest release image pull the newest pulse tag and restart instead of reinstalling everything.

If the Windows binary is missing or still reports ELF you will need to rebuild or redeploy the container so /opt/pulse/bin/pulse-host-agent-windows-*.exe actually exists. If the commands show valid PE files yet downloads still come back as Linux, let me know the exact output from both commands and the version reading so I can dig further.

[akcmjr]

The agents were missing from the /opt/pulse/bin directory.
I recreated a container with the new version 4.27.1, but they are still missing.