AWS ec2 Sysprep fails

Packer
#1

Packer v1.7.10

This just started recently where sysprep isn’t completing correctly. It appears that the SysprepInstance.ps1 -NoShutdown is not completing. This is causing the new AMI to break. The AMi is in a unrecoverable state.

This is the last line of the packer script.
{
“type”: “powershell”,
“inline”: [
“C:/ProgramData/Amazon/EC2-Windows/Launch/Scripts/InitializeInstance.ps1 -Schedule”,
“C:/ProgramData/Amazon/EC2-Windows/Launch/Scripts/SysprepInstance.ps1 -NoShutdown”
]

#2

Strangely enough, I’m seeing the same behavior in my environment, in AWS, when doing the sysprep step through Ansible over Packer. I’ve been thinking of switching to using the powershell provisionier, via Packer directly, just like you mention in your example. For me, things worked just fine until maybe mid-January.

#3

Yes, I run builds monthly and it decided to stop working in Feb. The very strange thing is that when I use the 2019 Windows image it works fine. Some reason 2016 just does not work. I’ve been trying older versions of Packer and those don’t seem to work.

#4

For me, this happens on Windows Server 2019. I’m no longer building 2016, so I can’t say how it goes there. The other strange thing is that after a few failed attempts, it suddenly works, then it starts failing again, then it works for once, and so on.

#5

Did anyone ever find a resolution to this? Can confirm we’re seeing it on the most recent AWS AMIs for Windows Server 2016 and 2019

#6

I found if the Windows instance needs a reboot due to the configuration of the AMI, Sysprep fails. So I added a “reboot if required” at the end of my Ansible playbook, with a 2 min delay to allow the instance to be completely restarted before running Sysprep, then it worked again. I also found some articles about updates causing issues but did not have to dig into that.

#7

Changing the instance type did the trick for me. All builds completed successfully when I went with a different instance type.

#8

Here’s what I had to do to get it to work. Sometimes just calling sysprep with the generalize/oobe would work, other times it wouldn’t. I think it was a timing thing on when it closed sysprep vs. when it was actually completed.

    {
      "type": "powershell",
      "elevated_user": "SYSTEM",
      "elevated_password": "",
      "inline": [
        "echo '>>> Sysprepping VM ...'",
        "If ((Get-Item \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\WindowsStore\").Property -contains \"DisableWindowsConsumerFeatures\"){Remove-ItemProperty -Path \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\WindowsStore\" -Name \"DisableWindowsConsumerFeatures\"}",
        "If ((Get-Item \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\WindowsStore\").Property -contains \"AutoDownload\"){Remove-ItemProperty -Path \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\WindowsStore\" -Name \"AutoDownload\"}",
        "Start-Process -FilePath \"$Env:SystemRoot\\System32\\Sysprep\\Sysprep.exe\" -ArgumentList \"/oobe /generalize /quiet /quit\" -Wait -NoNewWindow",
        "while($true) { $imageState = Get-ItemProperty HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Setup\\State | Select ImageState; if($imageState.ImageState -ne 'IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE') { Write-Verbose $imageState.ImageState -Verbose; Start-Sleep -s 15  } else { break } }"
      ]
    }],