Provisioning halts on "Waiting for WinRM to become available..."

[dhoer]

I'm getting the same thing as issue #31 for:
make virtualbox/eval-win10x64-enterprise

The two differences I see from what was mentioned in issue #31 is that I'm using VBox 5.0.6 and Packer 0.8.6.

I even added:
"ssh_host_port_min": "5985",
"ssh_host_port_max": "5985"

But that didn't fix it either.

Any ideas? Maybe VBox 5.0.6 not compatible?

Environment

Mac OS X 10.10.5 (Yosemite)
Vagrant 1.7.4
VirtualBox 5.0.6r103037
Packer 0.8.6

Vagrant Plugins

vagrant-share (1.1.4, system)
vagrant-vmware-fusion (3.2.9)
vagrant-winrm (0.7.0)

$ make virtualbox/eval-win10x64-enterprise
rm -rf output-virtualbox-iso
mkdir -p box/virtualbox
packer build -only=virtualbox-iso -var 'cm=nocm' -var 'version=1.0.4' -var 'update=false' -var 'headless=false' -var "shutdown_command=shutdown /s /t 10 /f /d p:4:1 /c Packer_Shutdown" -var "iso_url=http://care.dlservice.microsoft.com/dl/download/C/3/9/C399EEA8-135D-4207-92C9-6AAB3259F6EF/10240.16384.150709-1700.TH1_CLIENTENTERPRISEEVAL_OEMRET_X64FRE_EN-US.ISO" -var "iso_checksum=56ab095075be28a90bc0b510835280975c6bb2ce" eval-win10x64-enterprise.json
virtualbox-iso output will be in this color.

==> virtualbox-iso: Downloading or copying Guest additions
    virtualbox-iso: Downloading or copying: file:///Applications/VirtualBox.app/Contents/MacOS/VBoxGuestAdditions.iso
==> virtualbox-iso: Downloading or copying ISO
    virtualbox-iso: Downloading or copying: http://care.dlservice.microsoft.com/dl/download/C/3/9/C399EEA8-135D-4207-92C9-6AAB3259F6EF/10240.16384.150709-1700.TH1_CLIENTENTERPRISEEVAL_OEMRET_X64FRE_EN-US.ISO
==> virtualbox-iso: Creating floppy disk...
    virtualbox-iso: Copying: floppy/00-run-all-scripts.cmd
    virtualbox-iso: Copying: floppy/01-install-wget.cmd
    virtualbox-iso: Copying: floppy/_download.cmd
    virtualbox-iso: Copying: floppy/_packer_config.cmd
    virtualbox-iso: Copying: floppy/disablewinupdate.bat
    virtualbox-iso: Copying: floppy/eval-win10x64-enterprise/Autounattend.xml
    virtualbox-iso: Copying: floppy/fixnetwork.ps1
    virtualbox-iso: Copying: floppy/install-winrm.cmd
    virtualbox-iso: Copying: floppy/oracle-cert.cer
    virtualbox-iso: Copying: floppy/passwordchange.bat
    virtualbox-iso: Copying: floppy/powerconfig.bat
    virtualbox-iso: Copying: floppy/update.bat
    virtualbox-iso: Copying: floppy/zz-start-sshd.cmd
==> virtualbox-iso: Creating virtual machine...
==> virtualbox-iso: Creating hard drive...
==> virtualbox-iso: Attaching floppy disk...
==> virtualbox-iso: Creating forwarded port mapping for SSH (host port 5985)
==> virtualbox-iso: Executing custom VBoxManage commands...
    virtualbox-iso: Executing: modifyvm eval-win10x64-enterprise --memory 1536
    virtualbox-iso: Executing: modifyvm eval-win10x64-enterprise --cpus 1
    virtualbox-iso: Executing: setextradata eval-win10x64-enterprise VBoxInternal/CPUM/CMPXCHG16B 1
==> virtualbox-iso: Starting the virtual machine...
==> virtualbox-iso: Waiting 10s for boot...
==> virtualbox-iso: Typing the boot command...
==> virtualbox-iso: Waiting for WinRM to become available...

[rickadair]

I see that same behavior with the parallels provider as well.

[dhoer]

@rickadair @rasa I suspect it is related to this merge pull request:
9299c1d

But I haven't had time to check it out.

[rickadair]

