I’m trying to build an AWS AMI for Windows 2016. I’m basing it from an AMI that I have already used to create an instance manually and I could connect to with Remote Desktop.
I’ve tried various parameter combinations but Packer hangs either waiting for WinRM to be ready or (if I set the password explicitly) or waiting for the password to be ready (if the password has been autogenerated).
I see many posts related to this. Is this a know bug or is there a reference configuration that is known to work?
Thanks for any help
Marco
1 Like
Hi!
You’re on the right track with that autounattend docs link, but you don’t need a whole autounattend file because the windows OS is already installed. For AWS, you need to just pass a little script in the user_data_file option, containing code to launch WinRM on your desired port. An example can be found here:
Hope this helps!
Hi @SwampDragons, thanks that looked spot on, but it still hangs.
I’ve tried to change the Packer HCL and use the bootstrap file but I still get:
==> amazon-ebs.windows_hashistack: Prevalidating any provided VPC information
==> amazon-ebs.windows_hashistack: Prevalidating AMI Name: Windows Hashistack 1601485330
amazon-ebs.windows_hashistack: Found Image ID: ami-0fc34d9f0e087b0e2
==> amazon-ebs.windows_hashistack: Creating temporary keypair: packer_5f74ba12-6db5-db62-d773-f20a776eada3
==> amazon-ebs.windows_hashistack: Creating temporary security group for this instance: packer_5f74ba17-ffd4-6c79-6638-579b0b9c6feb
==> amazon-ebs.windows_hashistack: Authorizing access to port 5985 from [0.0.0.0/0] in the temporary security groups…
==> amazon-ebs.windows_hashistack: Launching a source AWS instance…
==> amazon-ebs.windows_hashistack: Adding tags to source instance
amazon-ebs.windows_hashistack: Adding tag: “Name”: “Packer Builder”
amazon-ebs.windows_hashistack: Instance ID: i-035b62f19b08d8e87
==> amazon-ebs.windows_hashistack: Waiting for instance (i-035b62f19b08d8e87) to become ready…
==> amazon-ebs.windows_hashistack: Skipping waiting for password since WinRM password set…
==> amazon-ebs.windows_hashistack: Using winrm communicator to connect: 10.241.239.140
==> amazon-ebs.windows_hashistack: Waiting for WinRM to become available…
1 Like
It might be an AWS issue as I cannot even get the password manually from the EC2 dashboard…
Did you use the example password SuperS3cr3t!!!! and set it in your HCL? If not, make sure you’ve properly modified that script to set the correct password. I’m not sure you’re able to retrieve a password manually from the ec2 dashboard if you set it via a script like this, so that’s not all that surprising.
It’s normal for it to take a few minutes waiting for WinRM to become available – does it hang for a long time until a timeout?
While it is waiting, are you able to connect via RDP to confirm that the instance is up?
Are there VPC settings you haven’t set in your Packer config?
Does the instance require https and/or NTLM? That configuration example is as bare-bones as possible. As such it is insecure and won’t work if you have certain hardening rules in place.
I did use SuperS3cr3t!!!! but didn’t work.
The base AMI I’m using is derived from another Windows 2016 AMI. In the base AMI I’ve generated a password with an AWS keypair. AWS Support explained that I could not login to the new AMI because it’s not possible to generate a new password on a derived AMI. I need to keep using the base password. In fact using the base password on a manually instanced AMI from the base one, works. So maybe Packer hangs because it cannot generate a new password? I’ve tried the base AMI password in the HCL but it hangs in the same way. And waits forever until it timeouts.
I’m not able to connect via RDP while waiting, which is strange because I can do it on the base AMI.
All VPC settings should be ok, because I can generate a Linux AMI with Packer. Just not with Windows. This is a private VPC I’m connecting to with the corporate VPN.
I’m not sure what other requirements are needed. Since it cannot connect with WinRM it does not even start to install my packages.
See below my HCL:
variable "region" { default = "us-west-2" }
variable "vpc_id" { default = "vpc-XXX" }
variable "subnet_id" { default = "subnet-XXX" }
source "amazon-ebs" "windows_hashistack" {
ami_name = "Windows Hashistack {{timestamp}}"
region = var.region
vpc_id = var.vpc_id
subnet_id = var.subnet_id
instance_type = "t2.medium"
# Source AMI has been derived from another AMI. I've generated a password using a keypair for this
source_ami = "ami-0c383e1605d38a941"
user_data_file = "./windows_scripts/bootstrap_win.txt"
communicator = "winrm"
winrm_username = "Administrator"
# Password generated on the base instance with the mykeypair.pem
winrm_password = "tk(&oWEKXZcH.JXtzvfknF;arklFZg=E"
ami_groups = ["all"]
tags = {
OS_Version = "Windows 2016"
Architecture = "amd64"
}
}
build {
sources = [
"source.amazon-ebs.windows_hashistack"
]
provisioner "powershell" {
scripts = [
"./windows_scripts/disable-uac.ps1",
"./windows_scripts/install_nomad_consul.ps1"
]
}
// Need to restart after installing Docker
provisioner "windows-restart" {}
}
and this is the bootstrap_win.txt (note I’ve commented the password because I’m using the base AMI password. Even setting SuperS3cr3t!!! does not work):
<powershell>
# Set administrator password
#net user Administrator SuperS3cr3t!!!!
#wmic useraccount where "name='Administrator'" set PasswordExpires=FALSE
# First, make sure WinRM can't be connected to
netsh advfirewall firewall set rule name="Windows Remote Management (HTTP-In)" new enable=yes action=block
# Delete any existing WinRM listeners
winrm delete winrm/config/listener?Address=*+Transport=HTTP 2>$Null
winrm delete winrm/config/listener?Address=*+Transport=HTTPS 2>$Null
# Disable group policies which block basic authentication and unencrypted login
Set-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\WinRM\Client -Name AllowBasic -Value 1
Set-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\WinRM\Client -Name AllowUnencryptedTraffic -Value 1
Set-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\WinRM\Service -Name AllowBasic -Value 1
Set-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\WinRM\Service -Name AllowUnencryptedTraffic -Value 1
# Create a new WinRM listener and configure
winrm create winrm/config/listener?Address=*+Transport=HTTP
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="0"}'
winrm set winrm/config '@{MaxTimeoutms="7200000"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/service '@{MaxConcurrentOperationsPerUser="12000"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
winrm set winrm/config/client/auth '@{Basic="true"}'
# Configure UAC to allow privilege elevation in remote shells
$Key = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
$Setting = 'LocalAccountTokenFilterPolicy'
Set-ItemProperty -Path $Key -Name $Setting -Value 1 -Force
# Configure and restart the WinRM Service; Enable the required firewall exception
Stop-Service -Name WinRM
Set-Service -Name WinRM -StartupType Automatic
netsh advfirewall firewall set rule name="Windows Remote Management (HTTP-In)" new action=allow localip=any remoteip=any
Start-Service -Name WinRM
</powershell>
1 Like
I made some progress. If I use a base AMI that has not been derived already, the SuperS3cr3t!!!! password thing works.
I see script being installed but it complains about double quotes in the script
==> amazon-ebs.windows_hashistack: Provisioning with powershell script: ./windows_scripts/install_nomad_consul.ps1
==> amazon-ebs.windows_hashistack: At C:\Windows\Temp\script-5f761af2-d62b-0849-d4b2-83c1d6a0e2bd.ps1:24 char:111
==> amazon-ebs.windows_hashistack: + ... t-api.hashicorp.com/v1/check/nomad | jq -r ".current_version"' '2>&1'
==> amazon-ebs.windows_hashistack: + ~~~~~~~~~
==> amazon-ebs.windows_hashistack: The string is missing the terminator: ".
==> amazon-ebs.windows_hashistack: + CategoryInfo : ParserError: (:) [], ParseException
==> amazon-ebs.windows_hashistack: + FullyQualifiedErrorId : TerminatorExpectedAtEndOfString
==> amazon-ebs.windows_hashistack:
Note that it complains about line 24, but line 23 is very similar
I don’t understand when/how to use single or double quotes
Okay, good to know that you can get it working in an unmodified AMI. I assume that in the derived AMIs, you’ve tried using that user_data_file with the user/password commented out, and then provided your special generated AWS password as the winrm_password to Packer?
Are you using the winrm_username Administrator or some other one? I’ve had issues getting non-administrator users to work in the past. I think at a minimum your user connecting via winRM has to be part of the administrators group.
As for your new issue, that looks like an issue with your Powershell script and not with Packer – Packer just uploads the script and calls it with Powershell; it doesn’t read or understand what you’re doing. I’d recommend trying to connect to your instance via RDP or the console, and run it manually to make sure the script is in good working order before you try to run it with Packer.
Yes it’s Administrator.
The latter issue was that apparently there was a dash character represented as Unicode that would confuse encoding in Packer…
After lots of trial and error I replaced the dash character and it worked…
I’ll leave this here for posteriority:
One reason Packer might hang is that AWS will generate one password (we knew that) at launch thats it. What I (might) add is that you can tell AWS to generate another password at the next boot: see this.
That way, you can add a Powershell script that triggers EC2Launch to generate a new password at boot by modifying a json file.
==>
# this a snippet from the script we run
$launchConfig.setComputerName = $true
$launchConfig.handleUserData = $true
$launchConfig.adminPasswordType = 'Random'
With something like this, I was able to build AMIs on top of existing AMIs.
Hope this helps anyone, anywhere! Might even be worth adding as a hint in the hang message (maybe?) ?
Cheers
We are encountering a similar or perhaps the exact issue. We have a source ami we built that has some tools we had to manually install (because they only have GUI installation). In trying to use this as our source ami we hang at this same “Waiting for WinRM to become available…” for 31 minutes and 5 seconds before it times out. Is there a way to shorten that timeout?
We will try to use the Administrator password that was generated by AWS when we made the instance this source ami was based off.
Another tip here, if you change the password from SuperS3cr3t!!! (on AWS) make sure to use a complex enough password with numbers, a good length and also a special character. Otherwise the password wont be accepted in the boot script and you it will hang at this WinRM step as well.
I faced this problem, but it was due to not using the default VPC - I had to grant it a public IP using associate_public_ip_address = true
