logo
Menu

Enabling Windows Remote Management with Amazon WorkSpaces and Amazon AppStream 2.0

This post describes how to set up Windows Remote Management on your domain joined AppStream 2.0 and WorkSpaces instances, including the networking prerequisites. WinRM permits easy remote management of Active Directory domain joined Amazon WorkSpaces and Amazon AppStream 2.0 instances.

Dan Garibay
Amazon Employee
Published Aug 30, 2024
Customers use Amazon WorkSpaces to get a fully managed remote desktop solution in the AWS cloud, supporting Windows and Linux desktops. A top question from customers is how to manage their systems at scale.
Windows Remote Management, also known as WinRM, is a cornerstone of managing Windows systems at scale with tools built into the operating system but, it is not enabled by default. Since Amazon WorkSpaces Personal deployments frequently use Active Directory, WinRM is an excellent choice. It is fundamental to other possibilities, such as using Ansible to manage your Windows WorkSpaces.
Additionally, WorkSpaces Pools and Amazon AppStream 2.0 fleets optionally support domain joining. If such Pools or Fleets are domain joined, they can also be managed with WinRM.
WorkSpaces Personal directories of the Identity source "AWS Directory Service" use Active Directory, and this post will apply to these. WorkSpaces Personal directories with the Identity source "IAM Identity Center" do not use Active Directory .
In this post, you will learn how to use Active Directory Group Policy to enable WinRM across your domain.

Overview of solution

In this post, you will use Active Directory Group Policy to enable WinRM listeners and the appropriate firewall rules. These will be applied across your domain joined Windows WorkSpaces and domain joined Windows AppStream fleets.
This post only focuses on enabling HTTP (port 5985) WinRM. When WinRM is used with Kerberos, as described in this post, ongoing communication is encrypted, and initial authentication is done with a non-reusable token. For more information, see the “Encryption and transport protocols” section of Microsoft’s WinRM Security documentation.
For additional security, WinRM can be set up to use HTTPS. This requires existing certificate issuance and automation infrastructure and is out of scope for this post.

Prerequisites

For this walkthrough, you should have the following prerequisites:
  • An AWS account.
  • Pre-existing Windows based Amazon WorkSpaces deployment.
  • Access to your Active Directory, with sufficient privileges to create new Group Policy.
  • A Windows computer joined to the domain, with the Active Directory Remote Server Administration tools pre-installed.

Prerequisite 1: Install the Active Directory Administration Tools

If you already have the Active Directory Remote Server Administration tools installed, you can skip to the next section.
This is a prerequisite section, to assist if you do not already have the Active Directory administration tools installed on your Windows domain management computer (such as your Amazon WorkSpace). If you already have these installed, you can skip to the next section.
These steps need to be performed on a Windows machine which is connected to the same Active Directory you will be administering. A Windows Amazon WorkSpace joined to the same domain is a valid option.
  1. Begin by logging into the Windows machine (could be an Amazon WorkSpace or EC2 instance) you will use for Active Directory administration.
  2. Open an Administrative PowerShell console by right-selecting on the Start logo and choosing Windows PowerShell (Admin) or Terminal (Admin).
  3. Run winver and note whether your Windows machine is based on Windows Server or Windows 10/11.
  4. Run one of the following two commands, based on the result:
If your Windows machine is based on Windows Server:
Install-WindowsFeature GPMC,RSAT-AD-Tools,RSAT-AD-PowerShell
If your Windows machine is based on Windows 10 or 11:
This will install the Active Directory MMC tools, Active Directory PowerShell commandlets, and the Group Policy console.

Prerequisite 2a: Identify the WorkSpaces Organizational Unit

