<h2>User Data Persistance</h2>

<p>If I create an image with Packer or other tool, I'll include normally a userdata initialization script that would allow connecting via WinRM. This is required as the default AMI settings wouldn't allow the tooling to connect. In this scenario Packer would create the instance from an AMI with my provided userdata. </p>

<p>However, when I then take an AMI of this configured instance and try to use it as a new instance, this new image has it's own userdata. If I wanted to run the exact same command, I would need to create the userdata in this new instance. </p>

<p>Userdata isn't persisted in your AMI, it's more an instance level configuration value. </p>

<h3>Follow-Up Comments on This</h3>

<p>The goal should be to create your AMI with the tooling, for example git, and then your new instance should not even need to run that command in the first place as you've "baked" it into your "golden ami". Consider this in your approach. Also consider decoupling any installation directly from userdata and use something like AWS Simple Systems Manager Command documents to run the installation. This would decouple your installation code from your infrastructure allowing you to apply automatically as well as on demand without having to repeat your work.</p>

<h2>User Data Content</h2>

<p>The code example above has a typo in the closing tag for PowerShell. I'd try replacing this and see if that's the root issue. If there's further issues after fixing that, post a comment on this answer and I'd be glad to look further.</p>

<p>Also as far as powershell syntax consider using join path for proper path parsing. </p>

<p>For example <code>$exe = Join-Path $ENV:ProgramData 'git/git.exe</code></p>

<p>The. You can run </p>

<pre><code>&amp;$exe --config --global ....
</code></pre>

<p>I'd also recommend that you consider looking at Amazon systems manager documents. You can create a  document that initializes a setting such as get config. </p>

<p>Then you create a AWS association to this document on a tag, at that point it will run automatically anytime a new instance is created without you having to continue to maintain it. It also allows you to update the document independently of the user data, and then ensure you can run it manually as needed as well. I'm a big fan of decoupling any type of configuration scripts from the userdata and using that as a last resort.</p>

<p>One last item...</p>

<pre><code>Remove-Item C:\c -Recurse -ErrorAction Ignore
</code></pre>

<p>Highly recommend you revisit that. That's seems super easy to mess up and start deleting stuff you didn't mean to. I'd make sure you use a fully qualified path with <code>Join-Path</code> and also use the <code>-LiteralPath</code> instead of positional argument by default. If anyone created a folder c on c drive I'd reject that in a heartbeat in a code review.</p>

CC BY-SA 4.0
2020-02-02T23:36:18.770Z
I already corrected that one while working on orginal ec2 instance.
Four Seasons
CC BY-SA 4.0
2020-02-03T08:45:09.083Z
And you reviewed the event log and log file for userdata? Can you execute this command in verbose mode and confirm the success when running manually?
sheldonhull
CC BY-SA 4.0
2020-02-03T08:46:38.103Z
If you are just not seeing the results of the command but no error, then verify the config file in the administrator account as I'm pretty sure git config global is global to you, not to the machine. Maybe it's a scope issue.
sheldonhull
CC BY-SA 4.0
2020-02-04T00:46:37.120Z
I executed the command manually on the machine and yes it worked pretty well.
Four Seasons
CC BY-SA 4.0
2020-02-04T00:47:18.347Z
Well I have not checked the config file.
Four Seasons
CC BY-SA 4.0
2020-02-11T08:24:10.250Z
Did you find a solution as this still is marked open? cheers
sheldonhull
CC BY-SA 4.0
2020-02-13T20:50:30.340Z
No I have not found the solution yet.
Four Seasons
CC BY-SA 4.0
2020-02-14T19:52:51.900Z
Ok @Ufomammut I have something that's probably relevant in re-reading your question. See updated answer
sheldonhull
CC BY-SA 4.0
2020-03-08T18:04:42.687Z
@ufomammot can you update with more detail or advise my answer solved the issue. Still shows no answer accepted and want to see if my additional detail helped.
sheldonhull
CC BY-SA 4.0
2020-02-02T21:07:51.947Z
2020-02-14T19:57:55.483Z
2020-02-14T19:57:55.483Z
sheldonhull
<p>I created a windows Ec2 instance with user data in it. In my ec2 instance I downlaoded git and installed it. Later in EC2 instance, I provided it with the user data which was supposed to download a git repository and place it in C: </p>

<p>This is my user data in original EC2 instance.</p>

<pre><code> &lt;powershell&gt;
Remove-Item C:\c -Recurse -ErrorAction Ignore
C:\"Program Files"\Git\bin\git.exe config --global http.sslVerify false
C:\"Program Files"\Git\bin\git.exe clone https://github.com/(somename)/(someapp).git /c
&lt;/powershell&gt;
&lt;persist&gt;true&lt;/persist&gt;
</code></pre>

