amazon-ebs: error uploading powershell script after sysprep

[ShawnHardwick]

Overview of the Issue

When using the amazon-ebs as a source and using the powershell provisioner as part of the build where the script uses EC2Launch v2 to sysprep the EC2 instance, the script executes successfully, but returns the below error:
Error uploading script: Error uploading file to $env:TEMP\winrmcp-b32cf09e-51da-4e4f-5fcb-b10876fa546e.tmp: Couldn't create shell: http response error: 401 - invalid content type

Reproduction Steps

• Download Packer build files from URL below
  • Add own security groups, VPC ID, Subnet IDs for own AWS account
• Execute packer build .
• Observe that Sysprep.ps1 executes successfully, but error is returned

Plugin and Packer version

From packer version
Packer v1.14.3

Simplified Packer Buildfile

https://gist.github.com/ShawnHardwick/7f448a0d00a0e61ced496eb14a873383

Operating system and Environment details

Ubuntu Jammy (22.04)

Log Fragments and crash.log files

Split into three different executions:

• AWS Plugin 1.4.0
• AWS Plugin 1.5.0
• AWS Plugin 1.8.0

https://gist.github.com/ShawnHardwick/16ea978be8634ad1d45012864fa698d5

Detailed information about the issue

#601 in 1.5.0 of the Amazon Packer plugin incremented the Packer plugin SDK which incorporated this change hashicorp/packer-plugin-sdk#298.

The general workflow when using the Powershell provisioner is that Packer will create a temporary script file on the remote host, execute the script and then send follow up commands to clean up this temporary file.

When running sysprep via EC2Launch v2, new WinRM connections by Packer are inaccessible so once the script is complete, Packer should not be expected to send any more WinRM commands.

Pre-1.5.0, the Packer PowerShell provisioner would attempt to clean up the Powershell script file, but fail. Attempting multiple times, but eventually giving up and NOT sending a build-ending error.

As of 1.5.0, Packer executes similarly but sends a build-ending error.

skip_clean for the Powershell provisioner does not seem to influence this behavior.

Potential Workarounds

• Don't use 1.5.0 and newer of Amazon Packer plugin
• Don't use Powershell provisioner when executing sysprep

[ShawnHardwick]

I don't believe I can reproduce the issue using the below:

  provisioner "powershell" {
    inline = [
      "& 'C:/Program Files/Amazon/EC2Launch/ec2launch' reset --block",
      "& 'C:/Program Files/Amazon/EC2Launch/ec2launch' sysprep --block"
    ]
  }

So it might be a distinction in how inline vs script is handled