This section can be skipped if you already know the OU you need to apply the group policies to, or if you are not configuring WorkSpaces.
To scope this Group Policy to be specific to your WorkSpaces, you will need to identify the Organizational Unit your WorkSpaces’ Active Directory Computer Objects are placed into when they were originally joined the domain during provisioning.
  1. Open the WorkSpaces console. Validate your AWS Region in the top right of the console matches the region your Amazon WorkSpaces are provisioned in. Change the region if necessary.
  2. In the left menu, select Directories.
  3. In the "Directory ID" column, you will see links which can be chosen. Navigate to the full page for the directory ID you need the Active Directory OU information from by selecting the matching link in this column.
    1. For WorkSpaces Personal: Note the Identity source column. Only Directories with the AWS Directory Service Identity Source use Active Directory. Directories which use the IAM Identity Center Identity Source are not Active Directory Domain Joined. These are instead managed with an MDM solution tied to their external identity source, such as InTune (for Entra ID) or JumpCloud MDM (for JumpCloud). This post only applies to AWS Directory Service Identity Source directories.
  4. In the full Directory page, you will be able to see the OU for both WorkSpaces Personal and Pools. The steps differ slightly:
    1. WorkSpaces Personal: You will see a Summary section at the top, containing fields such as Directory type, Organization name, and Registration code. On this page, locate the Organizational unit field. Note this value for future reference (or keep this console open in a separate tab).
    2. WorkSpaces Pools: There is an Active Directory Config - optional section further down the page, which will contain the Organization Unit (OU) field. Note this value for future reference (or keep this console open in a separate tab).

Prerequisite 2b: Identify the AppStream 2.0 Organizational Unit

This section can be skipped if you already know the OU you need to apply the group policies to, or if you are not configuring domain-joined AppStream 2.0.
To scope this Group Policy to be specific to your Amazon AppStream 2.0 instances, you will need to identify the Organizational Unit your AppStream 2.0 Active Directory Computer Objects are placed into.
  1. Open the AppStream 2.0 console. Validate your Region in the top right of the console, and change it if appropriate.
  2. In the left menu, select Directory Configs.
  3. Select the Directory the AppStream Instances are provisioned to.
  4. In the Directory Config Details window, find the Organizational Units (OUs) field. Note this value for future reference (or keep this console open in a separate tab).

Permit WinRM traffic to your WorkSpaces and AppStream 2.0 instances

In this section, you will modify your WorkSpaces (or AppStream 2.0) security group configuration to permit inbound WinRM traffic.
You will need to designate an IP address range or AWS Security Group ID from which WinRM commands can be sent (that is, where your management Windows machine instance resides). These will likely be internal IP address ranges, either within your VPC, or other IP space you control, such as your on-premises network.


Create a WinRM Source specific Security Group

In this section, you will create an EC2 Security Group which permits inbound WinRM traffic. Later, you will configure your WorkSpaces and/or AppStream 2.0 instances to use this Security Group.
  1. Navigate to the EC2 console. Double check you are in the same Region that your WorkSpaces or AppStream 2.0 instances are in.
  2. Under Networking & Security, select Security Groups, then select Create security group.
  3. Use the following options and values for the new Security Group.
    1. Security group name: WinRM
    2. Description: Permit inbound WinRM traffic
    3. VPC: The VPC where your WorkSpaces or AppStream 2.0 instances are deployed.
    4. Inbound rules: Select Add rule. Select the dropdown under Type, and select WinRM-HTTP. Under the Source column, leave the dropdown on Custom.
      1. If your management Windows machine(s) are in AWS, and have a Security Group ID associated to them, you supply that existing Security Group ID here. Alternatively, enter an IPv4 address range in CIDR notation that you trust WinRM commands to come from.
    5. Outbound rules: Leave this empty.
    6. Under the Tags section, add any tags as desired.
  4. Select Create security group.
  5. Note the Security Group ID as you will need it in future steps.

Configure your WorkSpaces Personal or Pools directory with the WinRM Security Group

This section can be skipped if you are not configuring WorkSpaces Personal or domain-joined WorkSpaces Pools.
  1. Navigate to the WorkSpaces console and select Directories in the top left. Validate that you are in the region with your WorkSpaces.
  2. Locate the directory associated with the WorkSpaces you wish to manage and note the Directory ID.
  3. In the "Directory ID" column, you will see links which can be chosen. Navigate to the full page for the directory ID you are changing the Security Group configuration on, by selecting the matching link in this column.
  4. In the Directory's full details page, scroll down to the Security group section, which has the description, "The security group for your WorkSpaces' network interfaces in your Amazon VPC. This security group is applied to any new or rebuilt WorkSpaces in this directory."
  5. Select the Edit button at the top right of the Security group section.
  6. On the resulting Edit security group page, you will see a drop-down menu with a list of all Security Groups (by name and ID) in your WorkSpaces VPC.
    1. If you do not see the Security Group you created previously, double check that it was created in the correct region and VPC.
  7. Select the ID of the rule you created in the previous section. Then select the Save button.
  8. You will be returned to the directory overview page. If you scroll back to the Security group section, you will see the Security Group you chose previously.
