Breaking syntax changes in Packer v1.13 for Windows build templates

[angaaruriakhil]

Description

We perform builds of these images using agents that have the latest version of Packer installed (via install-packer.sh).

We recently upgraded to Packer v1.13.

This has broken our Windows builds using the packer templates present in this repository. It fails on the very first step:

Code

  provisioner "powershell" {
    inline = [
      "New-Item -Path ${var.image_folder} -ItemType Directory -Force",
      "New-Item -Path ${var.temp_dir} -ItemType Directory -Force"
    ]
  }

Error

==> azure-arm.build_vhd: Provisioning with powershell script: /tmp/powershell-provisioner534343087
==> azure-arm.build_vhd:
==> azure-arm.build_vhd: C:\Windows\Temp\script-68403835-d153-9b9c-b9f3-59412845eb52.ps1 : An error occurred: Cannot bind parameter because
==> azure-arm.build_vhd: parameter 'Path' is specified more than once. To provide multiple values to parameters that can accept multiple
==> azure-arm.build_vhd: values, use the array syntax. For example, "-parameter value1,value2,value3".
==> azure-arm.build_vhd:     + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
==> azure-arm.build_vhd:     + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,script-68403835-d153-9b9c-b9f3-5941284
==> azure-arm.build_vhd:    5eb52.ps1
==> azure-arm.build_vhd:

If we look at the release notes for v1.13 we can see that some changes were made to the syntax required for uploading directories.

core: Updated the documentation to explicitly state that a trailing slash is required when uploading directories, regardless of the guest OS.
This clarification is intended to ensure consistent behavior and prevent confusion, especially for Windows users.
https://github.com/hashicorp/packer/pull/13309

I'm not sure if the above is the breaking change or there is a bug in the new Packer version.

As a workaround we are installing Packer v1.12 in our pipelines and removing 1.13.

If the changes are intentional from Packer's side, are there plans to update the syntax of the Windows templates to be compatible with Packer v1.13 so that builds can continue to be executed?

Thanks!

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 22.04
• Ubuntu 24.04
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

Image version and build link

N/A - Building image from this repo

Is it regression?

Yes

Expected behavior

First step of Windows build should pass with:

=> azure-arm.build_vhd: Provisioning with powershell script: /tmp/powershell-provisioner3329247378
    azure-arm.build_vhd:
    azure-arm.build_vhd:
    azure-arm.build_vhd:     Directory: C:\
    azure-arm.build_vhd:
    azure-arm.build_vhd:
    azure-arm.build_vhd: Mode                 LastWriteTime         Length Name
    azure-arm.build_vhd: ----                 -------------         ------ ----
    azure-arm.build_vhd: d-----          6/4/2025  12:55 PM                image
    azure-arm.build_vhd:
    azure-arm.build_vhd:
    azure-arm.build_vhd:     Directory: C:\Users\packer\AppData\Local
    azure-arm.build_vhd:
    azure-arm.build_vhd:
    azure-arm.build_vhd: Mode                 LastWriteTime         Length Name
    azure-arm.build_vhd: ----                 -------------         ------ ----
    azure-arm.build_vhd: d-----          6/4/2025  12:55 PM                Temp

Actual behavior

Error

==> azure-arm.build_vhd: Provisioning with powershell script: /tmp/powershell-provisioner534343087
==> azure-arm.build_vhd:
==> azure-arm.build_vhd: C:\Windows\Temp\script-68403835-d153-9b9c-b9f3-59412845eb52.ps1 : An error occurred: Cannot bind parameter because
==> azure-arm.build_vhd: parameter 'Path' is specified more than once. To provide multiple values to parameters that can accept multiple
==> azure-arm.build_vhd: values, use the array syntax. For example, "-parameter value1,value2,value3".
==> azure-arm.build_vhd:     + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
==> azure-arm.build_vhd:     + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,script-68403835-d153-9b9c-b9f3-5941284
==> azure-arm.build_vhd:    5eb52.ps1
==> azure-arm.build_vhd:

