endless "Waiting for WinRM to become available"

[shurick81]

I have got a fresh Windows 10 x64 on my host machine.

First, I install dependencies in PowerShell. Packer:

$releaseZipUrl = "https://releases.hashicorp.com/packer/1.1.0/packer_1.1.0_windows_amd64.zip?_ga=2.126128971.795379335.1507324222-290923388.1505150799"
$zipFile = "$env:TEMP\packer_1.1.0_windows_amd64.zip"
Start-BitsTransfer -Source $releaseZipUrl -Destination $zipFile
$targetFolder = "$env:ProgramFiles\Packer"
[System.Reflection.Assembly]::LoadWithPartialName( 'System.IO.Compression.FileSystem' ) | Out-Null
[System.IO.Compression.ZipFile]::ExtractToDirectory( $zipFile, "$targetFolder" )
$env:Path="$env:Path;$targetFolder"
[Environment]::SetEnvironmentVariable("Path", $env:Path, [EnvironmentVariableTarget]::Machine)

VirtualBox:

$releaseExeUrl = "http://download.virtualbox.org/virtualbox/5.1.28/VirtualBox-5.1.28-117968-Win.exe"
$exeFile = "$env:TEMP\VirtualBox-5.1.28-117968-Win.exe"
Start-BitsTransfer -Source $releaseExeUrl -Destination $exeFile 
Start-Process $exeFile -Wait -ArgumentList "--silent"

Chef SDK:

$releaseMsiUrl = "https://packages.chef.io/files/stable/chefdk/2.3.4/windows/2012r2/chefdk-2.3.4-1-x64.msi"
$msiFile = "$env:TEMP\chefdk-2.3.4-1-x64.msi"
Start-BitsTransfer -Source $releaseMsiUrl -Destination $msiFile
Start-Process msiexec.exe -Wait -ArgumentList "/I $msiFile /quiet"

Git:

$releaseExeUrl = "https://github.com/git-for-windows/git/releases/download/v2.14.2.windows.2/Git-2.14.2.2-64-bit.exe"
$exeFile = "$env:TEMP\Git-2.14.2.2-64-bit.exe"
Invoke-RestMethod -Uri $releaseExeUrl -OutFile $exeFile
Start-Process $exeFile -Wait -ArgumentList "/SILENT"

Then I open a new cmd window to clone and run the project:

cd \
md projects
cd projects
md projects-packer-templates
cd projects-packer-templates
git clone https://github.com/mwrock/packer-templates.git c:\projects\projects-packer-templates
cd cookbooks/packer-templates
berks vendor ../../vendor/cookbooks
cd ..\..
packer build -force -only virtualbox-iso .\vbox-2012r2.json

As a result, it endeavors on following stage: So it opens the virtual machine but never continues provisioning.

[shurick81]

However, when I run vbox-2016.json, it works as expected and I get image prepared:

The sequence for this one is almost the same as for Win 2012 R2:

cd c:\projects\projects-packer-templates
Remove-item .\cookbooks\packer-templates\Berksfile.lock
cd cookbooks/packer-templates
berks vendor ../../vendor/cookbooks
cd ..\..
packer build -force -only virtualbox-iso .\vbox-2016.json

[shurick81]

After some time it actually fails with timeout. However, the machine was fully alive and responsive...

[eeevans]

@shurick81, I've had similar experiences creating a Windows 10 box on Hyper-V. One of the things I found is that it is not able to run the a:\winrm.ps1 file as the ExecutionPolicy is not set so that it can be run. Even after setting the ExecutionPolicy to unrestriced for the machine however, it still runs with errors. If I run the commands manually in a powershell window, it completes correctly and the packer build continues. Hope this helps.

[ilovemysillybanana]

@eeevans did you ever find a solution for this?

[eeevans]

@ilovemysillybanana yes, I renamed it to winrm.bat and removed the single quotes from the set commands and changed the entry in the floppy_files section.

I'm just now creating the box again as my 90 days are about up and ran into this again and luckily found this post again or else I would have tried a couple of more days before discovering the solution again.

[Vagrantin]

I'm experiencing the same issue on a windows server 2012 R2 box, and I checked winRM is properly running, and the script could run properly as well…

Anyone found the root cause, of this issue ?

[its-saurabhjain]

I am facing similar issues, with Windows 2012R2 and Windows 2016 VM on Hyper-V with host OS as windows 10. The same scripts worked some 1 week back and today none is working. Started to feel that Packer is unreliable and if it is worth spending time on fixing issues which could have been abstracted...Need to evaluate other tools now..

[Joohansson]