This change applies slightly differently to WorkSpaces Personal and WorkSpaces Pools.
  • For WorkSpaces Personal:
    • With this configuration change, any WorkSpaces Personal instances that you create, or Rebuild, will have your WinRM security group applied to them automatically.
    • This change will not apply this Security Group to any previously deployed WorkSpaces Personal instances. To ensure this change is applied to existing WorkSpaces without needing to Rebuild them, there is a convenient solution described in the blog Automatically attach additional security groups to Amazon AppStream 2.0 and Amazon WorkSpaces.
  • For WorkSpaces Pools:
    • The configuration change will take place without further changes required.

Configure your AppStream 2.0 Fleet or Image Builder with the WinRM Security Group

This section can be skipped if you are not configuring domain-joined AppStream 2.0 Fleets or Image Builders.
AppStream can have Security Groups attached to new Image Builders, to new Fleets, and to existing Fleets (but they must be Stopped first).
For more information on these scenarios, please see Security Groups in Amazon AppStream 2.0.

Create your WinRM Group Policy

  1. On a Windows member server open the Group Policy Management Console.
    1. You can find it in the Start Menu, or by launching gpmc.msc from the Run menu, which can be reached with the keyboard shortcut Windows key + R.
  2. Expand Forest, Domains, and your domain Fully Qualified Domain Name. Locate the Organization Unit assigned to your WorkSpaces deployment.
  3. Right select the OU and choose Create a GPO in this domain, and Link it here.
  4. Provide a name and description for the policy.
  5. If you need to associate your new Group Policy Object to multiple Organizational Units:
    1. Right select the additional OU.
    2. Choose Link an Existing GPO.
    3. Choose the GPO you just created, and then OK.
    4. Repeat for every additional OU you need to associate.
  6. Right select your new GPO in the list and choose Edit.
  7. Navigate to Computer Configurations > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Windows Defender Firewall with Advanced Security.
  8. Right select Inbound Rules and choose New Rule.
  9. Choose the Predefined rule type. Select the drop down menu and choose Windows Remote Management in the list. Choose Next.
  10. In the "Which rules would you like to create?" step, you will see two versions of the rule. One rule will be for the profile Public , and one will be for the profile Domain, Private. Check the box for the rule with the Domain, Private profile; do not create the rule for the Public profile. Choose Next.
  11. Choose Allow the connection and then Finish.
  12. Expand Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service.
  13. Right-select Allow remote server management through WinRM and choose Edit.
  14. Choose Enabled.
  15. In the Options, enter an IPv4 range which corresponds to the servers you plan to administer your WorkSpaces from.
  16. Choose OK.
  17. Expand Computer Configuration > Preferences > Control Panel Settings > Services.
  18. Right select Services and choose New > Service
  19. In the New Service Properties select …
  20. In the Select a Service window select the WinRM service and choose Select.
  21. Configure the remaining fields on the General tab of the New Service Properties window as follows:
    1. Startup: Automatic (Delayed Start)
    2. Service action: Start service
    3. Leave the other options at the default
  22. Switch to the Recovery tab and make the following changes:
    1. First failure: Restart the service
    2. Second failure: Restart the service
    3. Third failure: Restart the service
    4. Leave the other options at the default
  23. Select OK to save the service configuration.
  24. Close the Group Policy Management Editor window.

Testing

