Packer: Packer not sysprepping Windows AMI

Created on 17 May 2016  ยท  15Comments  ยท  Source: hashicorp/packer

Hi,

I've got this config here and I'm building a Windows AMI, which I hoped would get sysprepped at the end of the baking process.
https://gist.github.com/davidobrien1985/fe92aeac51ba35926cabed315fa1c449

However, when trying to join the new AMI to an Active Directory Domain it fails because the Windows SID is identical on the instances.

If I go and log on to the Windows instance built from that AMI and enter Ec2Config, tell it to sysprep and shut down, then log on to the AWS Console and have it create an AMI from that now shut down instance, that new AMI is sysprepped (generalized).

So something in my packer template is missing or not working.

packer --version
0.10.0

Running on El Capitan, building a Windows Server 2012 R2 AMI.

Part output of packer build:

==> amazon-ebs: Provisioning with shell script: /Users/dobrien/Versent/apra/ref-microsoft-ad/packer/windows-ad/scripts/Ec2Config.ps1
    amazon-ebs: Updating Ec2 Config...
    amazon-ebs: Updated Ec2 Config.
==> amazon-ebs: Provisioning with shell script: /Users/dobrien/Versent/apra/ref-microsoft-ad/packer/windows-ad/scripts/BundleConfig.ps1
==> amazon-ebs: Stopping the source instance...
==> amazon-ebs: Waiting for the instance to stop...
==> amazon-ebs: Creating the AMI: 2.0.0-4-ad-windows-soe-2016-05-12T12-02-25Z
    amazon-ebs: AMI: ami-629bb701
==> amazon-ebs: Waiting for AMI to become ready...
==> amazon-ebs: Modifying attributes on AMI (ami-629bb701)...
    amazon-ebs: Modifying: description
==> amazon-ebs: Adding tags to AMI (ami-629bb701)...
    amazon-ebs: Adding tag: "BuildNumber": "4"
    amazon-ebs: Adding tag: "BuildUUID": "1463054545"
==> amazon-ebs: Tagging snapshot: snap-868369b7
==> amazon-ebs: Terminating the source AWS instance...
==> amazon-ebs: Cleaning up any extra volumes...
==> amazon-ebs: Deleting temporary security group...
==> amazon-ebs: Deleting temporary keypair...
Build 'amazon-ebs' finished.

==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
buildeamazon question windows-guest

Most helpful comment

For Windows Server 2016 you need to use this:
{ "type": "powershell", "inline": [ "C:\\ProgramData\\Amazon\\EC2-Windows\\Launch\\Scripts\\InitializeInstance.ps1 -Schedule", "C:\\ProgramData\\Amazon\\EC2-Windows\\Launch\\Scripts\\SysprepInstance.ps1 -NoShutdown" ] }

Credit goes again to @davidobrien1985
Source: https://david-obrien.net/2016/12/packer-and-aws-windows-server-2016/

All 15 comments

I'm not aware of any packer feature that does this automatically. If this is something that needs to be done inside the OS (e.g. not through the EC2 API) you should use a provisioner. If there's a missing API call for this we will need to add it in packer.

Ok, thanks @cbednarski .
I was under the impression that packer would do it "automatically" at the end of the build. The examples here https://github.com/mefellows/packer-community-templates kinda imply that this works.

So right now at the end of the build packer only shuts down the EC2 instance and doesn't sysprep it?

IMO shutdown with sysprep should be a default setting.

The build you linked uses amazon-windows-ebs which is a builder plugin that does not ship with packer. Unfortunately I don't do a lot of windows builds so I am not familiar with the history of those projects.

Also while I understand your use case with respect to EC2, we don't generally have OS-specific provisioning steps in Packer outside of the provisioners themselves (chef, puppet, etc.), since there are so many variations between OSes, versions, etc. Instead we aim to give you control over the build so you can add these types of things yourself.

It might make sense to make a windows-sysprep type of provisioner (similar to the windows-restart one), but I don't think this is something we want to do automatically since in other cases (e.g. Vagrant) it may not be appropriate. As it is, though, you can do this yourself -- you just need to supply the configuration.

What do you mean "doesn't ship with packer"?

In my snippet above I'm using amazon-ebs, I didn't install any custom provisioners, just straight packer.

Is that the issue? Is amazon-ebs not Windows specific? It supports the powershell provisioner.

What do you mean "doesn't ship with packer"?

amazon-windows-ebs builder (line 13) is a plugin from the deprecated repo packer-windows-plugins and does not ship with Packer (core).

Is amazon-ebs not Windows specific? It supports the powershell provisioner.

