Packer stuck on powershell inline script execution with elevated user and password (Windows 11)

[pbk8s]

Description

Hello - I am trying to build a Windows 11 image in Azure using Packer. However, it gets stuck (and hangs forever) in the following block in the process -

provisioner "powershell" { elevated_password = "${var.install_password}" elevated_user = "${var.install_user}" inline = ["bcdedit.exe /set TESTSIGNING ON"] }

If turn the debug mode on, and logon to the generated VM, the provisioner moves forward. Is this an issue with packer or the Windows 11 image?

Truncated logs for reference: 2024/06/24 16:35:06 [INFO] (telemetry) Starting provisioner powershell 2024/06/24 16:35:06 ui: ask: [1;32m==> azure-arm.image: Pausing before the next provisioner . Press enter to continue.[0m 2024/06/24 16:35:14 ui: [1;32m==> azure-arm.image: Provisioning with Powershell...[0m 2024/06/24 16:35:14 packer-provisioner-powershell plugin: Found command: bcdedit.exe /set TESTSIGNING ON 2024/06/24 16:35:14 ui: [1;32m==> azure-arm.image: Provisioning with powershell script: /var/folders/5x/svs_vb1176z145f7xkf11vp00000gn/T/powershell-provisioner2771910820[0m 2024/06/24 16:35:14 packer-provisioner-powershell plugin: Opening /var/folders/5x/svs_vb1176z145f7xkf11vp00000gn/T/powershell-provisioner2771910820 for reading 2024/06/24 16:35:14 packer-provisioner-powershell plugin: Uploading env vars to c:/Windows/Temp/packer-ps-env-vars-667a02b2-c8c2-b442-48fe-0f5b88b458ed.ps1 2024/06/24 16:35:14 packer-provisioner-powershell plugin: [INFO] 70 bytes written for 'uploadData' 2024/06/24 16:35:14 [INFO] 70 bytes written for 'uploadData' 2024/06/24 16:35:14 packer-plugin-azure_v1.4.5_x5.0_darwin_arm64 plugin: 2024/06/24 16:35:14 Uploading file to 'c:/Windows/Temp/packer-ps-env-vars-667a02b2-c8c2-b442-48fe-0f5b88b458ed.ps1' 2024/06/24 16:35:16 packer-provisioner-powershell plugin: Building elevated command wrapper for: powershell -executionpolicy bypass "& { if (Test-Path variable:global:ProgressPreference){set-variable -name variable:global:ProgressPreference -value 'SilentlyContinue'};. c:/Windows/Temp/packer-ps-env-vars-667a02b2-c8c2-b442-48fe-0f5b88b458ed.ps1; &'c:/Windows/Temp/script-667a02b2-880a-6450-a1df-b2311f36fd65.ps1'; exit $LastExitCode }" 2024/06/24 16:35:16 packer-provisioner-powershell plugin: Command [powershell -executionpolicy bypass "& { if (Test-Path variable:global:ProgressPreference){set-variable -name variable:global:ProgressPreference -value 'SilentlyContinue'};. c:/Windows/Temp/packer-ps-env-vars-667a02b2-c8c2-b442-48fe-0f5b88b458ed.ps1; &'c:/Windows/Temp/script-667a02b2-880a-6450-a1df-b2311f36fd65.ps1'; exit $LastExitCode }" > %SYSTEMROOT%/Temp/packer-667a02b4-7971-f3df-cb9b-1288138378e8.out 2>&1] converted to [powershell -executionpolicy bypass "& { if (Test-Path variable:global:ProgressPreference){set-variable -name variable:global:ProgressPreference -value 'SilentlyContinue'};. c:/Windows/Temp/packer-ps-env-vars-667a02b2-c8c2-b442-48fe-0f5b88b458ed.ps1; &'c:/Windows/Temp/script-667a02b2-880a-6450-a1df-b2311f36fd65.ps1'; exit $LastExitCode }" > %SYSTEMROOT%/Temp/packer-667a02b4-7971-f3df-cb9b-1288138378e8.out 2>&1] for use in XML string 2024/06/24 16:35:16 packer-provisioner-powershell plugin: Uploading elevated shell wrapper for command [powershell -executionpolicy bypass "& { if (Test-Path variable:global:ProgressPreference){set-variable -name variable:global:ProgressPreference -value 'SilentlyContinue'};. c:/Windows/Temp/packer-ps-env-vars-667a02b2-c8c2-b442-48fe-0f5b88b458ed.ps1; &'c:/Windows/Temp/script-667a02b2-880a-6450-a1df-b2311f36fd65.ps1'; exit $LastExitCode }" > %SYSTEMROOT%/Temp/packer-667a02b4-7971-f3df-cb9b-1288138378e8.out 2>&1] to [C:/Windows/Temp/packer-elevated-shell-667a02b4-a6f2-83bb-8ffe-2232c8f0ccdf.ps1] 2024/06/24 16:35:16 packer-provisioner-powershell plugin: [INFO] 3506 bytes written for 'uploadData' 2024/06/24 16:35:16 [INFO] 3506 bytes written for 'uploadData' 2024/06/24 16:35:16 packer-plugin-azure_v1.4.5_x5.0_darwin_arm64 plugin: 2024/06/24 16:35:16 Uploading file to 'C:/Windows/Temp/packer-elevated-shell-667a02b4-a6f2-83bb-8ffe-2232c8f0ccdf.ps1' 2024/06/24 16:35:17 packer-provisioner-powershell plugin: [INFO] 32 bytes written for 'uploadData' 2024/06/24 16:35:17 [INFO] 32 bytes written for 'uploadData' 2024/06/24 16:35:17 packer-plugin-azure_v1.4.5_x5.0_darwin_arm64 plugin: 2024/06/24 16:35:17 Uploading file to 'c:/Windows/Temp/script-667a02b2-880a-6450-a1df-b2311f36fd65.ps1' 2024/06/24 16:35:19 packer-plugin-azure_v1.4.5_x5.0_darwin_arm64 plugin: 2024/06/24 16:35:19 [INFO] starting remote command: powershell -executionpolicy bypass -file "C:/Windows/Temp/packer-elevated-shell-667a02b4-a6f2-83bb-8ffe-2232c8f0ccdf.ps1"

Platforms affected

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

Runner images affected

• [ ] Ubuntu 20.04
• [ ] Ubuntu 22.04
• [ ] Ubuntu 24.04
• [ ] macOS 11
• [ ] macOS 12
• [ ] macOS 13
• [ ] macOS 13 Arm64
• [ ] macOS 14
• [ ] macOS 14 Arm64
• [ ] Windows Server 2019
• [ ] Windows Server 2022

Image version and build link

Windows 11 Preview - Arm64

Is it regression?

No

Expected behavior

It should not hang indefinitely for logon with elevated_user and password.

Actual behavior

Hangs indefinitely waiting for logon with elevated_user and password.

Repro steps

Execute the following packer build command for a Windows 11 image in Azure - packer build -on-error=ask -debug \ -var "subscription_id=$SubscriptionId" \ -var "client_id=$ClientId" \ -var "client_secret=$ClientSecret" \ -var "location=$Location" \ -var "managed_image_name=$ImageName" \ -var "install_password=$InstallPassword" \ -var "image_version=$ImageVersion" \ -var "managed_image_resource_group_name=$ImageResourceGroupName" \ -var "tenant_id=$TenantId" \ -var "vm_size=$VMsize" \ $TemplatePath

[Prabhatkumar59]

@pbk8s We are looking into the issue, we will get back to you after investigating this issue, Thanks.

[Prabhatkumar59]

@pbk8s , It seems it's an authentication issue. When using Packer to build a Windows 11 image in Azure, the provisioning process with PowerShell gets stuck on the command bcdedit.exe /set TESTSIGNING ON. The issue seems to be related to execution policy restrictions or interactive prompts that aren't handled automatically. Switching to debug mode and manually logging in allows the process to proceed, indicating a possible issue with automated execution or permissions during provisioning. Ensuring the execution policy is set to Bypass and handling any interactive prompts programmatically within the scripts may resolve this issue.

Refer this official documentation how to bypass with execution policy using packer. https://developer.hashicorp.com/packer/docs/provisioners/powershell

[pbk8s]

Thanks @Prabhatkumar59. Yes, I observed the same behavior, in debug mode logging manually makes it go forward. The default execution policy for the provisioner is "bypass", I still tried to add it explicitly but it made no difference. I'll try to handle the interactive prompts within the code. Will keep you updated.

[Prabhatkumar59]

@pbk8s , any update from your end on this?

[pbk8s]

@Prabhatkumar59 I've tried multiple options so far - using scripts to handle the interactive logon, setting the execution policy to "bypass" but still stuck on the same issue. Per the documentation, packer defaults the execution policy to "bypass". Every time I need to manually login to the temp VM and that moves the script along. Is this an issue specific to Windows 11?

[Prabhatkumar59]

@pbk8s - The issue you're encountering doesn't appear to be specific to Windows 11 itself but rather a common challenge when automating tasks in Windows environments, especially during provisioning with tools like Packer. *You can modify your PowerShell script to handle any interactive prompts programmatically. For example, you can use -Confirm:$false or -Force parameters with commands like bcdedit.exe to suppress prompts and allow the script to run without human intervention.

Start-Process -FilePath "bcdedit.exe" -ArgumentList "/set TESTSIGNING ON" -NoNewWindow -Wait -PassThru

• Double-check that the user context used by Packer (${var.install_user} and ${var.install_password}) has sufficient permissions to execute administrative commands like modifying boot settings with bcdedit.

• The issue you're facing with Packer hanging during the provisioning process on Windows 11 doesn't appear to be exclusive to the OS version. It likely stems from interactive prompts or permissions not being handled correctly in your automation setup. Ensure your PowerShell scripts manage interactive commands like bcdedit.exe programmatically, use verbose logging for detailed troubleshooting, verify user permissions, and review Packer configurations thoroughly to resolve the issue effectively.

[pbk8s]

Thanks @Prabhatkumar59. I've the tried the options you suggested and still the same result. I tried the original "bcdedit" command with Windows 2022 and it worked fine without any issues. I did some more digging and it seems like with Windows 11 on Azure, using elevated_user and elevated_password, packer creates a scheduled task that doesn't run until an admin user has logged on to the system. The user in my case is "installer" which is added to the Administrators group prior to this step in the packer file, using the following code block.

provisioner "windows-shell" {
    inline = [
      "net user ${var.install_user} ${var.install_password} /add /passwordchg:no /passwordreq:yes /active:yes /Y",
      "net localgroup Administrators ${var.install_user} /add",
      "winrm set winrm/config/service/auth @{Basic=\"true\"}",
      "winrm get winrm/config/service/auth"
    ]
  }

  provisioner "powershell" {
    inline = ["if (-not ((net localgroup Administrators) -contains '${var.install_user}')) { exit 1 }"]
  }

I've verified by logging on the VM that this user is part of the Administrators group.

[Prabhatkumar59]

@pbk8s - Thanks for your reply. You can try to follow below steps for resolution:- Ensure Immediate Task Execution: You can modify the task creation process to ensure it runs immediately without requiring an admin login. Manual Execution Verification: Verify if manually running the scheduled task after logging in as "installer" resolves the issue. Alternative Execution Method: You can also consider using alternative methods to execute the required commands that do not rely on scheduled tasks, such as direct execution through a different provisioner or script.

[Prabhatkumar59]

@pbk8s - Hope you find the solutions feasible as there is no response from your side, we are closing the issue. thanks

[Fl-Ta]

Hey @pbk8s Were you able to find a solution here?

I encounter the same error that the script only starts and is executed after a login. If I use “win11-23h2-avd”, everything works fine, if I try to adapt it to “win11-23h2-ent”, the error persists.