--> amazon-ebs: Error processing command: Error generating elevated runner: Error preparing elevated shell script: Error uploading file to $env:TEMP\winrmcp-745f72eb-b955-49e4-5b6b-799c6709af97.tmp: Couldn't create shell: http response error: 401 - invalid content type
If i put that same provisioner as #1 it works so I know the content is fine.
Odd thing is I don't see this behavior with Linux EBS provisioners, so starting to wonder is this a bug with packer winrm or winrm itself ?
Here is a current list of my winrm setting that are passed in through user data.
net user SomeUser GoogleMuck /EXPIRES:NEVER /add
net localgroup administrators SomeUser /add
wmic useraccount where "name='somename'" set PasswordExpires=FALSE
Set-ExecutionPolicy -ExecutionPolicy bypass -Force
netsh advfirewall set allprofiles state off
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="0"}'
winrm set winrm/config '@{MaxTimeoutms="10800000"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
If any one can help truly identify the issue it would extremely helpfull. I have a feeling it is a problem winrm or my above settings but not sure where to start there.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/ead4549c-4591-4b1d-9491-ad32074d2167%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
First Attempt
My first attempt was 13 provisioners, with identical content:
{
"type": "windows-shell",
"inline": [ "REM Provisioner #" ]
},
This completed the full process with zero issues. This rules out my theory that the issue has to do with the mystical "10th Provisioner"
Second Attempt
My second attempt was bumped up to 20 provisioners, and I changed them to powershell with a short 1s sleep:
{
"type": "powershell",
"inline": [ "Write-Output 'Provisioner #'", "Start-Sleep 1"]
},
This also completed with no error.
It seems that it may not be the number of provisioners but maybe the amount of data sent through winrm? Is there a limit on how many elevated prompts can be executed? We were able to confirm however that packer is making the call to the instance on the failed attempt by analyzing network traffic so we know the call gets fired but not sure why it is failing. I am starting to think maybe I am missing an winrm setting or powershell environment setting somewhere? I dont think Packer.io publishes any recommended winrm settings but does anyone have a better set than what I have listed?
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/61af67d0-e741-458e-b5cd-00739c726a78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.