Group Policy automatically refreshes on certain intervals, such as on restart, login, and every 90 minutes with a randomized offset of up to 30 minutes. To ensure a given WorkSpace or AppStream instance has up-to-date settings, you can log into it and run gpupdate /force from an administrative PowerShell prompt, or you can reboot it.
In order to test, you can use Enter-PSSession to connect to a WorkSpace or AppStream instance from a domain joined computer in the same IP address range you provided previously.
You will need to connect using the computer name, not the IP address, due to Kerberos restrictions. In the example below, I’d like to connect to a specific WorkSpace Personal in my account. WorkSpaces Personal provides an API to get the hostname of the WorkSpace. In the example below, I use the API to get the hostname of my test WorkSpace Personal.
This picture shows using the Get-WKSWorkSpace PowerShell cmdlet to find the ComputerName.
Using AWS PowerShell to find the Active Directory Computer Name of the WorkSpace.
I can now connect to this computer. As a demonstration, I use Get-Volume on the remote computer to check the remaining free space on its C and D drives.
Connecting to a WorkSpace with WinRM, and using the Get-Volume PowerShell command.
Connecting to a WorkSpace with WinRM, and using the Get-Volume PowerShell command.
The connection works instantly because the following statements are true:
  • I am connecting from a computer connected to the same domain.
  • I am connecting from using Kerberos, (computer hostname, not IP address).
  • I am connecting with an Active Directory user account that is a member of the local administrators group on the remote computer. This occurs because the account is a member of an AD group. I have a separate Group Policy which adds this AD group to local administrators on my WorkSpaces.

Troubleshooting

If you are not able to connect with Enter-PSSession, try the following items.
  • On the testing WorkSpace or AppStream instance, run gpupdate /force to ensure it has the updated policies.
  • If this does not work, then from an Admin PowerShell session, run gpresult /h $env:userprofile\desktop\gp.html which will put a gp.html file on your desktop. Review this report and ensure your Group Policy is being applied. The command must be run with Administrator privileges so the computer section populates.
  • If the Group Policy is applying correctly, use the VPC Reachability Analyzer to ensure that WinRM (port 5985) traffic can pass between the point of origin and the WorkSpace or AppStream instance you are connecting to.

Cleanup

To remove this setup, you must alter the Group Policy, rather than simply deleting it. Deleting the Group Policy will not roll back the changes to any computer which already applied the policy. This is because security policies persist even if no longer defined in the policy that originally applied it. This is sometimes referred to as Group Policy “tattooing.”
To roll back the changes, follow these steps.
  1. Open the Group Policy Management Consolegpmc.msc from the Run menu or the PowerShell prompt.
  2. In the left console, expand Forest, Domains, and your domain Fully Qualified Domain Name. Locate the Organization Unit (or Units) you applied the policy to.
    1. If you linked the Group Policy to more than one Organizational Unit, you do not have to repeat these steps for each OU.
  3. Right select your local admin GPO in the list and choose Edit.
  4. Expand Computer Configurations > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Windows Defender Firewall with Advanced Security.
  5. Choose Inbound Rules. In the right section, right select Windows Remote Management (HTTP-In) and choose Properties.
  6. In the resulting window, in the General tab, change the Action to Block the connection and choose OK.
  7. Expand Computer Configuration > Policies > Windows Components > Administrative Templates > Windows Remote Management (WinRM) > WinRM Service.
  8. Right-select Allow remote server management through WinRM and choose Edit.
  9. Choose Disabled.
  10. Choose OK.
  11. Expand Computer Configuration > Preferences > Control Panel Settings and select Services.
  12. In the right window, right select WinRM and choose Properties.
  13. In the General tab, change the Startup option to Disabled, and the Service action to Stop service.
  14. In the Recovery tab, change the 3 failure options to No Change.
  15. Select OK button to save the service configuration.
  16. Close the Group Policy Management Editor window.

Conclusion

In this post, you have configured a Group Policy to enable Windows Remote Management on your WorkSpaces. This Group Policy does the following:
  • Creates a Windows Firewall rule to permit WinRM from an inbound IP address range of your choice.
  • Enables the WinRM listener.
  • Configures the WinRM service to automatically start on boot, and restart on failure.
Windows Remote Management enables you to increase your efficiency as a WorkSpaces administrator allowing you to:
  • Perform ad-hoc diagnostics of an end user’s WorkSpace without disrupting the user’s active session.
  • Connect to WorkSpaces individually or at scale for administrative purposes.
  • Use WinRM with a larger automation project, such as Ansible®. Ansible can be used to automate sending commands to your entire WorkSpaces fleet.

Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.

Comments