amazon-ebs and powershell is of two different types of plugins, _builder_ and _provisioner_ respectively. Builders are OS agnostic but provisioners try to adapt depending on the OS when applicable. To conclude the amazon-ebs builder plugin supports Windows because it doesn't care. The powershell provisioner plugin supports (only) Windows.

And yes, if you need to run sysprep before shutting down the instance then you have to setup a provisioner to do that (e.g. powershell).

Haven't tried these templates but they look good and includes syspreping an AMI.

@rickard-von-essen I should've been more clear above. This is what I am using: https://gist.github.com/davidobrien1985/fe92aeac51ba35926cabed315fa1c449

I'm not using the amazon-windows-ebs builder at all. I am not installing any custom builders.

I am setting the Ec2Config settings (see gist) and that should tell the Ec2Config service that when it shuts down it should sysprep. It doesn't.

So, how do I customise the powershell provisioner if that currently doesn't do a sysprep on shutdown?
It's now all compiled into one executable, right? Guess I have to go freshen up my golang again...

Hmmm @davidobrien1985 this is weird, as I mentioned in another issue just above this one, you are doing the exact steps to make the AMI be sysprepped to be used after the packer build

Please have a look at https://github.com/ricardclau/packer-demos/tree/master/templates/windows-server-2012 which I used in a talk I did some weeks ago in a local Winops meetup.

Hope this can help although your Ec2Config xml file changes look fine

I've been trying to get this working with no success. Am I understanding correctly that setting AutoSysprep to Yes in bundleconfig.xml should cause sysprep to run when the AMI creation is initiated? It's not working for me either through packer or manual AMI creation through the console. I wasn't able to find much information on what exactly that setting is intended to do so I'm not sure if I'm misunderstanding how this is supposed to work.

@brushwood24 You need to execute this:

$sysprep = "$(Join-Path $env:WINDIR 'System32\Sysprep\Sysprep.exe')"

& $sysprep /unattend:"C:\Program Files\Amazon\Ec2ConfigService\sysprep2008.xml" /generalize /oobe /quiet

Packer won't sysprep automatically as I have discovered, you run the sysprep as the last step in your packer.json and after that Packer will create the AMI.

Closing this since this is not a Packer issue. Please reopen if you disagree and have more information.

@davidobrien1985 - although this is closed I am thinking I might have found the source. (this thread is also popular when googling this topic)

I think packer is doing an explicit shutdown of the image then doing a create operation.
AWS Create image operation is capable of doing the shutdown implicitly - so I wonder if autosysprep only works when the create image operation goes against a running instance?

The downside to a create image happening on a running instance, is that AWS brings the instance back to the running state when the create image process is done (leaves it in the found state).

Also - FYI - I have an image where we installed .NET 3.5. By running the AWS prepare script (C:\Program Files\Amazon\Ec2ConfigService\scripts\InstallUpdates.ps1 -Patch 0) it runs ngen.exe and precompiles any assemblies in the GAC.

This made our instance boot time from the AMI go from 25 minutes to about 3 minutes.

Even though the ngen.exe process does not prevent instances from coming to a full booted state - it eats the CPU alive while processing a large queue of assemblies.

@DarwinJS We are running into a similar issue as what you have mentioned in your FYI. Instance startup time is excessive. Can you elaborate more on what you did to get down to 3 min? When we spoke to AWS they said our AMI is not finishing the sysprep prior to shutting down and creating the AMI, so each instance startup needs to finish the sysprep process. We are currently running packer amazon-ebs with powershell provisioner to setup the instance and then another powershell provisioner which calls "& \"c:\program files\Amazon\EC2ConfigService\EC2Config.exe\" -sysprep". Is this what you are doing or are you calling sysprep directly? If you could provide a snippet from your packer template or any other tips that would be great.

For Windows Server 2016 you need to use this:
{ "type": "powershell", "inline": [ "C:\\ProgramData\\Amazon\\EC2-Windows\\Launch\\Scripts\\InitializeInstance.ps1 -Schedule", "C:\\ProgramData\\Amazon\\EC2-Windows\\Launch\\Scripts\\SysprepInstance.ps1 -NoShutdown" ] }

Credit goes again to @davidobrien1985
Source: https://david-obrien.net/2016/12/packer-and-aws-windows-server-2016/

I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

frezbo picture frezbo  ยท  3Comments

brettswift picture brettswift  ยท  3Comments

mwhooker picture mwhooker  ยท  3Comments

znerd picture znerd  ยท  3Comments

craigsimon picture craigsimon  ยท  3Comments