Repro steps

Clone down runner images repo
Run packer build of any Windows OS with build agent that has Packer v1.13 installed

[validis-ad]

We're also experiencing this, Win builds broken for the same reason. Thanks for the investigation @angaaruriakhil

[vidyasagarnimmagaddi]

Hi , @angaaruriakhil ,Thank you for bringing this issue to our attention. We will look into this issue and will update you after investigating.


[raveheart1]

We're seeing the same issue on the Linux version of the latest GitHub Actions runner during image provisioning with Packer:

==> azure-arm.avd_w10: Provisioning with powershell script: scripts/ConfigureRemotingForAnsible.ps1
==> azure-arm.avd_w10: At C:\Windows\Temp\script-684315ba-808c-7a6f-08c8-0b7870d5de83.ps1:3 char:1
==> azure-arm.avd_w10: + [CmdletBinding()]
==> azure-arm.avd_w10: + ~~~~~~~~~~~~~~~~~
==> azure-arm.avd_w10: Unexpected attribute 'CmdletBinding'.
==> azure-arm.avd_w10: At C:\Windows\Temp\script-684315ba-808c-7a6f-08c8-0b7870d5de83.ps1:4 char:1
==> azure-arm.avd_w10: + Param (
==> azure-arm.avd_w10: + ~~~~~
==> azure-arm.avd_w10: Unexpected token 'Param' in expression or statement.
==> azure-arm.avd_w10: At C:\Windows\Temp\script-684315ba-808c-7a6f-08c8-0b7870d5de83.ps1:6 char:30
==> azure-arm.avd_w10: + [int]$CertValidityDays = 1095,
==> azure-arm.avd_w10: + ~~~~
==> azure-arm.avd_w10: The assignment expression is not valid. The input to an assignment operator must be an object that is able to accept
==> azure-arm.avd_w10: assignments, such as a variable or a property.
==> azure-arm.avd_w10: + CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
==> azure-arm.avd_w10: + FullyQualifiedErrorId : UnexpectedAttribute

💡 As a temporary workaround, we're removing [CmdletBinding()], Param() declarations, and simplifying the script body to avoid parameter parsing altogether.

First observed: Friday, June 6th, ~8am EST.

Let us know if others are seeing this or if an upstream fix is in motion.

[kishorekumar-anchala]

Hi @angaaruriakhil - If you're using the runner images codebase, the version is currently being fetched from the Choco package, which contains version 1.12. Once a new version becomes available in the Choco package, we will update accordingly. Thank you!

[angaaruriakhil]

Hi @angaaruriakhil - If you're using the runner images codebase, the version is currently being fetched from the Choco package, which contains version 1.12. Once a new version becomes available in the Choco package, we will update accordingly. Thank you!

Thanks for your response. We're actually using the Ubuntu runners, not Windows, to build our images which uses this script to install Packer. So it installs the latest version.

I understand that Windows runners use Chocolatey to install Packer, and that currently only goes up to v1.12, but it is a moot point to be honest. The reality is the scripts are not compatible with the latest version of Packer which is v1.13, anyone could be using any agent which could have this latest Packer version installed, to build these images. I (personally) don't think that waiting till things become a problem is the best strategy here.

Regardless - they seem to have dropped an update to Packer today (v1.13.1) which apparently fixes some PowerShell execution issues. So it turns out it was probably a bug identified on HashiCorp's side rather than an intentional change.

Will have to test on our next patching round and get back.

[kishorekumar-anchala]

Hi @angaaruriakhil -

Thank you for the information. The new version of Packer (1.13.1) is being rolled out this week, and we will proceed with testing accordingly.

As noted earlier, since this issue is not related to Windows, please raise a new request by selecting the appropriate Ubuntu checkbox when submitting the issue.

We are closing this ticket as it does not pertain to Windows.