Windows – Creating custom AMI in AWS that can be used with a key pair to get the Windows password after launch

amazon ec2amazon-web-servicesSecuritywindows

I wanted to create a custom AMI for use with Elastic Beanstalk. Up until now I have been logging on to my instance by using the key pair to retrieve the Windows Password.

I launched a new instance specifically for customising to use as a custom AMI. I went to the EC2 page on AWS, clicked 'Launch Instance' and chose the public image ami-9f1c4bfa. I chose this public image because it was the default instance in my Elastic Beanstalk setup. I also chose the same key pair that I have been using with my Elastic Beanstalk instances.

After I applied the settings that I wanted to my new instance, I went back to the EC2 list to create an image of it (a custom AMI).

Once that had saved, I then entered my AMI name within Elastic Beanstalk.

My EC2 instance had been recreated, but I could no longer use the key pair to get the Windows password.

Is it something I've done when creating the instance that causes this, or are there additional steps that I need to allow a key pair to be used?

Best Answer

From the documentation:

EC2Config runs initial startup tasks when the instance is first started and then disables them. To run these tasks again, you must explicitly enable them prior to shutting down the instance, or by running Sysprep manually. These tasks are as follows:

Set a random, encrypted password for the administrator account.

In the Windows EC2 Config Service, you'll want to verify that the Administrator Password retrieval option is set to 'Random.' From your description, it sounds like it is perhaps set to 'Keep Existing', as shown in the image below:

The EC2 Service Properties UI, showing 'Keep Existing' selected for the Administrator Password retrieval option

If you still know the password you used to access the original EC2 instance when you took that image, it is possible that this was disabled following startup of the original EC2 instance... in which case, you could verify this by attempting to access the new EC2 instance with that same password.

Related: