(upbeat music)
(keyboard clicks)
- Hello, I'm Chris,
a Cloud Support Engineer here
at the AWS headquarters in Seattle.
Sometimes, customers ask me for advice
when they have trouble connecting
to their Amazon EC2 Windows instance over RDP.
When attempting to log in, they may instead see an error,
such as "remote access to the server is not enabled",
"the remote computer is not available on the network"
or "the remote computer is turned off".
There are a number of Windows settings
that can cause an Amazon EC2 Windows instance
to refuse a connection.
It can be challenging to troubleshoot Windows
without connecting to it remotely,
so to automate the process,
AWS support provides
AWS systems manager automation documents,
which can remotely troubleshoot RDP on your behalf.
Today, I'll show you that process, step by step.
The automation document we'll be using
executes a series of PowerShell scripts
and other AWS support automation documents
to check configurations that might
prevent RDP sessions from starting.
Note that to execute most of this automation,
the target instance must be listed
as managed in systems manager.
To become a managed mnstance,
that instance must meet the following requirements:
first, the SSM Agent must be installed on the instance.
The agent comes pre-installed
on Windows Server 2016 and 2019 instances,
as well as on Windows Server 2003 through 2012 R2 AMIs,
published November 2016 or later.
Second, the instance requires
either outbound internet access on port 443,
or, in the case of private subnets,
a VPC configured to the systems manager VPC endpoints.
You don't need inbound internet access for systems manager.
Finally, we'll make sure that an IAM role
allowing systems manager access
is associated with the instance.
We'll walk through that in just a moment.
If your instance doesn't meet these requirements,
don't worry.
You can set this document to run
on unmanaged instances, it just takes a bit longer
and requires some downtime.
We'll work on that later;
feel free to skip ahead
using the link in the video description,
or follow along with both work flows.
So, what does this automation document do?
You can configure the document
to take the following actions on a running instance.
By default, the automation will out
but only the current values of these settings
you can choose to change the ones you need.
You can disable the Windows firewall for all profiles,
set the RDP service startup tag to automatic,
start, restart or force-restart the RDP service,
set the instances RDP port to 3389
and then restart the service,
disable Network Layer Authentication, or NLA,
or enable remote connections in the registry
by setting fDeny TSConnections registry value to zero.
You can additionally configure the document
to perform offline troubleshooting if these steps fail.
In this tutorial, we'll go through the following steps
to troubleshoot an unreachable instance:
first, we'll create an IAM role
for systems manager access.
Next, we'll assign that role to the instance
to register it with systems manager,
and finally, we'll execute the automation document
and then connect to the instance over RDP.
Let's get started.
After logging in to the AWS management console,
we'll navigate to the EC2 console.
I'll select instances to look at my resources.
I have a Windows server 2019 instance,
which is currently running and reachable by ping,
however, RDP connections to the instance are failing.
To troubleshoot this, we'll first head to the IAM console.
If your instance already has an IAM role
with the required access associated,
you can stand by or follow along to refresh your memory.
Under the navigation pane at the left-hand side,
select roles, then choose create role.
Under the select type of trusted entity page,
choose AWS service,
then choose
EC2.
Select EC2 role for simple systems manager
from the use case list,
then choose next to move on to permissions.
Verify Amazon EC2 role for SSMs listed
then choose next to exit.
If you use tags to manage your IAM resources,
you can add them here.
In this example, I don't need to tag my roles,
so I'll just choose next to review.
Choose a role name you'll remember;
you'll need to look it up later.
I'll name mine Amazon EC2 role for SSM,
and use the default description.
Next, choose create role.
You'll be returned to the roles page.
Your role is ready to go.
Let's move on to the next step.
We'll register the instance in systems manager.
Head back to the Amazon EC2 console,
and then select instances from the left-hand pane.
Choose the instance you're troubleshooting.
Select actions,
instance settings,
and attach/replace IAM role.
In the dropdown list,
start typing the name of your SSM role.
Select it, and then apply your changes.
The task was successful,
so the instances will soon be listed as managed.
Note that it can take up to five minutes
for the instance to register
with the systems managers service,
so if it doesn't appear right away,
you can pause this video
and wait 'till the registration process completes.
Now, let's move on.
Under services, search for systems manager.
Choose managed instances from the left-hand panel.
Because the instance has outbound internet access,
and the systems manager role is attached,
it's listed here,
this means we can run the automation.
Let's get to the fun part.
On the left-hand panel, choose automation.
Next, choose execute automation to start the process.
The first step is to choose an automation document.
To locate the AWS support troubleshoot RDP document,
we can use a filter mark.
Select document name prefix,
equal,
and then the start of the document name.
You can enter as much as you want to narrow the results.
Select the button next to AWS support troubleshoot RDP.
Unless otherwise indicated by AWS,
you can leave the document version as
default version at runtime.
Choose next.
In this example, we'll be rending the full document
on a single instance.
We can leave the simple execution option selected.
Next, we'll fill out the parameters for the automation.
Under instance ID, you can manually enter
the ID of the instance you'd like to target.
However, I find it's easier to use
the interactive instance picker.
Select your unreachable instance.
By default, the automation will
check the values of the RDP settings
without taking action.
You can manually choose action for each setting
by using the drop-down menus.
For example, I can choose to check
my Windows firewall setting, or disable the firewall.
In this case, I'd like to get in to
my instance right away,
and I don't have a problem
with changing these settings to the default.
I'll choose fix all under the action drop-down
to restore all RDP settings to their defaults,
and I'll also disable the Windows firewall.
Heads up, if you choose this option,
be sure to restore your Windows firewall settings
based on your security policy
as soon as you have access to the instance.
The allow offline option and S3 bucket name settings
can be used to run offline troubleshooting
if the other steps fail,
or if the target is not a managed instance.
I'll discuss these settings in detail later.
For now, we'll use online troubleshooting.
Now that I've confirmed my parameters
the way I want them,
I'll choose execute to start the automation.
I've been directed to the execution detail page,
for the automation I just ran.
On this page, I can follow along with each step
written in to the automation document.
Note that not all steps are expected to execute.
Just like that, I can see the automation was successful.
I can expand the output section,
to see what happened.
My RDP service has been started,
and switched to the automatic startup type.
It looks like the service was disabled,
which would explain why it couldn't connect.
Let's head back to the instance and test it.
I'll return to the EC2 console,
open up my instances,
and choose connect.
Download the remote desktop file,
and open the downloaded file
to connect to the public DNS of my instance.
And there you have it.
I'm connected to my instance over RDP now,
so I can authenticate and restore my firewall
through its previous settings.
If your instance isn't registered with Systems Manager,
or if the online troubleshooting steps don't work,
you can use the AllowOffline setting
in the document parameters.
Offline troubleshooting works on any instance,
but it can take some time to run,
and using it requires a stop and restart.
Remember that when an instance is stopped,
data stored on instance store volumes
and automatically-assigned public IPs are lost.
The offline troubleshooting process
uses the AWSSupport-ExecuteEC2Rescue
automation document to perform
the following steps by default:
the process creates a temporary VPC
that configures the VPC with a series
of AWS LAM defunctions.
It finds a subnet in the temporary VPC
and the same availability zone as your instance,
then launches a temporary
systems manager-enabled helper instance,
and then stops your instance, takes a backup,
and attaches the root volume of the instance
to the helper instance.
The system uses run command
to run EC2 rescue on the helper instance,
identifying and fixing issues on the original root volume.
When the process is done, it attaches the root volume
back to your original instance, and restarts it.
Finally, it terminates the temporary instance,
VPC and LAM defunctions it created
at the start of the automation.
And back on the Amazon EC2 console,
let's move to instances to look at my resources.
I have a Windows Server 2019 instance,
which is responsive, but doesn't tell our IDP connections.
However, this instance doesn't have an IAM role assigned,
so it isn't managed.
We can use offline RDP troubleshooting to fix this.
First, let's get to the systems manager console.
Select automation from the left-hand panel.
Choose execute automation.
Browse to the AWS support troubleshoot RDP document.
Select the button,
then choose next.
For this example,
we'll run a simple execution
to run the entire document on one instance.
Open up the interactive instance picker.
To show non-managed instances,
choose the drop-down on the right side
and select show all instances.
Select the instance you want to troubleshoot
then scroll down to the rest of the parameters.
There are a couple of things that need to be said here.
First, the action must be set to fix all
and allow offline must be set to true,
otherwise, execution will fail on non-managed instances.
Two optional settings are available
with offline troubleshooting.
First, under subnet ID,
you can choose an existing subnet
in the same availability zone as your instance
to launch the helper instance in to.
If you leave this blank,
it will create a new VPC by default.
Additionally, under S3 bucket name,
you can enter the name of an Amazon S3 bucket
to collect EC2 rescue logs from your instance.
These logs can come in handy,
if you need to perform manual troubleshooting.
Note that your instance must have access to this bucket,
or the log output will fail.
In this example, I don't need the logs,
so I'll leave this field blank.
Choose execute to launch the process,
and be redirected to the execution detail page.
Here, you can watch the progress of your automation,
step-by-step.
If you've configured your parameters correctly,
it'll get to the step
troubleshoot RDP offline with subnet ID,
and stay there for a while.
This step runs the entire EC2 rescue work flow,
so it can take some time.
You can pause this video 'till the work flow completes.
We've waited a while for the automation to finish,
and the execution status now displays success.
Next, I'll test my connection.
I'll return to the Amazon EC2 console
to track it down.
Pick instances from the left-hand menu,
and then locate your instance.
Choose connect,
download the remote desktop file
and then open it to connect
to the public DNS of your instance.
You now should be able to log in to your instance.
Thanks for watching,
and happy cloud computing from all of here at AWS.
(upbeat music)