latest vagrant image for windows 2016 has firewall closed for winrm

[dogfish182]

port 5986 is blocked by the windows firewall which is on after provisioning.

port 5985 has firewall rule.
port 5986 has no corresponding rule, therefore the system is only ansible managed after you login and disable the firewall.

works with port 5985 fine, but this doesn't match whats written here

https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general_windows.html#create-a-windows-server-in-a-vm

my working config is as follows. Note that I provision a second network card in virtualbox (host only adapter) and connect directly to it, therefore I use the actual port and not the local redirect over
ansible_host: 127.0.0.1 as suggested by your link.

ansible_user: vagrant
ansible_password: vagrant
ansible_port: 5985
ansible_connection: winrm
ansible_winrm_transport:  ntlm
ansible_winrm_server_cert_validation: ignore

[jborean93]

@dogfish182 this was an issue with the 0.3.0 images, 0.4.0 included a fix which created the https firewall rule. Please let me know if that is not the case.

[dogfish182]

this is very strange... I just had a colleague use the box for the first time today (and perform the download) and got the issue I described.
I'm checking it now and it seems you are right on my installation (which is at latest now) I'm confused, but this is indeed working. Thanks for the quick feedback!

[dogfish182]

just reconfimed this is an issue on

jborean93/WindowsServer2016 (virtualbox, 0.4.0)

freshly downloaded the new box and ran it via molecule, system is blocked by the firewall for 5986. (no rule present).

edit: I'm using this box with molecule and on the 3rd deploy of the same box, the firewall is open for this port. I'm pretty sure that its sometimes setting the firewall and sometimes not.

[dogfish182]

might be a bit closer to the cause here. I think if the box is under provisioned in vagrant (not enough ram) then some tasks are failing or timing out and that may be the result, I've not been able to figure out exactly when the firewall port doesn't get added but since I have set 4GB of RAM for this box, it seems to be working reliably. figure it's worth adding this to the issue prior to closing.

EDIT: reopened, failing to provision the firewall doesn't seem to be memory bound, it's definitely failing in some cases making this unreliable to use with something like molecule at the moment.

[jborean93]

Weird, I haven't come across this issue, I usually start my VMs with 2GB of RAM but have done 1GB before. One thing it could be is that part of the sysprep startup process it runs Reset-WinRMConfig as defined at https://github.com/jborean93/packer-windoze/blob/master/roles/sysprep/files/PackerWindoze.psm1. Because the firewall rule step is run after the listener is activated, WinRM is enabled and accessible (over 5985) and Vagrant will continue on with it's next task. If Vagrant then does something like set the hostname, there could be a race condition where the hostname is set, Vagrant reboots the box before the HTTPS firewall step is reached. I can probably fix that by creating the HTTPS firewall rule before the listener.

[dogfish182]

actually I think you're right. I did a few deployments yesterday and I see the script running with reseting winrm, then setting https listener, but indeed 'you are about to be signed out' and the machine reboots either during or just after that finishes. seems to be a race condition indeed.

[jborean93]

Cool thanks for the confirmation, will fix up the order in the next release

[jborean93]

@dogfish182 I've just recently commited some changes 3dc07ea that is designed to make this step a bit more resilient. I've reordered the operations but I've also changed it so a global deny firewall rule will stop Vagrant from continuing on until the WinRM configuration step is mostly complete. The only remaining step is the test of the WInRM configuration but that's nothing too critical and relies on the Firewall to be open to actually test out.

I'm planning on building a new set of boxes shortly which should contain this fix.

[jborean93]

The latest Vagrant images at 0.5.0 have been released and contain the updates setup logic. I've tested them multiple times and can confirm that Vagrant waits until the setup is done before starting it's process.