HTTP Provisioner - Windows Server

I’m having an issue with the packer provisioner using HTTP, even when the firewalls are off the host VM running Windows Server 2025 cant find the host path hosted by the HTTP Server

It keeps saying either

PACKER_HTTP_URL environment variable is not set or empty when its not

or it says

An error occurred: Invalid URI: The hostname could not be parsed.

Can I get any help with this one ? this is stopping my scripts being downloaded or run.

I validated the environment variables being set during provisioning using the following provisioner block:

provisioner "powershell" {
  inline = [
    "Get-ChildItem Env: | Sort-Object Name | Format-Table Name,Value -AutoSize"
  ]
}

This confirmed I was referencing the correct variables, specifically PACKER_HTTP_ADDR. However, despite using the correct variable, it is not being translated or passed into the OS environment during provisioning as expected.

I’ve also confirmed that the Windows Firewall is fully disabled to rule out local interference, yet I’m still encountering consistent errors such as “unable to reach URI”. Additionally, I discovered a nearly identical issue already reported on Packer’s GitHub back in April, suggesting this could be a broader problem with how contextual variables are injected into the guest environment.

To aid visibility, here’s the current PowerShell inline provisioner I’m attempting to use (which still fails):

# Extract and prepare IP/port
"$urlRoot = \"http://$env:PACKER_HTTP_ADDR\"",
"$ip, $port = $env:PACKER_HTTP_ADDR -split ':'",

# Open Windows Firewall inbound + outbound for dynamic HTTP port
"New-NetFirewallRule -DisplayName 'Packer HTTP Inbound' -Direction Inbound -Action Allow -RemoteAddress $ip -Protocol TCP -LocalPort $port",
"New-NetFirewallRule -DisplayName 'Packer HTTP Outbound' -Direction Outbound -Action Allow -RemoteAddress $ip -Protocol TCP -RemotePort $port",

# Corrected echo with subexpression
"Write-Host \"Firewall rules created for Packer HTTP on $($ip):$($port)\""

This code should dynamically open the required ports for the HTTP server started by Packer’s built-in http_directory mechanism, but it currently fails due to the $env:PACKER_HTTP_ADDR variable not resolving inside the provisioned environment.