Connect to PowerShell Remoting (WinRM) from your Mac

Bifrost talks to Windows over WinRM (Windows Remote Management) — the same protocol Enter-PSSession and the Hyper-V manager use. If a PowerShell or Hyper-V connection shows “Failed to connect”, it’s almost always one of the steps below on the Windows side. Run through them in order.

1. Enable WinRM on the Windows machine

On the Windows host you want to reach, open PowerShell as Administrator and run:

Enable-PSRemoting -Force

This starts the WinRM service and adds the firewall rule. On most machines that’s all you need.

If remoting stops working after a reboot, the WinRM service may not have come back on its own. Set it to start automatically (and re-check the network profile, which a reboot can flip back to Public):

Set-Service WinRM -StartupType Automatic
Start-Service WinRM
Get-NetConnectionProfile   # should be Private or Domain, not Public

2. Make sure the network profile is Private (or Domain)

Enable-PSRemoting refuses to open the firewall while any network adapter is on the Public profile. Check and fix it:

Get-NetConnectionProfile
# If it shows "Public", switch it:
Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private

(Use the InterfaceAlias shown by the first command.) On a domain-joined machine the profile is usually DomainAuthenticated, which is fine.

3. Confirm the firewall rule and the port

WinRM listens on TCP 5985 (HTTP). Verify the listener and that the port is open:

winrm enumerate winrm/config/listener
Test-NetConnection -ComputerName localhost -Port 5985

If Test-NetConnection fails locally, the listener isn’t running — re-run step 1.

4. Username and domain

The simplest format that just works is DOMAIN\username typed directly in the Username field — for example CONTOSO\jdoe. You don’t need to fill the separate Domain field: DOMAIN\username already tells Windows everything. This is the recommended setup and it’s rock-solid for long-running sessions.

• Domain account: DOMAIN\username — use the short (NetBIOS) domain name, e.g. CONTOSO\jdoe.
• Local account (workgroup / no domain): .\username or MACHINENAME\username, e.g. .\Administrator.

The separate Domain field is optional — only useful if you’d rather type a bare username and supply the realm separately (mostly for Kerberos). For most people, DOMAIN\username in the Username field is all you need.

5. Authentication method

Bifrost does not silently switch protocols — the Authentication setting decides, and you can leave it on the inherited default.

• NTLM — works on domain and workgroup/standalone machines, over plain HTTP. It’s a dependable default and stays stable for hours. Being on a domain does not force Kerberos.
• Kerberos — for domain machines reached by their FQDN (host.domain.lan); it needs to locate the domain controller, so it won’t work when you connect by IP. Use it only if your environment mandates Kerberos.
• Negotiate — lets the client and server agree (Kerberos if both support it, otherwise NTLM).
• Basic — sends the username/password directly, with no Windows authentication. Only works if the WinRM listener is explicitly configured for it (and, over plain HTTP, with AllowUnencrypted — so credentials aren’t protected). Use it only for a non-domain host set up that way, ideally over HTTPS. For everything else, prefer NTLM or Negotiate.

If a connection works with the inherited default, leave it. NTLM over a trusted network is fine — the protocol still seals (encrypts) the payload.

6. HTTP vs HTTPS

By default WinRM uses HTTP on 5985. The traffic is still encrypted (Kerberos/NTLM seal the payload), so it’s safe on a trusted network. For an untrusted network you can configure a WinRM HTTPS listener on 5986 and switch the Transport to HTTPS in Bifrost.

---

Troubleshooting

“No route to host” the very first time, then it works on retry. On macOS the first connection on a local network can be blocked while the system shows (or silently evaluates) the Local Network permission prompt. Allow Bifrost under System Settings → Privacy & Security → Local Network, then reconnect. This is a macOS permission step, not a firewall issue — macOS only filters inbound traffic.

Connection refused / times out. The host is off, unreachable, or WinRM isn’t running. Bifrost reports the failure after ~30 s instead of hanging. Verify the host is up and step 1 is done.

It connects but a command never returns. Make sure WinRM is fully enabled (step 1) and you’re on a recent Bifrost build — older builds could leave a request hanging on a dropped connection. Pressing Ctrl-C and re-running the command clears it.

Hyper-V manager shows nothing / fails. Hyper-V uses the same WinRM path as PowerShell. Connect with an account that’s a member of the Hyper-V Administrators (or local Administrators) group on the host, and make sure steps 1–4 pass.

Still stuck? Get in touch — include the exact error text Bifrost shows.