I was facing the same win Win server 2019. I followed the exact windows guide here: https://packer.io/intro/getting-started/build-image.html

Solved it by skipping setting the password:

• Removed the "set admin password" in bootstrap_win.txt
• Removed "winrm_password" from the packer json file (kept the winrm_username)

Now the packer will actually wait for the real password to become available which take about 5-10min and automatically use that for the winrm connection! Maybe not the best solution, but it works.

[msrinivascharan]

My case, increased WinRM connection time out ("winrm_timeout": "30m") to 30m from 2m. it didn't took 30 mins. and successful.

[vedat227]

in my case it was firewall issue. port "5986" is blocked on firewall. I updated bootstrap script to use port 443 and set "winrm_port" to 443 in the json file

[Razique]

If others are still struggling, here's what I ended up using. works fine on server 2019:

<powershell>
  Write-Output "Disabling WinRM over HTTP..."
  Disable-NetFirewallRule -Name "WINRM-HTTP-In-TCP"
  Disable-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC"
  Get-ChildItem WSMan:\Localhost\listener | Remove-Item -Recurse

  Write-Output "Configuring WinRM for HTTPS..."
  Set-Item -Path WSMan:\LocalHost\MaxTimeoutms -Value '1800000'
  Set-Item -Path WSMan:\LocalHost\Shell\MaxMemoryPerShellMB -Value '1024'
  Set-Item -Path WSMan:\LocalHost\Service\AllowUnencrypted -Value 'false'
  Set-Item -Path WSMan:\LocalHost\Service\Auth\Basic -Value 'true'
  Set-Item -Path WSMan:\LocalHost\Service\Auth\CredSSP -Value 'true'

  New-NetFirewallRule -Name "WINRM-HTTPS-In-TCP" `
      -DisplayName "Windows Remote Management (HTTPS-In)" `
      -Description "Inbound rule for Windows Remote Management via WS-Management. [TCP 5986]" `
      -Group "Windows Remote Management" `
      -Program "System" `
      -Protocol TCP `
      -LocalPort "5986" `
      -Action Allow `
      -Profile Domain,Private

  # New-NetFirewallRule -Name "WINRM-HTTPS-In-TCP-PUBLIC" `
  #     -DisplayName "Windows Remote Management (HTTPS-In)" `
  #     -Description "Inbound rule for Windows Remote Management via WS-Management. [TCP 5986]" `
  #     -Group "Windows Remote Management" `
  #     -Program "System" `
  #     -Protocol TCP `
  #     -LocalPort "5986" `
  #     -Action Allow `
  #     -Profile Public

  $Hostname = [System.Net.Dns]::GetHostByName((hostname)).HostName.ToUpper()
  $pfx = New-SelfSignedCertificate -CertstoreLocation Cert:\LocalMachine\My -DnsName $Hostname
  $certThumbprint = $pfx.Thumbprint
  $certSubjectName = $pfx.SubjectName.Name.TrimStart("CN = ").Trim()

  New-Item -Path WSMan:\LocalHost\Listener -Address * -Transport HTTPS -Hostname $certSubjectName -CertificateThumbPrint $certThumbprint -Port "5986" -force

  Write-Output "Restarting WinRM Service..."
  Stop-Service WinRM
  Set-Service WinRM -StartupType "Automatic"
  Start-Service WinRM
</powershell>

[Qflament]

I have the same problem with Windows 10 and i have no more idea. Did you find an other solution to create a VM ? or did you find a new way to connect winrm? thank for your help

[pavelterex]

@Qflament recently I was also struggling with deployment of Windows 10 which was always hanging on infinite "Waiting for WinRM" no matter what I did. Meanwhile Win Server 2022 with same Communicator settings did not have such problem and WinRM got detected almost instantly.

Interesting fact was that actually on Windows 10 WinRM was accessible from outside and I was able to perform any actions, but still packer was waiting fro WinRM anyway.

After several attempts of investigation I found that problem was in Network type which was Public (I already had Firewall disabled for all types of network) and winrm configuration was not properly applied. I added this line in bootstrap script BEFORE "winrm quickconfig -quiet"

# Switch any existing Public connections to Private
Get-NetConnectionProfile -NetworkCategory Public | Set-NetConnectionProfile -NetworkCategory Private

and it totally solved the problem - WinRM gets detected instantly

2024-02-12T12:59:49+01:00: ==> vsphere-iso.windows-desktop-pro: Waiting for WinRM to become available...
2024-02-12T12:59:58+01:00:     vsphere-iso.windows-desktop-pro: WinRM connected.
2024-02-12T12:59:58+01:00: ==> vsphere-iso.windows-desktop-pro: Connected to WinRM!