<p>The EC2 instance worked without any problem. Then I decided to create a custom AMI from it. I created one and launched another instance from it. I then tried to run the instance to which it ran succesfully. But then in the new EC2 instance that I created from custom AMI, the user data from the original EC2 instance was not executed. I tried changing the setting of EC2 instance which was found in C://programdata . I configured it to run user data on every boot. But then still user data was not executed. I am not sure what's going on here. Any help will be appreciated.</p>

<amazon-web-services><amazon-ec2><amazon-ami>
User data in original windows ec2 instance does not get executed in custom ami
Four Seasons
# User data in original windows ec2 instance does not get executed in custom ami

(Asked by: username_0 on 2020-01-30)

I created a windows Ec2 instance with user data in it. In my ec2 instance I downlaoded git and installed it. Later in EC2 instance, I provided it with the user data which was supposed to download a git repository and place it in C: 
This is my user data in original EC2 instance.
 
Remove-Item C:\c -Recurse -ErrorAction Ignore
C:\"Program Files"\Git\bin\git.exe config --global http.sslVerify false
C:\"Program Files"\Git\bin\git.exe clone https://github.com/(somename)/(someapp).git /c

true

The EC2 instance worked without any problem. Then I decided to create a custom AMI from it. I created one and launched another instance from it. I then tried to run the instance to which it ran succesfully. But then in the new EC2 instance that I created from custom AMI, the user data from the original EC2 instance was not executed. I tried changing the setting of EC2 instance which was found in C://programdata . I configured it to run user data on every boot. But then still user data was not executed. I am not sure what's going on here. Any help will be appreciated.

**Tags:** amazon-web-services, amazon-ec2, amazon-ami


---

## 1 answers

### Answer by username_1 on 2020-02-02. Score: 2 | Accepted answer

User Data Persistance
If I create an image with Packer or other tool, I'll include normally a userdata initialization script that would allow connecting via WinRM. This is required as the default AMI settings wouldn't allow the tooling to connect. In this scenario Packer would create the instance from an AMI with my provided userdata. 
However, when I then take an AMI of this configured instance and try to use it as a new instance, this new image has it's own userdata. If I wanted to run the exact same command, I would need to create the userdata in this new instance. 
Userdata isn't persisted in your AMI, it's more an instance level configuration value. 
Follow-Up Comments on This
The goal should be to create your AMI with the tooling, for example git, and then your new instance should not even need to run that command in the first place as you've "baked" it into your "golden ami". Consider this in your approach. Also consider decoupling any installation directly from userdata and use something like AWS Simple Systems Manager Command documents to run the installation. This would decouple your installation code from your infrastructure allowing you to apply automatically as well as on demand without having to repeat your work.
User Data Content
The code example above has a typo in the closing tag for PowerShell. I'd try replacing this and see if that's the root issue. If there's further issues after fixing that, post a comment on this answer and I'd be glad to look further.
Also as far as powershell syntax consider using join path for proper path parsing. 
For example $exe = Join-Path $ENV:ProgramData 'git/git.exe
The. You can run 
&$exe --config --global ....

I'd also recommend that you consider looking at Amazon systems manager documents. You can create a  document that initializes a setting such as get config. 
Then you create a AWS association to this document on a tag, at that point it will run automatically anytime a new instance is created without you having to continue to maintain it. It also allows you to update the document independently of the user data, and then ensure you can run it manually as needed as well. I'm a big fan of decoupling any type of configuration scripts from the userdata and using that as a last resort.
One last item...
Remove-Item C:\c -Recurse -ErrorAction Ignore

Highly recommend you revisit that. That's seems super easy to mess up and start deleting stuff you didn't mean to. I'd make sure you use a fully qualified path with Join-Path and also use the -LiteralPath instead of positional argument by default. If anyone created a folder c on c drive I'd reject that in a heartbeat in a code review.

> **Comments:**
> **username_0**: I already corrected that one while working on orginal ec2 instance.  
> **username_1**: And you reviewed the event log and log file for userdata? Can you execute this command in verbose mode and confirm the success when running manually?  
> **username_1**: If you are just not seeing the results of the command but no error, then verify the config file in the administrator account as I'm pretty sure git config global is global to you, not to the machine. Maybe it's a scope issue.  
> **username_0**: I executed the command manually on the machine and yes it worked pretty well.  
> **username_0**: Well I have not checked the config file.  
> **username_1**: Did you find a solution as this still is marked open? cheers  
> **username_0**: No I have not found the solution yet.  
> **username_1**: Ok @Ufomammut I have something that's probably relevant in re-reading your question. See updated answer  
> **username_1**: @ufomammot can you update with more detail or advise my answer solved the issue. Still shows no answer accepted and want to see if my additional detail helped.  

---

