Let's say that the CloudWatch Agent installed on Windows Server was version X.0. After few months, there was an update, and the latest available version of CloudWatch Agent was X.1. So, how can I proceed with updating the already installed CloudWatch Agent version on Windows Server?
In the user guide, I am able to find ways to 'Download and Configure the CloudWatch Agent' and other related processes but not able to find ways to update the CloudWatch Agent version.
Any prompt support in this regard will be highly appreciated.
You can re-install using AWS Systems Manager, for that Systems Manager has to be installed already and you need to add these I AM roles if not there already
AmazonSSMManagedInstanceCore, CloudWatchAgentServerPolicy.
Download the CloudWatch agent package
Systems Manager Run Command enables you to manage the configuration of your instances. You specify a Systems Manager document, specify parameters, and execute the command on one or more instances. SSM Agent on the instance processes the command and configures the instance as specified.
To download the CloudWatch agent using Run Command:
Open the Systems Manager console at
https://console.aws.amazon.com/systems-manager/.
In the navigation pane, choose Run Command.
-or-
If the AWS Systems Manager home page opens, scroll down and choose
Explore Run Command.
Choose Run command.
In the Command document list, choose AWS-ConfigureAWSPackage.
In the Targets area, choose the instance on which to install the
CloudWatch agent. If you do not see a specific instance, it might not be configured for Run Command. For more information, see Setting Up AWS Systems Manager for Hybrid Environments in the AWS Systems Manager User Guide.
In the Action list, choose Install.
In the Name box, enter AmazonCloudWatchAgent.
Keep Version set to latest to install the latest version of the agent.
Choose Run.
Optionally, in the Targets and outputs areas, select the button next to an instance name and choose View output. Systems Manager should show that the agent was successfully installed.
As below it does uninstall and reinstall.
Reference: AWS Documentation
Related
I want to see the list of VMs that doesn't have the ops agent installed in my GCP project.
Any command or API or console view will work for me.
I noticed that when my VM boots, it will randomly choose between two guest environments. In the logs, I see "GCE Agent Started" with either (version 20210908.1) or (version 20200610.00). The host key changes along with the agent version. The issue is that I am only able to access my conda environments and other information on one of these versions. Is there any way I can control or choose which agent version is used on startup? Is there a way to disable or uninstall these agents?
I'm trying to get all our instances (all Windows based) upgraded to IMDSv2 and have been following the advice found here https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html#instance-metadata-transition-to-version-2 and using CloudWatch to find instances making MetadataNoToken calls (i.e. using IMDSv1).
I've found several instances using IMDSv1 this way, but I can't work out how to find out what is making the calls from with the OS.
According to CloudWatch each server is making one call per minute to the IMDSv1 service.
The support article mentions upgrading any AWS SDKs or CLI tools, but the servers in question don't have seem to have any SDKs or CLI tools installed.
Each instance has the following AWS published tools installed on them:
Amazon SSM Agent
Amazon CloudWatch Agent
AWS Tools for Windows
EC2ConfigService
AWS PV Drivers
aws-cfn-bootstrap
I've updated the Amazon SSM Agent and the Amazon CloudWatch Agent to the latest versions. But I can't find any information about how to update the AWS Tools for Windows package.
I've also run TCPView from Sysinternals on the servers and tried to find what process is making calls to the 169.254.169.254 endpoint, but it doesn't seem to pick up any traffic to that address.
I'm reluctant to just disable IMDSv1 and do a scream test as they are production servers.
If anyone has any advice or guidance on how to find what is making the IMDSv1 calls it would be appreciated.
I figured it out in the end, using the £Windows Resource Monitor Network monitor" tool, I found the exectucable that was making the calls.
I've written up the proceess in this blog post:
https://www.greystone.co.uk/2022/03/24/how-greystone-upgraded-its-aws-ec2-instances-to-use-instance-meta-data-service-version-2-imdsv2/
I need to install Fire Eye in multiple ec2 instances in my AWS account, all running Windows Server 2012. I have the installer msi and could do it using Distributor in SSM. However there is a json file that needs to be in the same folder as the msi file when software is being installed. This doesn't seem to be supported by Distributor.
Can anyone help me out with how this can be done, short of logging in to every server and installing it manually after copy pasting the json and msi file in one folder?
Usually for ad-hoc execution of commands on a fleet of instances you would use AWS Systems Manager Run Command:
Administrators use Run Command to perform the following types of tasks on their managed instances: install or bootstrap applications, build a deployment pipeline, capture log files when an instance is terminated from an Auto Scaling group, and join instances to a Windows domain, to name a few.
I've got development and production instances in EC2. I've been updating my app in Visual Studio 2019 and redeploying it to the dev instance, then creating an AMI of that instance and using that image to update the production instance(s).
Suddenly my app no longer updates when I deploy to the dev instance. The logs all show the update was applied, but when I look at the files on the server they have not changed for days. I suspect I may be using AMIs incorrectly, but I'm not sure what I'm doing wrong.
How do I get my updates to show again?
You are facing the issue because creating an AMI from running environment isn't the right approach since EB runs several scripts under the hood to attach instances to that particular environment.
Note: Custom AMIs are ideal only when you're installing a lot of dependencies or software that you want to be baked into your AMI so subsequent deployments go through quick. Here's the documentation that walks you through the steps, and here's the summary of the steps:
The best approach would be to launch a stand alone EC2 using an EB
AMI as base (ideally an AMI with HVM virtualization).
Connect to the instance with SSH or RDP.
Perform any customizations you want.
(Windows platforms) Run the EC2Config service Sysprep. For
information about EC2Config, see Configuring a Windows Instance Using
the EC2Config Service. Ensure that Sysprep is configured to generate
a random password that can be retrieved from the AWS Management
Console.
In the Amazon EC2 console, stop the EC2 instance. Then on the
Instance Actions menu, choose Create Image (EBS AMI).