Vagrant attempting to provision Windows 10 guest through WinRM commands despite SSH being set as the communicator

[carlosonunez]

Please note that the Vagrant issue tracker is in priority reserved for bug reports and enhancements. For general usage questions, please use the Vagrant mailing list: https://groups.google.com/forum/#!forum/vagrant-up. Thank you!

Tip: Before submitting your issue, don't hesitate to remove the above introductory text, possible empty sections (e.g. References), and this tip.

Vagrant version

Run vagrant -v to show the version. If you are not running the latest version of Vagrant, please upgrade before submitting an issue.

Vagrant 2.2.3

Host operating system

This is the operating system that you run locally.

MacOS 10.13

Guest operating system

This is the operating system you run in the virtual machine.

Windows 10, build 10240

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :
require 'uri'

box_path = ENV['LOCAL_BOX_PATH'] || "#{Dir.pwd}/ie11.box"
if !File.exists? box_path
  raise IOError.new "Box not found: #{box_path}"
end
box_uri = URI.join('file:///',box_path)

Vagrant.configure("2") do |config|
  config.vm.box = "Win10"
  config.vm.box_download_insecure = true
  config.vm.box_url = box_uri.to_s
  config.vm.guest = :windows
  config.winrm.username = "IEUser" # default username for the box
  config.winrm.password = "Passw0rd!" # default password for the box
  config.vm.boot_timeout = 600
  config.vm.graceful_halt_timeout = 600
  config.ssh.username="IEUser"
  config.ssh.password="Passw0rd!"
  config.ssh.insert_key = false
  config.ssh.sudo_command = ''
  config.ssh.shell = 'sh -l'
  config.vm.communicator = "ssh"
  config.vm.network :private_network, ip: "192.168.0.2"
  config.vm.network :forwarded_port, guest: 3389, host: 3389
  config.vm.network :forwarded_port, guest: 2000, host: 2000
end

Please note, if you are using Homestead or a different Vagrantfile format, we may be unable to assist with your issue. Try to reproduce the issue using a vanilla Vagrantfile first.

Debug output

Provide a link to a GitHub Gist containing the complete debug output: https://www.vagrantup.com/docs/other/debugging.html. The debug output should be very long. Do NOT paste the debug output in the issue, just paste the link to the Gist.

https://gist.github.com/carlosonunez/5197a59c7016ae17fba96af47468926c

Expected behavior

Network interfaces are configured and the box becomes available, and running vagrant up with VAGRANT_LOG=true should show this:

 INFO ssh: Execute: powershell '((test-wsman).productversion.split(" ") | select -last 1).split("\.")[0] (sudo=false)'

Actual behavior

Vagrant hangs at "Configuring network interfaces..." because it attempts to run the above directly inside of the SSH session.

Steps to reproduce

1. Copy and paste the Vagrantfile above into a local Vagrantfile
2. Create the box: vagrant up

References

Are there any other GitHub issues (open or closed) that should be linked here? For example:

• GH-1234
• ...

None :(

[sparkoo]

Hi @carlosonunez , were you able to find any workaround? I'm meeting same issue. I have sshd over cygwin and I can't run powershell commands there. I'm thinking about patching vagrant so test-wsman command will run explicitly in powershell like powershell.exe -Command "test-wsman...", then having powershell.exe on cygwin path should be enough to work.

[carlosonunez]

I have not, I'm afraid :(

Carlos. On Apr 8, 2019, 04:18 -0500, Michal Vala [email protected], wrote:

Hi @carlosonunez , were you able to find any workaround? I'm meeting same issue. I have sshd over cygwin and I can't run powershell commands there. I'm thinking about patching vagrant so test-wsman command will run explicitly in powershell like powershell -Command "test-wsman...", then having powershell.exe on cygwin path should be enough to work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[simonmango]

I know this response is over 4 years too late but for others that might experience this type of issue... For me, it turned out to be the fact that WinRM service was not enabled/running on the VM and therefore WinRM could not connect to it from the host.

Once I fixed the issue with the Windows base box it worked fine everytime.

Maybe you could start the VM, log in and find out if the WinRM service is running.

Here are some links that helped me: https://www.pdq.com/blog/how-to-enable-winrm-window-remote-management/ https://gist.github.com/mapbutcher/6016861 https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/enable-psremoting?view=powershell-7.3