Makes sense. I ended up addressing it by adding sc config winrm start=auto to my install-winrm.cmd.

[dusek]

In my case, it was caused by using a non-English Windows 7 install image (I was using a Czech one). That caused systeminfo (run in install-winrm.cmd) to report the OS version in a localized form, specifically, "OS Name" is localized in the Czech version of systeminfo to something else (or see an example of German output). The problem was that based on this, fixnetwork.ps1 was not run, and the network remained set to Public, which caused most commands in install-winrm.cmd to fail.

I solved it by commenting the systeminfo ... and the subsequent if errorlevel 1... line in install-winrm.cmd to make fixnetwork.ps1 run unconditionally (without checking for a specific Windows version).

[eoyslebo]

I have the same issue when I run make virtualbox/eval-win10x64-enterprise: installation will not continue because WinRM is not running.

Installation continues and completes if I manually run Enable-PSRemoting -force as admin.

If I make virtualbox/eval-win10x64-enterprise-ssh, the installation completes without any manual steps. When i vagrant up the result however, WinRM is disabled and provisioning fails. Trying to run Enable-PSRemoting manually fails because the network interface is set to public. The ssh server is working, but is not being used by vagrant to provision.

[diimdeep]

OSX 10.11.2
Vagrant 1.8.1
vagrant-parallels (1.6.0)
vagrant-share (1.1.5, system)
vagrant-winrm (0.7.0)
Packer 0.8.6
Parallels 11.1.1

make parallels/eval-win10x64-enterprise

Same problem, stuck somewhere at windows update.

[jcoutch]

If you have update.bat in your floppy's section - remove it. When the 00-run-all-scripts.bat file runs, it'll iterate through all of them, and once it hits update.bat, Windows updates will be performed and may/may not reboot your machine (depending on the updates.) Since it reboots, any scripts listed after update.bat will never get triggered...one of which being zz-start-sshd.bat, which starts sshd/winrm.

If you want to do updates, then you'd need to modify the reboot function in update.bat to insert a runonce registry entry for zz-start-sshd.bat, or even better, create a new script called post-update-run-scripts.bat that you can toss any scripts you want to run after Windows Update, and set that up to run once.

[jcoutch]

I submitted a pull request to work around the update.bat issue I found:
#58

[rmoriz]

Ran into the same problem with make vmware/eval-win10x64-enterprise on OSX with packer 0.10.0 and VMWare Fusion 8.1. After removing update.bat I see the error mentioned in #37

[andrew-morris]

this is affecting me as well

[dhoer]

Updating packer from v0.8.6 to v0.12.0 fixed it.

[ColinNg]

Working Combination for packer-windows on macOS Sierra:
vagrant 1.8.6, 1.9.1
packer 0.12.0
VirtualBox 5.1.10 r112026

Failing Versions
vagrant 1.8.7 can’t add boxes made by packer
packer 0.12.1 bug with WinRM
VirtualBox 5.1.8, 5.1.12 can’t remove Floppy Issue

[barkingfoodog]

Vagrant 1.8.7 embeds a curl binary that's incompatible with macOS 10.12 Sierra. The issue and workaround are described here. Fixing that might fix the error you encountered adding boxes to Vagrant.

[fumiyas]

#41 (comment)

VirtualBox 5.1.8, 5.1.12 can’t remove Floppy Issue

Put HEADLESS=true into your Makefile.local to avoid it. See the following issues for details.

• #16063 (Any immediate "VBoxManage modifyvm" commands after detaching a dvd drive fail with 'The machine 'vm_name' is already locked for a session') – Oracle VM VirtualBox
  • https://www.virtualbox.org/ticket/16063
• Error removing floppy controller · Issue #2401 · mitchellh/packer
  • Error removing floppy controller hashicorp/packer#2401

[bflad]

The HEADLESS=true solution above did workaround the floppy issue for me (OS X 10.12.2 / VirtualBox 5.1.14 / Vagrant 1.9.1 / Packer 0.12.2). 👍

[hugo4711]

My problem was similar to what @dusek mentioned above. I tried to use a german ISO which lead to a timeout "Waiting for WinRM to become available..." because in the Autounattend.xml the Lanuage Setting and also the Windows Version String in the Tag was not what the installer provided, so the installation did not finish.

Correcting all the differences in the Autounattend.xml fixed this problem for me.