hashicorp/vagrant · error · VagrantPlugins::CommandPS::Errors::PSRemotingUndetected

Unable to establish a remote PowerShell connection with the

Error message

Unable to establish a remote PowerShell connection with the guest. Check if the firewall rules on the guest allow connections to the Windows remote management service.

What it means

After enable_psremoting.ps1 exits 0, `vagrant powershell` parses its JSON stdout; if result['Success'] is false, Errors::PSRemotingUndetected is raised. The script ran, but its probe could not confirm that PS remoting to the guest is actually usable — typically the Windows Remote Management service on the guest is not reachable or not listening.

Source

Thrown at plugins/commands/powershell/command.rb:114

      end

      def ready_ps_remoting_for(machine, ps_info)
        machine.ui.output(I18n.t("vagrant_ps.detecting"))
        script_path = File.expand_path("../scripts/enable_psremoting.ps1", __FILE__)
        args = []
        args << "-hostname" << ps_info[:host]
        args << "-port" << ps_info[:port].to_s
        args << "-username" << ps_info[:username]
        args << "-password" << ps_info[:password]
        result = Vagrant::Util::PowerShell.execute(script_path, *args)
        if result.exit_code != 0
          raise Errors::PowerShellError,
            script: script_path,
            stderr: result.stderr
        end

        result_output = JSON.parse(result.stdout)
        raise Errors::PSRemotingUndetected if !result_output["Success"]
        result_output
      end

      def reset_ps_remoting_for(machine, ps_info)
        machine.ui.output(I18n.t("vagrant_ps.resetting"))
        script_path = File.expand_path("../scripts/reset_trustedhosts.ps1", __FILE__)
        args = []
        args << "-hostname" << ps_info[:host]
        result = Vagrant::Util::PowerShell.execute(script_path, *args)
        if result.exit_code != 0
          raise Errors::PowerShellError,
            script: script_path,
            stderr: result.stderr
        end
      end
    end
  end
end

View on GitHub (pinned to 35f3160f4a)

Solutions

  1. Open Windows Remote Management in the guest firewall: allow inbound TCP 5985 (and 5986 if HTTPS).
  2. Run `Enable-PSRemoting -Force` inside the guest (via `vagrant provision` with a shell provisioner or another communicator) and retry.
  3. If WinRM requires HTTPS, configure winrm transport https and port 5986 in the Vagrantfile.

Example fix

# before: guest firewall blocks WinRM
# after: guest-side rule allowing remote management
c.vm.provision "shell", inline: "netsh advfirewall firewall add rule name='WinRM-HTTP' dir=in action=allow protocol=TCP localport=5985"
Defensive patterns

Strategy: try-catch

Validate before calling

# Pre-flight from the host (Windows): can we see remoting on the guest?
system('powershell', '-Command', "Test-WSMan -ComputerName #{guest_ip}") or
  abort 'PS remoting not detected on guest; enable it or open firewall 5985'

Try / catch

begin
  env.cli(['powershell'])
rescue VagrantPlugins::CommandPowershell::Errors::PSRemotingUndetected => e
  warn e.message # guest-side: firewall 5985/5986 + Enable-PSRemoting, then retry once
  exit 1
end

Prevention

When it happens

Trigger: Guest firewall blocks Windows Remote Management (5985/5986); WinRM listener not configured on the guest (service stopped or Enable-PSRemoting never run); HTTPS-only WinRM while the probe uses HTTP.

Common situations: Locked-down corporate Windows images; guests cloned from templates without running sysprep/Enable-PSRemoting; NAT/private networks where the detection targets the wrong interface.

Related errors


AI-assisted analysis of hashicorp/vagrant@35f3160f4a (2026-08-21). Data as JSON: /api/errors/4e0b5c818dc25ee6. Report an issue: GitHub.