unable to add hyperv standalone host to new install latest v13

Try this checklist for troubleshooting.

Hi ​@AshbyComputers -

This may be an issue with UAC? See my resolution in the post below:

Let us know how it goes.

i agree with both ​@Chris.Childerhose & ​@coolsport00 

If you’re trying to add a standalone Hyper‑V host into Veeam Data Platform (v12/v13), the issue is almost always firewall‑related. These are the ports that need to be open on the Hyper‑V host, allowing traffic from the Veeam Backup server.

The important ones (don’t skip these)

SMB & basic Windows management

• TCP 445 – SMB (admin shares, component install)
• TCP 135 – RPC endpoint mapper
• TCP 49152–65535 – RPC dynamic ports (this one catches people out a lot)

If RPC dynamic ports are blocked, the host will not add cleanly.

Hyper‑V management

Veeam uses WinRM/WMI to talk to Hyper‑V:

• TCP 5985 – WinRM (HTTP)
• TCP 5986 – WinRM (HTTPS, only if you’ve enabled it)

If WinRM isn’t enabled or is firewalled, Veeam usually throws vague or misleading errors.

Veeam data traffic

When Veeam deploys its data mover to the host, it uses:

• TCP 2500–3300 – Veeam data mover (default range)

You can change this range in Veeam, but it has to be open on the Hyper‑V side either way.

“Make it work” rule (what I usually do)

If you just want to get past the add‑host issue quickly, allow inbound from the Veeam Backup server IP to the Hyper‑V host on:

• TCP 445
• TCP 135
• TCP 5985
• TCP 2500–3300
• TCP 49152–65535

This fixes the vast majority of “can’t add Hyper‑V host” problems.

Common gotchas I see all the time

• WinRM isn’t enabled (winrm quickconfig)
• Firewall only allows Domain profile, but the NIC is Private/Public
• RPC dynamic ports blocked
• DNS mismatch (Veeam resolves the host to a different IP than expected)

I’ve run into similar issues with Hyper-V hosts before, especially on standalone setups.

In my experience, it’s usually something related to communication or permissions rather than Veeam itself. I’ve had success troubleshooting with things like:

• IPv6 configuration
• UAC settings
• Local security policies
• Antivirus interference
• Firewall rules
• User permissions
• Authentication format (using hostname\user instead of just user)
• Windows updates / patch level

In a few cases, even after a fresh install, something in these areas was blocking the connection and causing the same “connection refused” error.

Might be worth double-checking those points