WinRM timeout caused by public NetworkLocation which disables WinRM

[obilodeau]

WinRM problems with Windows 7 profile

• Windows 7 x86 Pro w/ product key
• packer 0.12.0
• Host: Ubuntu 16.04.1
• Virtual Box: 5.0.24

WinRM is not listening on 5985 after Windows is installed. Manual investigation reveals that network profile is not set properly, WinRM is not configured and not allowed through firewall.

Oddly, this doesn't happen in another environment.

[obilodeau]

It looks as if the enablewinrm.ps1 is not executed. I'll check if it is inside the floppy made by virtualbox and try to trace if it gets executed or not.

[obilodeau]

I can't reproduce on my arch linux host.

• packer 0.12.2
• VirtualBox 5.1.14

[obilodeau]

Running enablewinrm.ps1 by hand on a VM build failure gave:

The script is enablewinrm.ps1:

Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private

winrm quickconfig -q -transport:http
winrm set winrm/config/client '@{AllowUnencrypted="true"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
net stop winrm
netsh advfirewall firewall set rule group="remote administration" new enable=yes
netsh firewall add portopening TCP 5985 "Port 5985"
sc.exe config winrm start=auto
net start winrm

[obilodeau]

The code for setting the network location works but the integration of it doesn't. It's like if it's not running or crashing. I'll have to look at how to call powershell.

I re-ran it from a cmd prompt once Windows started and then reran enablewinrm.ps1 and now everything is ok. But this was interactive. We need it to be automated.

So there's something still missing in the integration...

[obilodeau]

I fixed a typo in the Autounattend.xml script. My previously bugged environment now reaches the same bug as #31 which means this bug is fixed.

I amended the previous commit with the typo fixed so that bisect wouldn't fail on a typo.