AWS EC2 not executing userdata after launch or restart

1.7k Views Asked by At

Using Terraform I launched windows EC2 instance. We used our own AMI. In terraform I have attached powershell script to userdata while creating the instance. After instance is launched, from AWS console I verified that the instance has the following userdata attached. enter image description here

Then I checked the log in C:\ProgramData\Amazon\EC2-Windows\Launch\Log\UserdataExecution.log However I do not see any of the output from powershell script. Here is the snippet from the log

2022/11/05 06:27:13Z: Begin user data script process.
2022/11/05 06:27:13Z: Unable to parse <persist> tags. This can happen when tags are unmatched or poorly formed.
2022/11/05 06:27:13Z: Sending telemetry bool: IsUserDataScheduledPerBoot
2022/11/05 06:27:13Z: Unregister the scheduled task to persist user data.
2022/11/05 06:27:15Z: Unable to parse <runAsLocalSystem> tags. This can happen when tags are unmatched or poorly formed.
2022/11/05 06:27:15Z: Unable to parse <script> tags. This can happen when tags are unmatched or poorly formed.
2022/11/05 06:27:15Z: Unable to parse <powershellArguments> tags. This can happen when tags are unmatched or poorly formed.
2022/11/05 06:27:15Z: <powershell> tag was provided.. running powershell content
2022/11/05 06:27:22Z: User data script completed.
2022/11/05 06:34:45Z: Begin user data script process.
2022/11/05 06:34:45Z: Unable to parse <persist> tags. This can happen when tags are unmatched or poorly formed.
2022/11/05 06:34:45Z: Sending telemetry bool: IsUserDataScheduledPerBoot
2022/11/05 06:34:45Z: Unregister the scheduled task to persist user data.
2022/11/05 06:34:48Z: Unable to parse <runAsLocalSystem> tags. This can happen when tags are unmatched or poorly formed.
2022/11/05 06:34:48Z: Unable to parse <script> tags. This can happen when tags are unmatched or poorly formed.
2022/11/05 06:34:48Z: Unable to parse <powershellArguments> tags. This can happen when tags are unmatched or poorly formed.
2022/11/05 06:34:48Z: <powershell> tag was provided.. running powershell content
2022/11/05 06:35:01Z: Message: The output from user data script: Running User Data Script
(host) Running User Data Script

WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Listener

Type            Keys                                Name                                                               
----            ----                                ----                                                               
Container       {Transport=HTTPS, Address=*}        Listener_123xxxxx                                                
Setting up WinRM
(host) setting up WinRM
WinRM service is already running on this machine.
WinRM is not set up to allow remote access to this machine for management.
The following changes must be made:

...
...
...
2022/11/05 06:35:01Z: User data script completed.
2022/11/09 18:06:10Z: Begin user data script process.
2022/11/09 18:06:10Z: Failed to get metadata: The result from http://169.254.169.254/latest/user-data was empty
2022/11/09 18:06:18Z: Launch metadata did not include a user data script.
2022/11/09 18:06:18Z: User data script completed.

The log also shows Failed to get metadata: The result from http://169.254.169.254/latest/user-data was empty when I browse the url it responded back with above powershell script.

enter image description here

Is there a setting that we missed on original AMI that is not allowing to run userdata? Why its not able to run the PS script?

Update 1

I ran the following command on the created Instance, and then it worked C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 –Schedule

So may be I need to run this command on the original instance from which the AMI was created and then recreate AMI and use it with terraform.

reference https://aws.amazon.com/premiumsupport/knowledge-center/ec2-windows-troubleshoot-user-data/
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-windows-run-command-existing/

1

There are 1 best solutions below

0
On

This is a potential solution that solved it for me (you commented on my previous post)

When building the AMI, you need to initially shutdown the system with sysprep. This can be found in the EC2Launch app.

Essentially without sysprep, the resulting EC2 instances will not have the initial networking rules they need on startup.