WinRM connection failure using Powershell Core

[Dan W]

Hello, I am currently using an automated pipeline to deploy Virtual Machines using Packer, Terraform and Ansible.

Details

• Linux VMs as build agents
• Powershell Core 6.1.1
• WinRM into Windows Machines using the Packer communicator
  

I have not had any success yet, I am using the Azure-Arm builder, so i will try a local builder as a workaround.

Is this possibly a communicator problem where Packer expects Powershell to be on a Windows Operating System? I know the WinRM implementation uses https://github.com/masterzen/winrm

Any help would be appreciated.

Thanks

Dan

[Dan W]

I also tried running PACKER_LOG=1 and the system just freezes at this step

2018/11/27 22:08:21 ***: 2018/11/27 22:08:21 TempComputeName=

2018/11/27 22:08:21 ***: 2018/11/27 22:08:21 TempResourceGroupName=

2018/11/27 22:08:21 ***: 2018/11/27 22:08:21 BuildResourceGroupName=***

2018/11/27 22:08:21 ***: 2018/11/27 22:08:21 CloudEnvironmentName=Public

2018/11/27 22:08:21 ***: 2018/11/27 22:08:21 VirtualNetworkName=

2018/11/27 22:08:21 ***: 2018/11/27 22:08:21 VirtualNetworkSubnetName=

2018/11/27 22:08:21 ***: 2018/11/27 22:08:21 VirtualNetworkResourceGroupName=

2018/11/27 22:08:21 ***: 2018/11/27 22:08:21 CustomDataFile=

2018/11/27 22:08:21 ***: 2018/11/27 22:08:21 OSType=Windows

2018/11/27 22:08:21 ***: 2018/11/27 22:08:21 UserName=***

2018/11/27 22:08:21 ***: 2018/11/27 22:08:21 Password=********************************

azure-arm: Creating Azure Resource Manager (ARM) client ...

2018/11/27 22:08:22 ***: 2018/11/27 22:08:22 Azure request method="GET" request="https://management.azure.com/subscriptions/***/resourceGroups/***/providers/Microsoft.Compute/images?api-version=2017-

[Megan Marsh]

You're absolutely right -- the Powershell provisioner assumes you're on windows. 

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/d6a05267-3fc8-4a7a-a197-fced47342cd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Megan Marsh]

And so does the WinRM communicator. If you want to provision a linux vm you're going to need to use the SSH communicatior.

[Justin DynamicD]

I'm actually doing this as we speak without issue, and there is no need to install powershell core locally on the control node.

On the azure-arm builder, just declare a few extra vars to connect to Windows:

"os_type": "Windows",

"communicator": "winrm",

"winrm_username": "packer",

"winrm_use_ssl": true,

"winrm_insecure": true

"os_type" will tell azure to create a packer account on the windows instance, add a certificate, and prep WinRM to listen via NTLM.  winrm_insecure just lets packer know that the cert is self-signed.  

After that the toughest part is injecting your ansible playbook.  I found the community supported ansible-remote plug-ins to be terrible, and instead rely on shell-local to kick-off an ansible play.

[Jordan Borean]

Just an FYI, the winrm connection is not related to PowerShell in any way and it uses something called Windows Remote Shell (WinRS) to create a basic shell and execute commands.. There is PowerShell remoting which operates over the WSMan protocol but it is different from how Packer, and most third party apps, connects to Windows hosts.

[Dan W]

I actually have this exact WINRM configuration in my JSON.

 "builders" : [{

    "type": "azure-arm",

    "client_id": "{{user `client_id`}}",

    "client_secret": "{{user `client_secret`}}",

    "subscription_id": "{{user `subscription_id`}}",

    "tenant_id": "{{user `tenant_id`}}",

    "managed_image_name" : "{{user `tag`}}",

    "managed_image_resource_group_name" : "{{user `image_resource_group`}}",

    "custom_managed_image_resource_group_name" : "{{user `image_resource_group`}}",

    "custom_managed_image_name": "{{user `base_image`}}",

    "build_resource_group_name" : "{{user `image_resource_group`}}",

    "vm_size": "Standard_D4_v3",

    "os_type": "{{user `os_type`}}",

    "os_disk_size_gb": "{{user `disk_size`}}",

    "communicator": "winrm",

    "winrm_use_ssl": true,

    "winrm_insecure": true,

    "winrm_timeout": "10m",

    "winrm_username": "packer"

  }],

The Linux Build Agent running packer is timing out with these settings.

[Dan W]

Is it possible to use do what I am asking?

1. Ubuntu running Packer
   
2. Deploying an Azure-ARM builder
3. Ubuntu VM WinRS into Windows VM

[Jordan Borean]

I don't see why not. You will need to make sure you are configuring WinRM on your Azure host through something like an Azure extension https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/features-windows. I see you are using SSL so are you creating the https listener yourself?

[Dan W]

On Thursday, 29 November 2018 14:55:24 UTC-5, Jordan Borean wrote:

I don't see why not. You will need to make sure you are configuring WinRM on your Azure host through something like an Azure extension https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/features-windows. I see you are using SSL so are you creating the https listener yourself?

Azure-Arm builder does that for you dynamically

https://www.packer.io/docs/builders/azure.html - Windows Section

I believe your information about the Windows Remote Shell and the implementation being baked right into Packer has helped me determine the problem.