# Administer WorkSpaces Personal
<a name="administer-workspaces"></a>

You can administer your WorkSpaces using the WorkSpaces console.

To perform directory administration tasks, see [Set up Active Directory Administration Tools for WorkSpaces Personal](directory_administration.md).

**Note**  
Ensure you update networking dependency drivers like ENA, NVMe, and PV drivers on your WorkSpaces. You should do this at least once every 6 months. For more information, see [ Install or upgrade Elastic Network Adapter (ENA) driver ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking-ena.html#ena-adapter-driver-install-upgrade-win), [AWS NVMe drivers for Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html), and [Upgrade PV drivers on Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Upgrading_PV_drivers.html).
Ensure you update the EC2Config, EC2Launch, and EC2Launch V2 agents to the latest versions periodically. You should do this at least once every 6 months. For more information, see [Update EC2Config and EC2Launch](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/migrating-latest-types.html#upgdate-ec2config-ec2launch).

**Topics**
+ [

# Manage your Windows WorkSpaces in WorkSpaces Personal
](group_policy.md)
+ [

# Manage your Amazon Linux 2 WorkSpaces in WorkSpaces Personal
](manage_linux_workspace.md)
+ [

# Manage your Ubuntu WorkSpaces in WorkSpaces Personal
](manage_ubuntu_workspace.md)
+ [

# Manage your Rocky Linux WorkSpaces
](manage_rockylinux_workspace.md)
+ [

# Manage your Red Hat Enterprise Linux WorkSpaces
](manage_rhel_workspace.md)
+ [

# Optimize WorkSpaces for real-time communication in WorkSpaces Personal
](communication-optimization.md)
+ [

# Manage the running mode in WorkSpaces Personal
](running-mode.md)
+ [

# Manage applications in WorkSpaces Personal
](manage-applications.md)
+ [

# Modify a WorkSpace in WorkSpaces Personal
](modify-workspaces.md)
+ [

# Customize branding in WorkSpaces Personal
](customize-branding.md)
+ [

# Tag resources in WorkSpaces Personal
](tag-workspaces-resources.md)
+ [

# Maintenance in WorkSpaces Personal
](workspace-maintenance.md)
+ [

# Encrypted WorkSpaces in WorkSpaces Personal
](encrypt-workspaces.md)
+ [

# Reboot a WorkSpace in WorkSpaces Personal
](reboot-workspaces.md)
+ [

# Rebuild a WorkSpace in WorkSpaces Personal
](rebuild-workspace.md)
+ [

# Restore a WorkSpace in WorkSpaces Personal
](restore-workspace.md)
+ [

# Microsoft 365 Bring Your Own License (BYOL) in WorkSpaces Personal
](byol-microsoft365-licenses.md)
+ [

# Upgrade Windows BYOL WorkSpaces in WorkSpaces Personal
](upgrade-windows-10-byol-workspaces.md)
+ [

# Migrate a WorkSpace in WorkSpaces Personal
](migrate-workspaces.md)
+ [

# Delete a WorkSpace in WorkSpaces Personal
](delete-workspaces.md)

# Manage your Windows WorkSpaces in WorkSpaces Personal
<a name="group_policy"></a>

You can use Group Policy Objects (GPOs) to apply settings to manage Windows WorkSpaces or users that are part of your Windows WorkSpaces directory.

**Note**  
If you use Microsoft Entra ID or Custom WorkSpaces directory, you can manage users and groups with Microsoft Entra ID or your Identity Providers. For more inforamtion, see [Create a dedicated Microsoft Entra ID directory with WorkSpaces Personal](launch-entra-id.md).
Linux instances do not adhere to Group Policy. For information about managing Amazon Linux WorkSpaces, see [Manage your Amazon Linux 2 WorkSpaces in WorkSpaces Personal](manage_linux_workspace.md). 

Amazon recommends that you create an organizational unit for your WorkSpaces Computer Objects and an organizational unit for your WorkSpaces User Objects.

To use the Group Policy settings that are specific to Amazon WorkSpaces, you must install the Group Policy administrative template for the protocol or protocols that you are using, either PCoIP or DCV.

**Warning**  
Group Policy settings can affect the experience of your WorkSpace users as follows:  
**Implementing an interactive logon message to display a logon banner prevents users from being able to access their WorkSpaces.** The interactive logon message Group Policy setting is not currently supported by PCoIP WorkSpaces. The logon message is supported on DCV WorkSpaces, and users have to login again after accepting the logon banner. Logon messages are not supported when Certificate-Based Logon is enabled.
**Disabling removable storage through Group Policy settings causes a login failure** that results in users being logged in to temporary user profiles with no access to drive D.
**Removing users from the Remote Desktop Users local group through Group Policy settings prevents those users from being able to authenticate** through the WorkSpaces client applications. For more information about this Group Policy setting, see [ Allow log on through Remote Desktop Services](https://docs.microsoft.com/windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services) in the Microsoft documentation.
**If you remove the built-in Users group from the **Allow log on locally** security policy, your PCoIP WorkSpaces users won't be able to connect to their WorkSpaces through the WorkSpaces client applications.** Your PCoIP WorkSpaces also won't receive updates to the PCoIP agent software. PCoIP agent updates might contain security and other fixes, or they might enable new features for your WorkSpaces. For more information about working with this security policy, see [ Allow log on locally](https://docs.microsoft.com/windows/security/threat-protection/security-policy-settings/allow-log-on-locally) in the Microsoft documentation.
Group Policy settings can be used to restrict drive access. **If you configure Group Policy settings to restrict access to drive C or to drive D, users can't access their WorkSpaces.** To prevent this issue from occurring, make sure that your users can access drive C and drive D. 
**The WorkSpaces audio-in feature requires local logon access inside the WorkSpace.** The audio-in feature is enabled by default for Windows WorkSpaces. However, if you have a Group Policy setting that restricts users' local logon in their WorkSpaces, audio-in won't work on your WorkSpaces. If you remove that Group Policy setting, the audio-in feature is enabled after the next reboot of the WorkSpace. For more information about this Group Policy setting, see [ Allow log on locally](https://docs.microsoft.com/windows/security/threat-protection/security-policy-settings/allow-log-on-locally) in the Microsoft documentation.  
For more information about enabling or disabling audio-in redirection, see [Configure audio-in redirection for PCoIP](#gp_audio) or [Configure audio-in redirection for DCV](#gp_audio_in_wsp).
Using Group Policy to set the Windows power plan to **Balanced** or **Power saver** might cause your WorkSpaces to sleep when they're left idle. We strongly recommend using Group Policy to set the Windows power plan to **High performance**. For more information, see [My Windows WorkSpace goes to sleep when it's left idle](amazon-workspaces-troubleshooting.md#windows_workspace_sleeps_when_idle). 
Some Group Policy settings force users to log off when they are disconnected from a session. Any applications that users have open on their WorkSpaces are closed.
"Set time limit for active but idle Remote Desktop Services sessions" is currently not supported on DCV WorkSpaces. Avoid using it during DCV sessions as it causes a disconnect even when there is activity and the session is not idle.

For information about using the Active Directory administration tools to work with GPOs, see [Set up Active Directory Administration Tools for WorkSpaces Personal](directory_administration.md).

**Contents**
+ [Install the Group Policy administrative template files for DCV](#gp_install_template_wsp)
+ [

## Manage Group Policy settings for DCV
](#gp_configurations_dcv)
+ [

## Install the Group Policy administrative template for PCoIP
](#gp_install_template)
+ [

## Manage Group Policy settings for PCoIP
](#gp_configurations_pcoip)
+ [

## Set the maximum lifetime for a Kerberos ticket
](#gp_kerberos_ticket)
+ [

## Configure device proxy server settings for internet access
](#gp_device_proxy)
  + [

### Proxying desktop traffic
](#w2aac11c31c11c27c15)
  + [

### Recommendation on the use of proxy servers
](#w2aac11c31c11c27c17)
+ [Enable Zoom Meeting Media Plugin support](#zoom-integration)
  + [

### Enable Zoom Meeting Media Plugin for DCV
](#zoom-wsp)
    + [

#### Prerequisites
](#zoom-integ-prerequisites-wsp)
    + [

#### Before you begin
](#zoom-begin-wsp)
    + [

#### Installing the Zoom components
](#installing-zoom-wsp)
  + [

### Enable Zoom Meeting Media Plugin for PCoIP
](#zoom-pcoip)
    + [

#### Prerequisites
](#zoom-integ-prerequisites-pcoip)
    + [

#### Create the registry key on a Windows WorkSpaces host
](#zoom-integ-create-registry-key)
    + [

#### Troubleshooting
](#zoom-integ-troubleshoot)

## Install the Group Policy administrative template files for DCV
<a name="gp_install_template_wsp"></a>

To use the Group Policy settings that are specific to WorkSpaces when using DCV, you must add the Group Policy administrative template `wsp.admx` and `wsp.adml` files for DCV to the Central Store of the domain controller for your WorkSpaces directory. For more information about `.admx` and `.adml` files, see [ How to create and manage the Central Store for Group Policy Administrative Templates in Windows](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra).

The following procedure describes how to create the Central Store and add the administrative template files to it. Perform the following procedure on a directory administration WorkSpace or Amazon EC2 instance that is joined to your WorkSpaces directory.

**To install the Group Policy administrative template files for DCV**

1. From a running Windows WorkSpace, make a copy of the `wsp.admx` and `wsp.adml` files in the `C:\Program Files\Amazon\WSP` directory.

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open Windows File Explorer, and in the address bar, enter your organization's fully qualified domain name (FQDN), such as `\\example.com`.

1. Open the `sysvol` folder.

1. Open the folder with the `FQDN` name.

1. Open the `Policies` folder. You should now be in `\\FQDN\sysvol\FQDN\Policies`.

1. If it doesn't already exist, create a folder named `PolicyDefinitions`.

1. Open the `PolicyDefinitions` folder.

1. Copy the `wsp.admx` file into the `\\FQDN\sysvol\FQDN\Policies\PolicyDefinitions` folder.

1. Create a folder named `en-US` in the `PolicyDefinitions` folder.

1. Open the `en-US` folder.

1. Copy the `wsp.adml` file into the `\\FQDN\sysvol\FQDN\Policies\PolicyDefinitions\en-US` folder.<a name="verify-admin-template"></a>

**To verify that the administrative template files are correctly installed**

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**).

1. Expand the forest (**Forest:*FQDN***).

1. Expand **Domains**. 

1. Expand your FQDN (for example, `example.com`).

1. Expand **Group Policy Objects**.

1. Select **Default Domain Policy**, open the context (right-click) menu, and choose **Edit**.
**Note**  
If the domain backing the WorkSpaces is an AWS Managed Microsoft AD directory, you cannot use the Default Domain Policy to create your GPO. Instead, you must create and link the GPO under the domain container that has delegated privileges.  
When you create a directory with AWS Managed Microsoft AD, Directory Service creates a *yourdomainname* organizational unit (OU) under the domain root. The name of this OU is based on the NetBIOS name that you typed when you created your directory. If you didn't specify a NetBIOS name, it will default to the first part of your Directory DNS name (for example, in the case of `corp.example.com`, the NetBIOS name is `corp`).  
To create your GPO, instead of selecting **Default Domain Policy**, select the *yourdomainname* OU (or any OU under that one), open the context (right-click) menu, and choose **Create a GPO in this domain, and Link it here**.   
For more information about the *yourdomainname* OU, see [ What Gets Created](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_what_gets_created.html) in the *AWS Directory Service Administration Guide*.

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **DCV**.

1. You can now use this **DCV** Group Policy object to modify the Group Policy settings that are specific to WorkSpaces when using DCV.

## Manage Group Policy settings for DCV
<a name="gp_configurations_dcv"></a>

**To use Group Policy settings to manage your Windows WorkSpaces that use DCV**

1. Make sure that the most recent [WorkSpaces Group Policy administrative template for DCV](#gp_install_template_wsp) is installed in the Central Store of the domain controller for your WorkSpaces directory.

1. Verify the administrative template files are correctly installed. For more information, see [To verify that the administrative template files are correctly installed](#verify-admin-template).

### Configure printer support for DCV
<a name="gp_local_printers_wsp"></a>

By default, WorkSpaces enables Basic remote printing, which offers limited printing capabilities because it uses a generic printer driver on the host side to ensure compatible printing.

Advanced remote printing for Windows clients connecting to Windows WorkSpaces lets you use specific features of your printer, such as double-sided printing, but it requires installation of the matching printer drivers on the host side and the client side.

You can use Group Policy settings to configure printer support as needed.


**Basic vs. Advanced Printing**  

| Aspect | Basic Printing | Advanced Printing | 
| --- | --- | --- | 
| Driver Used | Generic XPS driver | Printer-specific driver | 
| Driver Installation | Automatic | Manual (host and client) | 
| Features | Standard printing only | Full printer features (duplex, paper tray selection, finishing, etc.) | 

**When to use Advanced Printing:** - Double-sided (duplex) printing - Specific paper tray selection - Finishing options (stapling, hole-punching) - Label printing (e.g., Zebra printers) - Color management and other advanced features of a printer.

#### Configure Printer Support
<a name="w2aac11c31c11c19b5b1c13"></a>

**To configure printer support**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Configure remote printing** setting.

1. In the **Configure remote printing** dialog box, do one of the following:
   + **For Basic Printing:** choose **Enabled**. To automatically use the client computer's current default printer, select **Map local default printer to the remote host. **
   + **For Advanced Printing:** Choose **Enabled**, then choose **Enable Advanced Printing**.To automatically use the client computer's current default printer, select** Map local default printer to the remote host**. Once the policy is enabled, you will need to install matching printer drivers on the host and client side.
   + To disable printing, choose **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

#### Configure Advanced Printer Redirection
<a name="w2aac11c31c11c19b5b1c17"></a>

**Prerequisites**

1. **WorkSpaces Host Agent:** Version 2.2.0.2116 or later

1. **Windows Client:** Version 5.31.0 or later

1. **Printer drivers:** Matching printer drivers must be installed on both the WorkSpace and the client device

**Note**  
Advanced printing is only supported on Windows clients connecting to Windows WorkSpaces. MacOS, Linux, and Web clients will use basic printing.

#### Driver Version Matching
<a name="w2aac11c31c11c19b5b1c23"></a>

When Advanced printing is selected, three driver validation modes are supported:


**Driver Validation Modes**  

| Mode | Behavior | Use When | 
| --- | --- | --- | 
| Name Only (Default) | Matches driver name only, ignores version | Maximum compatibility needed | 
| Partial Match | Matches Major.Minor version (e.g., 10.6.x.x) | Balancing compatibility and features | 
| Exact Match | Requires exact version match | Specialized printers (e.g., Zebra label printers) | 

**To configure validation mode**, set name only, partial match, or exact match in the printer driver validation dropdown in the GPO.

**Note**  
When driver validation fails, WorkSpaces automatically falls back to basic printing.

**Verify Configuration**

1. Connect to the WorkSpace.

1. Open **Settings** > **Devices** > **Printers & scanners**.

1. Verify your local printer appears with "Redirected" prefix.

1. Print a test document and click Printer Properties to verify advanced options are available.

#### Troubleshooting
<a name="w2aac11c31c11c19b5b1c27"></a>

**Advanced features not available**: - Verify “Enable Advanced Printing” is selected in the GPO - Check driver versions match according to your validation mode - Consider using partial validation mode instead of exact. Make sure to restart for any changes on the GPO to take effect.

**Printer not appearing**: - Verify **Configure remote printing** is **Enabled** - Ensure printer is connected to client device - Restart WorkSpace session

**Print jobs fail**: - Check driver versions on both client and WorkSpace - Review logs at: **C:\$1ProgramData\$1Amazon\$1WSP\$1Logs\$1agentsession.log** - Look for "Advanced print is enabled" in logs

Enable detailed logging: In Group Policy, set Configure log verbosity to debug under **Computer Configuration** > **Policies** > **Administrative Templates** > **Amazon** > **WSP**. 

### Configure clipboard redirection (copy/paste) for DCV
<a name="gp_clipboard_wsp"></a>

By default, WorkSpaces supports two-way (copy/paste) clipboard redirection. For Windows WorkSpaces, you can use Group Policy settings to disable this feature or configure the direction where clipboard redirection is allowed. 

**To configure clipboard redirection for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Configure clipboard redirection** setting.

1. In the **Configure clipboard redirection** dialog box, choose **Enabled** or **Disabled**.

   When **Configure clipboard redirection** is **Enabled**, the following **Clipboard redirection options** will become available:
   + Choose **Copy and Paste** to allow two-way clipboard copy and paste redirection.
   + Choose **Copy Only** to allow copying data from the server clipboard to the client clipboard only.
   + Choose **Paste Only** to allow pasting data from the client clipboard to the server clipboard only.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

**Known limitation**  
With clipboard redirection enabled on the WorkSpace, if you copy content that is larger than 890 KB from a Microsoft Office application, the application might become slow or unresponsive for up to 5 seconds.

### Set the session resume timeout for DCV
<a name="gp_auto_resume_wsp"></a>

When you lose network connectivity, your active WorkSpaces client session is disconnected. WorkSpaces client applications for Windows and macOS attempt to reconnect the session automatically if network connectivity is restored within a certain amount of time. The default session resume timeout is 20 minutes (1200 seconds), but you can modify that value for WorkSpaces that are controlled by your domain's Group Policy settings. 

**To set the automatic session resume timeout value**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Enable/disable automatic reconnect** setting.

1. In the **Enable/disable automatic reconnect** dialog box, choose **Enabled**, and then set **Reconnect timeout (seconds)** to the desired timeout in seconds.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

### Configure video-in redirection for DCV
<a name="gp_video_in_wsp"></a>

By default, WorkSpaces supports redirecting data from a local camera. If needed for Windows WorkSpaces, you can use Group Policy settings to disable this feature. 

**To configure video-in redirection for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Enable/disable video-in redirection** setting.

1. In the **Enable/disable video-in redirection** dialog box, choose **Enabled** or **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

### Configure audio-in redirection for DCV
<a name="gp_audio_in_wsp"></a>

By default, WorkSpaces supports redirecting data from a local microphone. If needed for Windows WorkSpaces, you can use Group Policy settings to disable this feature. 

**To configure audio-in redirection for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Enable/disable audio-in redirection** setting.

1. In the **Enable/disable audio-in redirection** dialog box, choose **Enabled** or **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

### Configure audio-out redirection for DCV
<a name="gp_audio_out_wsp"></a>

By default, WorkSpaces redirects data to a local speaker. If needed for Windows WorkSpaces, you can use Group Policy settings to disable this feature. 

**To configure audio-out redirection for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Enable/disable audio-out redirection** setting.

1. In the **Enable/disable audio-out redirection** dialog box, choose **Enabled** or **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace. In the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions** > **Reboot WorkSpaces**.
   + In an administrative command prompt, enter **gpupdate /force**.

### Disable time zone redirection for DCV
<a name="gp_time_zone_wsp"></a>

By default, the time within a Workspace is set to mirror the time zone of the client that is being used to connect to the WorkSpace. This behavior is controlled through time zone redirection. You might want to turn off time zone direction for various reasons. For example: 
+ Your company wants all employees to work in a certain time zone (even if some employees are in other time zones).
+ You have scheduled tasks in a WorkSpace that are meant to run at a certain time in a specific time zone.
+ Your users who travel a lot want to keep their WorkSpaces in one time zone for consistency and personal preference.

If needed for Windows WorkSpaces, you can use Group Policy settings to disable this feature.

**To disable time zone redirection for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Enable/disable time zone redirection** setting.

1. In the **Enable/disable time zone redirection** dialog box, choose **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

1. Set the time zone for the WorkSpaces to the desired time zone.

The time zone of the WorkSpaces is now static and no longer mirrors the time zone of the client machines. 

### Configure DCV security settings
<a name="wsp_security"></a>

For DCV, data in transit is encrypted using TLS 1.2 encryption. By default, all of the following ciphers are allowed for encryption, and the client and server negotiate which cipher to use:
+ ECDHE-RSA-AES128-GCM-SHA256
+ ECDHE-ECDSA-AES128-GCM-SHA256
+ ECDHE-RSA-AES256-GCM-SHA384
+ ECDHE-ECDSA-AES256-GCM-SHA384
+ ECDHE-RSA-AES128-SHA256
+ ECDHE-RSA-AES256-SHA384

For Windows WorkSpaces, you can use Group Policy settings to modify the TLS Security Mode and to add new or block certain cipher suites. A detailed explanation of these settings and the supported cipher suites is provided in the **Configure security settings Group Policy **dialog box.

**To configure DCV security settings**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open **Configure security settings**.

1. In the **Configure security settings** dialog box, choose **Enabled**. Add cipher suites that you want to allow and remove cipher suites that you want to block. For more information about these settings, see the descriptions provided in the **Configure security settings** dialog box.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace, and after you restart the WorkSpace session. To apply the Group Policy changes, do one of the following:
   + To reboot the WorkSpace, in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**.
   + In an administrative command prompt, enter **gpupdate /force**.

### Configure extensions for DCV
<a name="extensions"></a>

By default, support for WorkSpaces extensions is disabled. If needed, you can configure your WorkSpace to use extensions in the following ways:
+ Server and client – Enable extensions for both server and client
+ Server only – Enable extensions for server only
+ Client only – Enable extensions for client only

For Windows WorkSpaces, you can use Group Policy settings to configure the use of extensions.

**To configure extensions for DCV**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Configure extensions** setting.

1. In the **Configure extensions** dialog box, choose **Enabled** and then set the desired support option. Choose **Client Only**, **Server and Client**, or **Server only**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after you restart the WorkSpace session. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace. In the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**.
   + In an administrative command prompt, enter **gpupdate /force**.

### Configure smart card redirection for DCV
<a name="gp_smart_cards_in_wsp"></a>

By default, Amazon WorkSpaces are not enabled to support the use of smart cards for either *pre-session authentication* or *in-session authentication*. Pre-session authentication refers to smart card authentication that's performed while users are logging in to their WorkSpaces. In-session authentication refers to authentication that's performed after logging in.

If needed, you can enable pre-session and in-session authentication for Windows WorkSpaces by using Group Policy settings. Pre-session authentication must also be enabled through your AD Connector directory settings by using the **EnableClientAuthentication** API action or the **enable-client-authentication** AWS CLI command. For more information, see [ Enable Smart Card Authentication for AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_clientauth.html) in the *AWS Directory Service Administration Guide*.

**Note**  
To enable the use of smart cards with Windows WorkSpaces, additional steps are required. For more information, see [Use smart cards for authentication in WorkSpaces Personal](smart-cards.md). 

**To configure smart card redirection for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Enable/disable smart card redirection** setting.

1. In the **Enable/disable smart card redirection** dialog box, choose **Enabled** or **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the WorkSpace session is restarted. To apply the Group Policy change, reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).

### WebAuthn (FIDO2) Redirection for DCV
<a name="gp_webauthn_fido2_in_wsp"></a>

By default, Amazon WorkSpaces enables WebAuthn redirection, allowing users to use their local FIDO2-compatible security keys and biometric authenticators with applications running inside their WorkSpace. This feature securely redirects authentication requests from applications in the WorkSpace to the user's local device, providing seamless access to authentication methods including Yubikeys and Windows Hello.

Amazon WorkSpaces supports two versions of WebAuthn redirection:
+ **Standard WebAuthn** - Requires a browser extension, supported on Windows and Linux WorkSpaces, for browser-based apps
+ **Enhanced WebAuthn** - No browser extension required, with additional native application support, supported on Windows WorkSpaces only

#### Standard WebAuthn redirection
<a name="w2aac11c31c11c19b5c21b9"></a>

Standard WebAuthn redirection requires a browser extension to facilitate the redirection of WebAuthn prompts to the client device.

##### Version requirements
<a name="w2aac11c31c11c19b5c21b9b5"></a>
+ **Windows WorkSpaces**: DCV host agent version 2.0.0.1425 or higher
+ **Client versions:**
  + Windows client: 5.19.0 or above
  + Mac client: 5.19.0 or above
  + Linux client: 2024.0 or above

##### Supported browsers on WorkSpaces
<a name="w2aac11c31c11c19b5c21b9b7"></a>
+ Google Chrome 116\$1
+ Microsoft Edge 116\$1

#### Enhanced WebAuthn redirection
<a name="w2aac11c31c11c19b5c21c11"></a>

Enhanced WebAuthn redirection eliminates the need for a browser extension and provides support for WebAuthn authentication in native Windows applications that support WebAuthn authentication.

##### Version requirements
<a name="w2aac11c31c11c19b5c21c11b5"></a>
+ **Windows WorkSpaces**: DCV host agent version 2.1.0.2000 or higher
+ **Client versions:**
  + Windows client: 5.29.0 or above
  + Mac client: 5.29.0 or above

##### Key benefits
<a name="w2aac11c31c11c19b5c21c11b7"></a>
+ No browser extension required
+ Improved performance
+ Support for WebAuthn in native Windows applications
+ Seamless authentication experience across browsers and desktop applications

##### Supported browsers on WorkSpaces
<a name="w2aac11c31c11c19b5c21c11b9"></a>
+ Google Chrome 116\$1
+ Microsoft Edge 116\$1

#### Configure WebAuthn redirection
<a name="w2aac11c31c11c19b5c21c13"></a>

**To configure WebAuthn redirection for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **DCV**.

1. Open the **Configure WebAuthn redirection** setting.

1. In the **Configure WebAuthn redirection** dialog box, choose **Enabled** or **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the WorkSpace session is restarted. To apply the Group Policy changes, reboot the WorkSpace by going to the Amazon WorkSpaces console and selecting the WorkSpace. Then, choose **Actions**, **Reboot WorkSpaces**.

**Note**  
This Group Policy setting enables WebAuthn redirection. The version used (Standard or Enhanced) depends on your host agent version and operating system support.

#### Configure WebAuthn process compatibility
<a name="w2aac11c31c11c19b5c21c15"></a>

When WebAuthn redirection is enabled, you can configure which applications and processes are allowed to use WebAuthn redirection through the **WebAuthn Process Compatibility List**.

##### Default process compatibility list
<a name="w2aac11c31c11c19b5c21c15b5"></a>

By default, the following processes are enabled for WebAuthn redirection:

```
['chrome.exe','msedge.exe','island.exe','firefox.exe','dcvwebauthnnativemsghost.exe','msedgewebview2.exe','Microsoft.AAD.BrokerPlugin.exe']
```

##### Required process for Standard WebAuthn
<a name="w2aac11c31c11c19b5c21c15b7"></a>
+ `dcvwebauthnnativemsghost.exe` - This process is **required** for Standard WebAuthn functionality and must remain in the compatibility list when using Standard WebAuthn.

**To configure the WebAuthn process compatibility list**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **DCV**.

1. Open the **Configure WebAuthn Redirection** setting.

1. Choose **Enabled**.

1. In the **WebAuthn process compatibility list** field, specify the list of process names that are compatible with WebAuthn redirection.
   + Use the default list as a starting point
   + Add additional process names as needed for your environment

1. Choose **OK**.

1. The Group Policy setting change takes effect after the WorkSpace session is restarted.

##### Process compatibility list guidelines
<a name="w2aac11c31c11c19b5c21c15c11"></a>
+ **For Standard WebAuthn**: Always include `dcvwebauthnnativemsghost.exe` in the list
+ **Custom Applications**: Add any additional `.exe` process names that need WebAuthn support in your environment
+ **Format**: Use comma-separated process names enclosed in square brackets, with each process name in single quotes

##### Example custom process list
<a name="w2aac11c31c11c19b5c21c15c11b5"></a>

```
['chrome.exe','msedge.exe','firefox.exe','dcvwebauthnnativemsghost.exe','msedgewebview2.exe','Microsoft.AAD.BrokerPlugin.exe','myapp.exe','customapplication.exe']
```

#### Transitioning from Standard to Enhanced WebAuthn
<a name="w2aac11c31c11c19b5c21c17"></a>

When upgrading from Standard WebAuthn to Enhanced WebAuthn, **users will need to uninstall or disable the Amazon DCV WebAuthn Redirection browser extension** they previously installed for Standard WebAuthn before using Enhanced WebAuthn.

##### Why this step is important
<a name="w2aac11c31c11c19b5c21c17b5"></a>
+ Enhanced WebAuthn handles redirection natively without browser extensions
+ Leaving the extension enabled will default to Standard WebAuthn redirection

#### Installing the Amazon DCV WebAuthn Redirection Extension (Standard WebAuthn Only)
<a name="installing_webauthn"></a>

**Note**  
This section only applies to Standard WebAuthn. Enhanced WebAuthn does not require browser extensions.

Users will need to install the Amazon DCV WebAuthn Redirection Extension to use Standard WebAuthn after the feature is enabled by doing either of the following:
+ Users will be prompted to enable the browser extension in their browser.
**Note**  
 This is a one-time browser prompt. Your users will get the notification when you update the DCV agent version to 2.0.0.1425 or higher. If your end users don’t need the WebAuthn redirection, they can just remove the extension from the browser. You can also block the WebAuthn Redirection Extension installation prompt using GPO policy.
+ You can force install the redirection extension for your users using GPO policy. If you enable the GPO policy, the extension will automatically be installed when your users launch the supported browsers with internet access.
+ Users can install the extension manually with [ Microsoft Edge Add-ons](https://microsoftedge.microsoft.com/addons/detail/dcv-webauthn-redirection-/ihejeaahjpbegmaaegiikmlphghlfmeh) or the [ Chrome Web Store](https://chromewebstore.google.com/detail/dcv-webauthn-redirection/mmiioagbgnbojdbcjoddlefhmcocfpmn?pli=1).

##### Understanding WebAuthn Redirection Extension Native Messaging
<a name="installing_webauthn-understand"></a>

WebAuthn redirection in Chrome and Edge browsers utilizes a browser extension and a native messaging host. The native messaging host is a component that allows communication between the extension and the host application. In a typical configuration, all native messaging hosts are permitted by the browser by default. However, you can choose to use a native messaging blocklist, where the value of \$1 means that all native messaging hosts are denied unless explicitly allowed. In this case, you need to enable the Amazon DCV WebAuthn Redirection native messaging host by explicitly specifying the value `com.dcv.webauthnredirection.nativemessagehost` in the allow list.

For more information, follow the guidance for your browser:
+ For Google Chrome, see [Native Messaging allowed hosts](https://support.google.com/chrome/a/answer/2657289#zippy=%2Cnative-messaging-allowed-hosts).
+ For Microsoft Edge, see [Native Messaging](https://learn.microsoft.com/en-us/deployedge/microsoft-edge-policies#native-messaging).

##### Manage and install the browser extension using Group Policy
<a name="w2aac11c31c11c19b5c21c19c11"></a>

You can install the Amazon DCV WebAuthn Redirection Extension using Group Policy, either centrally from your domain for session hosts that are joined to an Active Directory (AD) domain or using the Local Group Policy Editor for each session host. This process will change depending on which browser you're using.

**For Microsoft Edge**

1. Download and install the [ Microsoft Edge administrative template](https://learn.microsoft.com/en-us/deployedge/configure-microsoft-edge#1-download-and-install-the-microsoft-edge-administrative-template).

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**).

1. Expand the forest (**Forest:*FQDN***).

1. Expand **Domains**. 

1. Expand your FQDN (for example, `example.com`).

1. Expand **Group Policy Objects**.

1. Select **Default Domain Policy**, open the context (right-click) menu, and choose **Edit**.

1. Choose **Computer Configuration **, **Administrative Templates**, **Microsoft Edge**, and **Extensions**

1. Open **Configure extension management settings** and set it to **Enabled**.

1. Under **Configure extension management settings**, enter the following:

   ```
   {"ihejeaahjpbegmaaegiikmlphghlfmeh":{"installation_mode":"force_installed","update_url":"https://edge.microsoft.com/extensionwebstorebase/v1/crx"}}
   ```

1. Choose **OK**.

1. The Group Policy setting change takes effect after the WorkSpace session is restarted. To apply the Group Policy changes, reboot the WorkSpace by going to the Amazon WorkSpaces console and selecting the WorkSpace. Then, choose **Actions**, **Reboot WorkSpaces**).

**Note**  
You can block the installation of the extension by applying the following configuration management setting:  

```
{"ihejeaahjpbegmaaegiikmlphghlfmeh":{"installation_mode":"blocked","update_url":"https://edge.microsoft.com/extensionwebstorebase/v1/crx"}}
```

**For Google Chrome**

1. Download and install the Google Chrome administrative template. For more information, see [ Set Chrome Browser policies on managed PCs](https://support.google.com/chrome/a/answer/187202#zippy=%2Cwindows).

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**).

1. Expand the forest (**Forest:*FQDN***).

1. Expand **Domains**. 

1. Expand your FQDN (for example, `example.com`).

1. Expand **Group Policy Objects**.

1. Select **Default Domain Policy**, open the context (right-click) menu, and choose **Edit**.

1. Choose **Computer Configuration **, **Administrative Templates**, **Google Chrome**, and **Extensions**

1. Open **Configure extension management settings** and set it to **Enabled**.

1. Under **Configure extension management settings**, enter the following:

   ```
   {"mmiioagbgnbojdbcjoddlefhmcocfpmn":{ "installation_mode":"force_installed","update_url":"https://clients2.google.com/service/update2/crx"}}
   ```

1. Choose **OK**.

1. The Group Policy setting change takes effect after the WorkSpace session is restarted. To apply the Group Policy changes, reboot the WorkSpace by going to the Amazon WorkSpaces console and selecting the WorkSpace. Then, choose **Actions**, **Reboot WorkSpaces**).

**Note**  
You can block the installation of the extension by applying the following configuration management setting:  

```
{"mmiioagbgnbojdbcjoddlefhmcocfpmn":{ "installation_mode":"blocked","update_url":"https://clients2.google.com/service/update2/crx"}}
```

### Configure WebRTC redirection for DCV
<a name="gp_webrtc_in_wsp"></a>

WebRTC redirection enhances real-time communication by offloading audio and video processing from WorkSpaces to your local client, which improves performance and reduces latency. However, WebRTC redirection isn't universal and requires third-party application vendors to develop specific integrations with WorkSpaces. By default, WebRTC redirection isn't enabled on WorkSpaces. To use WebRTC redirection, ensure the following:
+ Third-party application vendor integration
+ WorkSpaces extensions are enabled through Group Policy settings
+ WebRTC redirection is enabled
+ WebRTC redirection Browser extension is installed and enabled

**Note**  
This redirection is implemented as an extension and requires you to enable support for WorkSpaces extensions using Group Policy settings. If the extensions are disabled, WebRTC redirection will not function. 

#### Requirements
<a name="w2aac11c31c11c19b5c23b9"></a>

WebRTC redirection for DCV requires the following:
+ DCV host agent version 2.0.0.1622 or higher
+ WorkSpaces clients:
  + Windows 5.21.0 or higher
  + Web client
+ Web browsers installed on your WorkSpaces running the Amazon DCV WebRTC Redirection Extension:
  + Google Chrome 116\$1
  + Microsoft Edge 116\$1

#### Enabling or disabling WebRTC redirection for Windows WorkSpaces
<a name="w2aac11c31c11c19b5c23c11"></a>

If needed, you can enable or disable support for WebRTC redirection for Windows WorkSpaces by using Group Policy settings. If you disable or don't configure this setting, WebRTC redirection will be disabled.

When feature is enabled, web applications that have integration with Amazon WorkSpaces will be able to redirect WebRTC API calls to the local client.

**To configure WebRTC redirection for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Configure WebRTC Redirection** setting.

1. In the **Configure WebRTC Redirection** dialog box, choose **Enabled** or **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the WorkSpace session is restarted. To apply the Group Policy changes, reboot the WorkSpace by going to the Amazon WorkSpaces console and selecting the WorkSpace. Then, choose **Actions**, **Reboot WorkSpaces**).

#### Installing the Amazon DCV WebRTC Redirection Extension
<a name="installing_webrtc"></a>

Users install the Amazon DCV WebRTC Redirection Extension to use WebRTC redirection after the feature is enabled by doing either of the following:
+ Users will be prompted to enable the browser extension in their browser.
**Note**  
As a one-time browser prompt, users will get the notification when you enable WebRTC redirection.
+ You can force install the redirection extension for users using the following GPO policy. If you enable the GPO policy, the extension will automatically be installed when users launch the supported browsers with internet access.
+ Users can install the extension manually with [ Microsoft Edge Add-ons](https://microsoftedge.microsoft.com/addons/detail/amazon-dcv-webrtc-redirec/kjbbkjjiecchbcdoollhgffghfjnbhef) or the [ Chrome Web Store](https://chromewebstore.google.com/detail/dcv-webrtc-redirection-ex/diilpfplcnhehakckkpmcmibmhbingnd?hl=en&authuser=0&pli=1).

##### Manage and install the browser extension using Group Policy
<a name="w2aac11c31c11c19b5c23c13b7"></a>

You can install the Amazon DCV WebRTC Redirection Extension using Group Policy, either centrally from your domain, for session hosts joined to an Active Directory (AD) domain, or using the Local Group Policy Editor for each session host. This process will be different depending on which browser you're using.

**For Microsoft Edge**

1. Download and install the [ Microsoft Edge administrative template](https://learn.microsoft.com/en-us/deployedge/configure-microsoft-edge#1-download-and-install-the-microsoft-edge-administrative-template).

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**).

1. Expand the forest (**Forest:*FQDN***).

1. Expand **Domains**. 

1. Expand your FQDN (for example, `example.com`).

1. Expand **Group Policy Objects**.

1. Select **Default Domain Policy**, open the context (right-click) menu, and choose **Edit**.

1. Choose **Computer Configuration **, **Administrative Templates**, **Microsoft Edge**, and **Extensions**

1. Open **Configure extension management settings** and set it to **Enabled**.

1. Under **Configure extension management settings**, enter the following:

   ```
   {"kjbbkjjiecchbcdoollhgffghfjnbhef":{"installation_mode":"force_installed","update_url":"https://edge.microsoft.com/extensionwebstorebase/v1/crx"}}
   ```

1. Choose **OK**.

1. The Group Policy setting change takes effect after the WorkSpace session is restarted. To apply the Group Policy changes, reboot the WorkSpace by going to the Amazon WorkSpaces console and selecting the WorkSpace. Then, choose **Actions**, **Reboot WorkSpaces**).

**Note**  
You can block the installation of the extension by applying the following configuration management setting:  

```
{"kjbbkjjiecchbcdoollhgffghfjnbhef":{"installation_mode":"blocked","update_url":"https://edge.microsoft.com/extensionwebstorebase/v1/crx"}}
```

**For Google Chrome**

1. Download and install the Google Chrome administrative template. For more information, see [ Set Chrome Browser policies on managed PCs](https://support.google.com/chrome/a/answer/187202#zippy=%2Cwindows).

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**).

1. Expand the forest (**Forest:*FQDN***).

1. Expand **Domains**. 

1. Expand your FQDN (for example, `example.com`).

1. Expand **Group Policy Objects**.

1. Select **Default Domain Policy**, open the context (right-click) menu, and choose **Edit**.

1. Choose **Computer Configuration **, **Administrative Templates**, **Google Chrome**, and **Extensions**

1. Open **Configure extension management settings** and set it to **Enabled**.

1. Under **Configure extension management settings**, enter the following:

   ```
   {"diilpfplcnhehakckkpmcmibmhbingnd":{ "installation_mode":"force_installed","update_url":"https://clients2.google.com/service/update2/crx"}}
   ```

1. Choose **OK**.

1. The Group Policy setting change takes effect after the WorkSpace session is restarted. To apply the Group Policy changes, reboot the WorkSpace by going to the Amazon WorkSpaces console and selecting the WorkSpace. Then, choose **Actions**, **Reboot WorkSpaces**).

**Note**  
You can block the installation of the extension by applying the following configuration management setting:  

```
{"diilpfplcnhehakckkpmcmibmhbingnd":{ "installation_mode":"blocked","update_url":"https://clients2.google.com/service/update2/crx"}}
```

### Configure disconnect session on screen lock for DCV
<a name="gp_lock_screen_in_wsp"></a>

If needed, you can disconnect users' WorkSpaces sessions when the Windows lock screen is detected. To reconnect from the WorkSpaces client, users can use their passwords or their smart cards to authenticate themselves, depending on which type of authentication has been enabled for their WorkSpaces.

This Group Policy setting is disabled by default. If needed, you can enable disconnecting the session when the Windows lock screen is detected for Windows WorkSpaces by using Group Policy settings.

**Note**  
This Group Policy setting applies to both password-authenticated and smart card-authenticated sessions.
To enable the use of smart cards with Windows WorkSpaces, additional steps are required. For more information, see [Use smart cards for authentication in WorkSpaces Personal](smart-cards.md). 

**To configure disconnect session on screen lock for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Enable/disable disconnect session on screen lock** setting.

1. In the **Enable/disable disconnect session on screen lock** dialog box, choose **Enabled** or **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

### Configure Screen Capture Protection for DCV
<a name="screen_capture_protection"></a>

Screen Capture Protection prevents screenshots, screen recordings, and screen sharing of WorkSpaces sessions from local client tools. When enabled, attempts to capture screen content from client side will show either the background or a black rectangle, helping protect sensitive information from exfiltration.

#### Requirements
<a name="w2aac11c31c11c19b5c27b5"></a>

Screen capture protection for DCV requires the following:
+ DCV host agent version 2.2.0.2116 or higher
+ WorkSpaces clients:
  + Windows 5.30.2 or higher
  + MacOS 5.30.2 or higher

**Note**  
 This feature is not supported on Linux clients, Web Access, or PCoIP protocol. 
Protection applies to captures initiated from the client device. Users can still take screenshots from within the WorkSpace itself. 
The feature is not compatible with screen sharing on MS Teams. 

#### Known limitations
<a name="w2aac11c31c11c19b5c27b9"></a>
+ The feature cannot prevent physical camera captures of screens.
+ The feature does not protect against direct RDP connections to the host server.
+ The feature does not protect against capture attempts initiated from within the WorkSpace itself, including screen share features of collaboration and chat tools.
+ All capture methods are blocked when enabled (selective blocking is not available).
+ MacOS client window may be grayed out if the feature is enabled and a video capture is attempted (e.g. trying to screen share the client window).

**To configure Screen Capture Protection for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Configure Screen Capture Protection** setting.

1. In the **Configure Screen Capture Protection** dialog box, choose **Enabled** or **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:

   1. Reboot the WorkSpace (in the WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).

   1. In an administrative command prompt, enter `gpupdate /force`.

### Configure Indirect Display Driver (IDD) for DCV
<a name="indirect_display_driver"></a>

By default, WorkSpaces supports using Indirect Display Driver (IDD). If needed for Windows WorkSpaces, you can use Group Policy settings to disable this feature.

**To configure Indirect Display Driver (IDD) for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Enable the AWS Indirect Display Driver** setting.

1. In the **Enable the AWS Indirect Display Driver** dialog box, choose **Enabled** or **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:

   1. Reboot the WorkSpace (in the WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).

   1. In an administrative command prompt, enter `gpupdate /force`.

### Configure display settings for DCV
<a name="display_settings"></a>

WorkSpaces allows you to configure several different display settings, including the maximum frame rate, minimum image quality, maximum image quality, and YUV encoding. Adjust these settings based on the image quality, responsiveness, and color accuracy that you need. 

By default, the maximum frame rate value is 25. The maximum frame rate value specifies the maximum allowed frames per second (fps). A value of 0 means no limit.

By default, the minimum image quality value is 30. The minimum image quality can be optimized for best image responsiveness, or best image quality. For best responsiveness, reduce the minimum quality. For best quality, increase the minimum quality.
+ Ideal values for best responsiveness are between 30 and 90.
+ Ideal values for best quality are between 60 and 90.

By default, the maximum image quality value is 80. The maximum image quality doesn't affect the image responsiveness or quality, but sets a maximum to limit network usage.

By default, image encoding is set to YUV420. Selecting **Enable YUV444 encoding** enables YUV444 encoding for high color accuracy.

For Windows WorkSpaces, you can use Group Policy settings to configure the maximum frame rate, minimum image quality, and maximum image quality values.

**To configure display settings for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Configure display settings** setting.

1. In the **Configure display settings** dialog box, choose **Enabled** and then set the **Maximum frame rate (fps)**, **minimum image quality**, and **maximum image quality** values to the desired levels.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after you restart the WorkSpace session. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace. the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**
   + In an administrative command prompt, enter **gpupdate /force**.

### Configure VSync for the AWS Virtual Display-Only Driver for DCV
<a name="vsync"></a>

By default, WorkSpaces supports using the VSync feature for the AWS Virtual Display-Only Driver. If needed for Windows WorkSpaces, you can use Group Policy settings to disable this feature.

**To configure VSync for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Enable VSync feature of the AWS Virtual Display Only Driver** setting.

1. In the **Enable VSync feature of the AWS Virtual Display Only Driver** dialog box, choose **Enabled** or **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do the following:

   1. Restart the WorkSpace by doing the either of the following:

      1. Option 1 — In the WorkSpaces console, choose the WorkSpace you want to reboot. Then, choose **Actions**, **Reboot WorkSpaces**.

      1. Option 2 — In an administrative command prompt, enter `gpupdate /force`.

   1. Reconnect to the WorkSpace in order to apply the setting.

   1. Reboot the Workspace again.

### Configure log verbosity for DCV
<a name="log_verbosity"></a>

By default, the log verbosity level for DCV WorkSpaces is set to **Info**. You can set log levels to verbosity levels ranging from least verbose to most verbose, as detailed here:
+ Error – least verbose
+ Warning
+ Info – default
+ Debug – most verbose

For Windows WorkSpaces, you can use Group Policy settings to configure the log verbosity levels.

**To configure log verbosity levels for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Configure log verbosity** setting.

1. In the **Configure log verbosity** dialog box, choose **Enabled** and then set the log verbosity level to **debug**, **error**, **info**, or **warning**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after you restart the WorkSpace session. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace. In the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**.
   + In an administrative command prompt, enter **gpupdate /force**.

### Configure idle disconnect timeout for DCV
<a name="idle-disconnect"></a>

WorkSpaces allows you to configure how long a user can be inactive, while connected to a WorkSpace, before they are disconnected. Examples of user activity input include the following:
+ Keyboard events
+ Mouse events (cursor movement, scrolling, clicking)
+ Stylus events
+ Touch events (tapping touchscreens, tablets)
+ Gamepad events
+ File storage operations (uploads, downloads, directory creation, list items)
+ Webcam streaming

Audio in, audio out, and pixels changing don't qualify as user activity.

When enabling idle disconnect timeout, you can optionally notify your user that their session will disconnect within the configured time unless they engage.

By default, idle disconnect timeout is disabled, the timeout value is set to 0 minutes, and the notification is disabled. If you enable this policy setting, the idle disconnect timeout value defaults to 60 minutes and the idle disconnect warning value defaults to 60 seconds. For Windows WorkSpaces, you can use Group Policy settings to configure this feature.

**To configure idle disconnect timeout for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Configure Idle Disconnect Timeout** setting.

1. In the **Configure Idle Disconnect Timeout** dialog box, choose **Enabled** and then set the desired disconnect timeout value (in minutes), and optionally the warning timer value (in seconds).

1. Choose **Apply**, **OK**.

1. The Group Policy setting change takes effect immediately after you apply the change.

### Configure file transfer for DCV
<a name="gp-file-transfer"></a>

By default, Amazon WorkSpaces disables the file transfer function. You can enable it to allow users to upload and download files between their local computer and WorkSpaces session. The files will be saved in a **My Storage** folder on the WorkSpaces session.

**To enable file transfer for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Configure session storage** setting.

1. In the **Configure Session Storage** dialog box, choose **Enabled**.

1. (Optional) Specify a folder for session storage (for example, `c:/session-storage`). If not specified, the default folder for session storage will be the home folder.

1. You can configure your WorkSpaces with one of the following file transfer options:
   + Choose `Download and Upload` to allow two-way file transfer.
   + Choose `Upload Only` to only allow file uploads from a local computer to your WorkSpaces session.
   + Choose `Download Only` to only allow file downloads from your WorkSpaces session to a local computer.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after you restart the WorkSpace session. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace. In the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**.
   + In an administrative command prompt, enter **gpupdate /force**.

### Configure USB redirection for DCV
<a name="gp_dcv_usbredirection"></a>

#### Overview
<a name="gp_dcv_usbredirection_overview"></a>

Starting with version 2.2.0.2047, Amazon WorkSpaces supports generic USB redirection for DCV-based Windows WorkSpaces, allowing users to access local USB devices within their virtual desktop environments. This feature complements existing optimized redirection solutions for specific device classes.

**Note**  
Amazon recommends using generic redirection only for devices where optimized redirection solutions are not available. Where available, optimized redirection solutions offer better performance.

#### Prerequisites
<a name="gp_dcv_usbredirection_prerequisites"></a>
+ Windows WorkSpaces using DCV protocol version 2.2.0.2047 or later
+ Latest version of WorkSpaces Windows client (version 5.30.0 or later)
+ Administrative access to configure Group Policy settings

#### Configuration
<a name="gp_dcv_usbredirection_config"></a>

USB redirection is disabled by default. You can enable the feature by using Group Policy Objects (GPO). After the feature is enabled, you can add devices to the allowlist for redirection. By default, devices not in the allowlist are not available for redirection.

##### Group Policy Configuration
<a name="gp_dcv_usbredirection_gpo"></a>

**To configure USB redirection for DCV using Group Policy**

1. Connect to the Windows WorkSpaces.

1. Copy policy template files (`wsp.admx` and `wsp.adml`) from the `C:\Program Files\Amazon\WSP` folder.

1. Paste `wsp.admx` into the `C:\Windows\PolicyDefinitions` folder.

1. Paste `wsp.adml` into the `C:\Windows\PolicyDefinitions\en-US` folder.

1. Launch Local GPO Editor (**gpedit.msc**).

1. Navigate to **Local Computer Policy** > **Computer Configuration** > **Administrative Templates** > **Amazon** > **WSP**.

1. Configure **Enable/disable USB** in the WSP setting.

1. Choose **Enabled** to activate USB redirection.

**Note**  
Changes to this setting are applied on the next connection.

#### Device Management
<a name="gp_dcv_usbredirection_device_mgmt"></a>

After USB redirection is enabled, you can configure the device allowlist in the GPO to add devices that you want to support for redirection.

##### Device Allowlist Configuration
<a name="gp_dcv_usbredirection_allowlist"></a>

USB redirection follows a default deny-all security stance. Administrators must explicitly allow devices by adding them to the allowlist in the GPO using the following format:

```
Name, Base class, Subclass, Protocol, Id Vendor, Id Product, Support Auto-share, Skip reset
// Use * to skip any values
```

**Examples:**

**Adding a device with Vendor ID/Product ID:**

```
Credit Card Reader, *, *, *, 0x0483, 0x2016, 1, 0
// Allows Credit Card Reader with VID 0x0483 and PID 0x2016 with auto-share support
```

**Adding a device with Class/Subclass:**

```
3D Mouse Devices, 03, 01, *, *, *, 1, 0
// Allows all 3D mice using HID class (03), boot interface subclass (01), with auto-share support
```

**Note**  
Test devices for compatibility and performance before adding them to the allowlist.

#### Security Considerations
<a name="gp_dcv_usbredirection_security"></a>

##### Best Practices
<a name="gp_dcv_usbredirection_best_practices"></a>
+ Use dedicated redirection methods when available for supported devices for best performance and compatibility. For example, for security keys like YubiKey, use WebAuthn redirection instead.
+ Implement strict device allowlists.
+ Monitor device access through audit logs.
+ Assess data security implications before allowing new devices.

### Configure webcam resolution for DCV
<a name="gp-webcam-resolution"></a>

Use this setting to configure webcam resolution settings. If you enable this policy setting, you can specify:
+ Maximum webcam resolution: This specifies the maximum webcam resolution that can be selected among the resolutions provided. If this value is missing or (0, 0) the default value is used.
+ Preferred webcam resolution: This specifies the preferred webcam resolution among the resolutions provided by the client. If the specified resolution is not supported, the closest matching resolution is selected. If this value is missing or (0, 0) the default value is used.

If you disable or do not configure this policy setting, the default resolutions are used.

**To configure webcam resolution for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Configure webcam resolution** setting.

1. In the **Configure webcam resolution** dialog box, choose **Enabled** and then set the **Maximum webcam resolution** (in pixels) and/or **Preferred webcam resolution** (in pixels).

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after you restart the WorkSpace session. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace. In the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**.
   + In an administrative command prompt, enter **gpupdate /force**.

### Configure server keyboard layout usage for DCV
<a name="gp-server-keyboard-layout"></a>

This setting controls whether to use server side keyboard layout for key interpretation, as opposed to the default client side keyboard layout. Changes to this setting are applied on the next connection. For more details on keyboard handling please see the *Amazon WorkSpaces User Guide*.

If you enable this policy setting, you can choose one of the following options:
+ **Always Off** - Always use client layout
+ **Always On** - Always use server layout

If you disable or do not configure this policy setting, the **Always Off** option is used.

**Note**  
This feature is supported in the Amazon WorkSpaces Windows client version 5.29.2 or newer, and the Amazon WorkSpaces macOS client version 5.30.0 or newer.

**To configure server keyboard layout usage for Windows WorkSpaces**

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Amazon**, and **WSP**.

1. Open the **Configure server keyboard layout usage** setting.

1. In the **Configure server keyboard layout usage** dialog box, choose **Enabled** and then set the **Server keyboard layout option**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after you restart the WorkSpace session. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace. In the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**.
   + In an administrative command prompt, enter **gpupdate /force**.

## Install the Group Policy administrative template for PCoIP
<a name="gp_install_template"></a>

To use the Group Policy settings that are specific to Amazon WorkSpaces when using the PCoIP protocol, you must add the Group Policy administrative template that is appropriate to the version of the PCoIP agent (either 32-bit or 64-bit) that is being used for your WorkSpaces. 

**Note**  
If you have a mix of WorkSpaces with 32-bit and 64-bit agents, you can use the Group Policy administrative templates for 32-bit agents, and your Group Policy settings will be applied to both 32-bit and 64-bit agents. When all of your WorkSpaces are using the 64-bit agent, you can switch to using the administrative template for 64-bit agents.

**To determine whether your WorkSpaces have the 32-bit agent or the 64-bit agent**

1. Log in to a WorkSpace, and then open the Task Manager by choosing **View**, **Send Ctrl \$1 Alt \$1 Delete** or by right-clicking the task bar and choosing **Task Manager**.

1. In the Task Manager, go to the **Details** tab, right-click the column headers, and choose **Select Columns**.

1. In the **Select Columns** dialog box, select **Platform**, and then choose **OK**. 

1. On the **Details** tab, find `pcoip_agent.exe`, and then check its value in the **Platform** column to determine if the PCoIP agent is 32-bit or 64-bit. (You might see a mix of 32-bit and 64-bit WorkSpaces components; this is normal.)

### Install the Group Policy administrative template for PCoIP (32-Bit)
<a name="gp_install_template_pcoip_32_bit"></a>

To use the Group Policy settings that are specific to WorkSpaces when using the PCoIP protocol with the 32-bit PCoIP agent, you must install the Group Policy administrative template for PCoIP. Perform the following procedure on a directory administration WorkSpace or Amazon EC2 instance that is joined to your directory. 

For more information about working with .adm files, see [ Recommendations for managing Group Policy administrative template (.adm) files](https://docs.microsoft.com/troubleshoot/windows-server/group-policy/manage-group-policy-adm-file) in the Microsoft documentation.

**To install the Group Policy administrative template for PCoIP**

1. From a running Windows WorkSpace, make a copy of the `pcoip.adm` file in the `C:\Program Files (x86)\Teradici\PCoIP Agent\configuration` directory.

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**) and navigate to the organizational unit in your domain that contains your WorkSpaces machine accounts.

1. Open the context (right-click) menu for the machine account organizational unit and choose **Create a GPO in this domain, and link it here**.

1. In the **New GPO** dialog box, enter a descriptive name for the GPO, such as **WorkSpaces Machine Policies**, and leave **Source Starter GPO** set to **(none)**. Choose **OK**.

1. Open the context (right-click) menu for the new GPO and choose **Edit**.

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, and **Administrative Templates**. Choose **Action**, **Add/Remove Templates** from the main menu. 

1. In the **Add/Remove Templates** dialog box, choose **Add**, select the `pcoip.adm` file copied previously, and then choose **Open**, **Close**.

1. Close the Group Policy Management Editor. You can now use this GPO to modify the Group Policy settings that are specific to WorkSpaces.

**To verify that the administrative template file is correctly installed**

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**) and navigate to and select the WorkSpaces GPO for your WorkSpaces machine accounts. Choose **Action**, **Edit** in the main menu.

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, **Classic Administrative Templates**, and **PCoIP Session Variables**.

1. You can now use this **PCoIP Session Variables** Group Policy object to modify the Group Policy settings that are specific to Amazon WorkSpaces when using PCoIP. 
**Note**  
To allow the user to override your settings, choose **Overridable Administrator Settings**; otherwise, choose **Not Overridable Administrator Settings**.

### Install the Group Policy administrative template for PCoIP (64-Bit)
<a name="gp_install_template_pcoip_64_bit"></a>

To use the Group Policy settings that are specific to WorkSpaces when using the PCoIP protocol, you must add the Group Policy administrative template `PCoIP.admx` and `PCoIP.adml` files for PCoIP to the Central Store of the domain controller for your WorkSpaces directory. For more information about `.admx` and `.adml` files, see [ How to create and manage the Central Store for Group Policy Administrative Templates in Windows](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra).

The following procedure describes how to create the Central Store and add the administrative template files to it. Perform the following procedure on a directory administration WorkSpace or Amazon EC2 instance that is joined to your WorkSpaces directory.

**To install the Group Policy administrative template files for PCoIP**

1. From a running Windows WorkSpace, make a copy of the `PCoIP.admx` and `PCoIP.adml` files in the `C:\Program Files\Teradici\PCoIP Agent\configuration\policyDefinitions` directory. The `PCoIP.adml` file is in the `en-US` subfolder of that directory.

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open Windows File Explorer, and in the address bar, enter your organization's fully qualified domain name (FQDN), such as `\\example.com`.

1. Open the `sysvol` folder.

1. Open the folder with the `FQDN` name.

1. Open the `Policies` folder. You should now be in `\\FQDN\sysvol\FQDN\Policies`.

1. If it doesn't already exist, create a folder named `PolicyDefinitions`.

1. Open the `PolicyDefinitions` folder.

1. Copy the `PCoIP.admx` file into the `\\FQDN\sysvol\FQDN\Policies\PolicyDefinitions` folder.

1. Create a folder named `en-US` in the `PolicyDefinitions` folder.

1. Open the `en-US` folder.

1. Copy the `PCoIP.adml` file into the `\\FQDN\sysvol\FQDN\Policies\PolicyDefinitions\en-US` folder.

**To verify that the administrative template files are correctly installed**

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**).

1. Expand the forest (**Forest:*FQDN***).

1. Expand **Domains**. 

1. Expand your FQDN (for example, `example.com`).

1. Expand **Group Policy Objects**.

1. Select **Default Domain Policy**, open the context (right-click) menu, and choose **Edit**.
**Note**  
If the domain backing the WorkSpaces is an AWS Managed Microsoft AD directory, you cannot use the Default Domain Policy to create your GPO. Instead, you must create and link the GPO under the domain container that has delegated privileges.  
When you create a directory with AWS Managed Microsoft AD, Directory Service creates a *yourdomainname* organizational unit (OU) under the domain root. The name of this OU is based on the NetBIOS name that you typed when you created your directory. If you didn't specify a NetBIOS name, it will default to the first part of your Directory DNS name (for example, in the case of `corp.example.com`, the NetBIOS name is `corp`).  
To create your GPO, instead of selecting **Default Domain Policy**, select the *yourdomainname* OU (or any OU under that one), open the context (right-click) menu, and choose **Create a GPO in this domain, and Link it here**.   
For more information about the *yourdomainname* OU, see [ What Gets Created](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_what_gets_created.html) in the *AWS Directory Service Administration Guide*.

1. In the Group Policy Management Editor, choose **Computer Configuration**, **Policies**, **Administrative Templates**, and **PCoIP Session Variables**.

1. You can now use this **PCoIP Session Variables** Group Policy object to modify the Group Policy settings that are specific to WorkSpaces when using PCoIP.
**Note**  
To allow the user to override your settings, choose **Overridable Administrator Settings**; otherwise, choose **Not Overridable Administrator Settings**.

## Manage Group Policy settings for PCoIP
<a name="gp_configurations_pcoip"></a>

Use Group Policy settings to manage your Windows WorkSpaces that use PCoIP.

### Configure printer support for PCoIP
<a name="gp_local_printers"></a>

By default, WorkSpaces enables Basic remote printing, which offers limited printing capabilities because it uses a generic printer driver on the host side to ensure compatible printing.

Advanced remote printing for Windows clients lets you use specific features of your printer, such as double-sided printing, but it requires installation of the matching printer driver on the host side.

Remote printing is implemented as a virtual channel. If virtual channels are disabled, remote printing does not function.

For Windows WorkSpaces, you can use Group Policy settings to configure printer support as needed.

**To configure printer support**

1. Make sure that you've installed the most recent [WorkSpaces Group Policy administrative template for PCoIP (32-Bit)](#gp_install_template_pcoip_32_bit) or [WorkSpaces Group Policy administrative template for PCoIP (64-Bit)](#gp_install_template_pcoip_64_bit).

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**) and navigate to **PCoIP Session Variables**.

1. Open the **Configure remote printing** setting.

1. In the **Configure remote printing** dialog box, do one of the following:
   + To enable Advanced remote printing, choose **Enabled**, and then under **Options,** **Configure remote printing**, choose **Basic and Advanced printing for Windows clients**. To automatically use the client computer's current default printer, select **Automatically set default printer**.
   + To disable printing, choose **Enabled**, and then under **Options,** **Configure remote printing**, choose **Printing disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

By default, local printer auto-redirection is disabled. You can use Group Policy settings to enable this feature so that your local printer is set as the default printer every time that you connect to your WorkSpace.

**Note**  
Local printer redirection is not available for Amazon Linux WorkSpaces. 

**To enable local printer auto-redirection**

1. Make sure that you've installed the most recent [WorkSpaces Group Policy administrative template for PCoIP (32-Bit)](#gp_install_template_pcoip_32_bit) or [WorkSpaces Group Policy administrative template for PCoIP (64-Bit)](#gp_install_template_pcoip_64_bit).

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**) and navigate to **PCoIP Session Variables**.

1. Open the **Configure remote printing** setting.

1. Choose **Enabled**, and then under **Options**, **Configure remote printing**, choose one of the following:
   + **Basic and Advanced printing for Windows clients**
   + **Basic printing**

1. Select **Automatically set default printer**, and then choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

### Configure clipboard redirection (copy/paste) for PCoIP
<a name="gp_clipboard"></a>

By default, WorkSpaces supports clipboard redirection. If needed for Windows WorkSpaces, you can use Group Policy settings to disable this feature. 

**To enable or disable clipboard redirection**

1. Make sure that you've installed the most recent [WorkSpaces Group Policy administrative template for PCoIP (32-Bit)](#gp_install_template_pcoip_32_bit) or [WorkSpaces Group Policy administrative template for PCoIP (64-Bit)](#gp_install_template_pcoip_64_bit).

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**) and navigate to **PCoIP Session Variables**.

1. Open the **Configure clipboard redirection** setting.

1. In the **Configure clipboard redirection** dialog box, choose **Enabled** and then choose one of the following settings to determine the direction in which clipboard redirection is allowed. When you're done, choose **OK**.
   + Disabled in both directions
   + Enabled agent to client only (WorkSpace to local computer)
   + Enabled client to agent only (local computer to WorkSpace)
   + Enabled in both directions 

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

**Known limitation**  
With clipboard redirection enabled on the WorkSpace, if you copy content that is larger than 890 KB from a Microsoft Office application, the application might become slow or unresponsive for up to 5 seconds.

### Set the session resume timeout for PCoIP
<a name="gp_auto_resume"></a>

When you lose network connectivity, your active WorkSpaces client session is disconnected. WorkSpaces client applications for Windows and macOS attempt to reconnect the session automatically if network connectivity is restored within a certain amount of time. The default session resume timeout is 20 minutes, but you can modify that value for WorkSpaces that are controlled by your domain's Group Policy settings.

**To set the automatic session resume timeout value**

1. Make sure that you've installed the most recent [WorkSpaces Group Policy administrative template for PCoIP (32-Bit)](#gp_install_template_pcoip_32_bit) or [WorkSpaces Group Policy administrative template for PCoIP (64-Bit)](#gp_install_template_pcoip_64_bit).

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**) and navigate to **PCoIP Session Variables**.

1. Open the **Configure Session Automatic Reconnection Policy** setting.

1. In the **Configure Session Automatic Reconnection Policy** dialog box, choose **Enabled**, set the **Configure Session Automatic Reconnection Policy** option to the desired timeout, in minutes, and choose **OK**. 

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

### Configure audio-in redirection for PCoIP
<a name="gp_audio"></a>

By default, Amazon WorkSpaces supports redirecting data from a local microphone. If needed for Windows WorkSpaces, you can use Group Policy settings to disable this feature.

**Note**  
If you have a Group Policy setting that restricts users' local logon in their WorkSpaces, audio-in won't work on your WorkSpaces. If you remove that Group Policy setting, the audio-in feature is enabled after the next reboot of the WorkSpace. For more information about this Group Policy setting, see [ Allow logon locally](https://docs.microsoft.com/windows/security/threat-protection/security-policy-settings/allow-log-on-locally) in the Microsoft documentation.

**To enable or disable audio-in redirection**

1. Make sure that you've installed the most recent [WorkSpaces Group Policy administrative template for PCoIP (32-Bit)](#gp_install_template_pcoip_32_bit) or [WorkSpaces Group Policy administrative template for PCoIP (64-Bit)](#gp_install_template_pcoip_64_bit).

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**) and navigate to **PCoIP Session Variables**.

1. Open the **Enable/disable audio in the PCoIP session** setting.

1. In the **Enable/disable audio in the PCoIP session** dialog box, choose **Enabled** or **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

### Disable time zone redirection for PCoIP
<a name="gp_time_zone"></a>

By default, the time within a Workspace is set to mirror the time zone of the client that is being used to connect to the WorkSpace. This behavior is controlled through time zone redirection. You might want to turn off time zone direction for various reasons: 
+ Your company wants all employees to work in a certain time zone (even if some employees are in other time zones).
+ You have scheduled tasks in a WorkSpace that are meant to run at a certain time in a specific time zone.
+ Your users who travel a lot want to keep their WorkSpaces in one time zone for consistency and personal preference.

If needed for Windows WorkSpaces, you can use Group Policy settings to disable this feature.

**To disable time zone redirection**

1. Make sure that you've installed the most recent [WorkSpaces Group Policy administrative template for PCoIP (32-Bit)](#gp_install_template_pcoip_32_bit) or [WorkSpaces Group Policy administrative template for PCoIP (64-Bit)](#gp_install_template_pcoip_64_bit).

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**) and navigate to **PCoIP Session Variables**.

1. Open the **Configure timezone redirection** setting.

1. In the **Configure timezone redirection** dialog box, choose **Disabled**.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

1. Set the time zone for the WorkSpaces to the desired time zone.

The time zone of the WorkSpaces is now static and no longer mirrors the time zone of the client machines. 

### Configure PCoIP security settings
<a name="gp_security"></a>

For PCoIP, data in transit is encrypted using TLS 1.2 encryption and SigV4 request signing. The PCoIP protocol uses encrypted UDP traffic, with AES encryption, for streaming pixels. The streaming connection, using port 4172 (TCP and UDP), is encrypted by using AES-128 and AES-256 ciphers, but the encryption defaults to 128-bit. You can change this default to 256-bit by using the **Configure PCoIP Security Settings** Group Policy setting.

You can also use this Group Policy setting to modify the TLS Security Mode and to block certain cipher suites. A detailed explanation of these settings and the supported cipher suites is provided in the **Configure PCoIP Security Settings** Group Policy dialog box. 

**To configure PCoIP security settings**

1. Make sure that you've installed the most recent [WorkSpaces Group Policy administrative template for PCoIP (32-Bit)](#gp_install_template_pcoip_32_bit) or [WorkSpaces Group Policy administrative template for PCoIP (64-Bit)](#gp_install_template_pcoip_64_bit).

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**) and navigate to **PCoIP Session Variables**.

1. Open the **Configure PCoIP Security Settings** setting.

1. In the **Configure PCoIP Security Settings** dialog box, choose **Enabled**. To set the default encryption for streaming traffic to 256-bit, go to the **PCoIP Data Encryption Ciphers** option, and select **AES-256-GCM only**.

1. (Optional) Adjust the **TLS Security Mode** setting, and then list any cipher suites that you want to block. For more information about these settings, see the descriptions provided in the **Configure PCoIP Security Settings** dialog box.

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

### Configure USB redirection for PCoIP
<a name="gp_usbredirection"></a>

**Note**  
Amazon WorkSpaces currently supports USB redirection only for YubiKey U2F. Other types of USB devices might be redirected but they are not supported and might not work properly. 

**To enable USB redirection for PCoIP**

1. Make sure that you've installed the most recent [WorkSpaces Group Policy administrative template for PCoIP (32-Bit)](#gp_install_template_pcoip_32_bit) or [WorkSpaces Group Policy administrative template for PCoIP (64-Bit)](#gp_install_template_pcoip_64_bit).

1. On a directory administration WorkSpace or an Amazon EC2 instance that is joined to your WorkSpaces directory, open the Group Policy Management tool (**gpmc.msc**) and navigate to **PCoIP Session Variables**.

1. Open the **Enable/disable USB in the PCOIP session** setting.

1.  Choose **Enabled**, and then choose **OK**. 

1. Open the **Configure PCoIP USB allowed and unallowed device rules** setting.

1. Choose **Enabled**, and under **Enter the USB authorization table (maximum ten rules)**, configure your USB device allow list rules.

   1. Authorization rule - 110500407. This value is a combination of a Vendor ID (VID) and a Product ID (PID). The format for a VID/PID combination is 1xxxxyyyy, where xxxx is the VID in hexadecimal format and yyyy is the PID in hexadecimal format. For this example, 1050 is the VID, and 0407 is the PID. For more YubiKey USB values, see [YubiKey USB ID Values](https://support.yubico.com/hc/en-us/articles/360016614920-YubiKey-USB-ID-Values).

1. Under **Enter the USB authorization table (maximum ten rules)**, configure your USB device block list rules. 

   1. For **Unauthorization Rule**, set an empty string. This means that only USB devices in the authorization list are allowed.
**Note**  
You can define a maximum of 10 USB authorization rules and a maximum of 10 USB unauthorization rules. Use the vertical bar (\$1) character to separate multiple rules. For detailed information about the authorization/unauthorization rules, see [Teradici PCoIP Standard Agent for Windows](https://www.teradici.com/web-help/pcoip_agent/standard_agent/windows/20.10/admin-guide/configuring/configuring/#pcoip-usb-allowed-and-unallowed-device-rules). 

1. Choose **OK**.

1. The Group Policy setting change takes effect after the next Group Policy update for the WorkSpace and after the WorkSpace session is restarted. To apply the Group Policy changes, do one of the following:
   + Reboot the WorkSpace (in the Amazon WorkSpaces console, select the WorkSpace, then choose **Actions**, **Reboot WorkSpaces**).
   + In an administrative command prompt, enter **gpupdate /force**.

After the setting takes effect, all supported USB devices can redirect to WorkSpaces unless restrictions are configured through the USB device rules setting.

## Set the maximum lifetime for a Kerberos ticket
<a name="gp_kerberos_ticket"></a>

If you have not disabled the **Remember Me** feature of your Windows WorkSpaces, your WorkSpace users can use the **Remember Me** or **Keep me logged in** check box in their WorkSpaces client application to save their credentials. This feature allows users to easily connect to their WorkSpaces while the client application remains running. Their credentials are securely cached up to the maximum lifetime of their Kerberos tickets.

If your WorkSpace uses an AD Connector directory, you can modify the maximum lifetime of the Kerberos tickets for your WorkSpaces users through Group Policy by following the steps in [ Maximum Lifetime for a User Ticket](https://docs.microsoft.com/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket) in the Microsoft Windows documentation.

To enable or disable the **Remember Me** feature, see [Enable self-service WorkSpaces management capabilities for your users in WorkSpaces Personal](enable-user-self-service-workspace-management.md).

## Configure device proxy server settings for internet access
<a name="gp_device_proxy"></a>

By default, the WorkSpaces client applications use the proxy server that’s specified in the device operating system settings for HTTPS (port 443) traffic. The Amazon WorkSpaces client applications use the HTTPS port for updates, registration, and authentication. 

**Note**  
Proxy servers that require authentication with sign-in credentials are not supported.

You can configure the device proxy server settings for your Windows WorkSpaces through Group Policy by following the steps in [ Configure device proxy and internet connectivity settings](https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/configure-proxy-internet) in the Microsoft documentation.

For more information about configuring the proxy settings in the WorkSpaces Windows client application, see [ Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-windows-client.html#windows_proxy_server) in the *Amazon WorkSpaces User Guide*. 

For more information about configuring the proxy settings in the WorkSpaces macOS client application, see [ Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-osx-client.html#osx_proxy_server) in the *Amazon WorkSpaces User Guide*.

For more information about configuring the proxy settings in the WorkSpaces Web Access client application, see [ Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-web-access.html#web-access-proxy) in the *Amazon WorkSpaces User Guide*.

### Proxying desktop traffic
<a name="w2aac11c31c11c27c15"></a>

For PCoIP WorkSpaces, the desktop client applications do not support the use of a proxy server nor TLS decryption and inspection for port 4172 traffic in UDP (for desktop traffic). They require a direct connection to ports 4172. 

For DCV WorkSpaces, the WorkSpaces Windows client application (version 5.1 and above) and macOS client application (version 5.4 and above) support the use of HTTP proxy servers for port 4195 TCP traffic. TLS decryption and inspection are not supported.

DCV does not support the use of proxy for desktop traffic over UDP. Only WorkSpaces Windows and macOS desktop client applications and web access support the use of proxy, for TCP traffic. 

**Note**  
If you choose to use a proxy server, the API calls that the client application makes to the WorkSpaces services are also proxied. Both API calls and desktop traffic should pass through the same proxy server. 

### Recommendation on the use of proxy servers
<a name="w2aac11c31c11c27c17"></a>

We do not recommend the use of a proxy server with your WorkSpaces desktop traffic.

Amazon WorkSpaces desktop traffic is already encrypted, so proxies do not improve security. A proxy represents an additional hop in the network path that could impact streaming quality by introducing latency. Proxies could also potentially reduce throughput if a proxy is not properly sized to handle desktop streaming traffic. Furthermore, most proxies are not designed for supporting long running WebSocket (TCP) connections and may affect streaming quality and stability. 

If you must use a proxy, please locate your proxy server as close to the WorkSpace client as possible, preferably in the same network, to avoid adding network latency, which could negatively impact streaming quality and responsiveness.

## Enable Amazon WorkSpaces for Zoom Meeting Media Plugin support
<a name="zoom-integration"></a>

Zoom supports optimized real-time communication for DCV and PCoIP Windows-based WorkSpaces, with the Zoom VDI Plugin. Direct client communication allows video calls to bypass the cloud-based virtual desktop and provide a local-like Zoom experience when the meeting is running inside the your user’s WorkSpace.

### Enable Zoom Meeting Media Plugin for DCV
<a name="zoom-wsp"></a>

Before installing the Zoom VDI components, update your WorkSpaces configuration to support Zoom optimization.

#### Prerequisites
<a name="zoom-integ-prerequisites-wsp"></a>

Before using the plugin, make sure the following requirements are met.
+ Windows WorkSpaces client version 5.10.0\$1 with [ Zoom VDI Plugin](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0066757#h_01H6PE29K2S6NPYCC3SWB667AT:~:text=Zoom%20Meeting%20client.-,Install%20the%20Zoom%20VDI%20plugin,-To%20complete%20your) version 5.17.10\$1
+ Within your WorkSpaces — [ Zoom VDI Meeting](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0063810) client version 5.17.10\$1

#### Before you begin
<a name="zoom-begin-wsp"></a>

1. Enable the **Extensions** Group Policy setting. For more information, see [Configure extensions for DCV](#extensions).

1. Disable the **Automatic reconnect** Group Policy setting. For more information, see [Set the session resume timeout for DCV](#gp_auto_resume_wsp).

#### Installing the Zoom components
<a name="installing-zoom-wsp"></a>

To enable Zoom optimization, install two components, provided by Zoom, on your Windows WorkSpaces. For more information, see[ Using Zoom for Amazon Web Services](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0066757#h_01H6PE29K2S6NPYCC3SWB667AT).

1. Install the Zoom VDI Meeting client version 5.12.6\$1 within your WorkSpace.

1. Install the Zoom VDI Plugin (Windows Universal Installer) version 5.12.6\$1 on the client where your WorkSpace is installed

1. Validate the plugin is optimizing the Zoom traffic, by confirming that your VDI Plugin Status shows as **Connected** within the Zoom VDI client. For more information, see [ How to confirm Amazon WorkSpaces optimization ](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0066757#h_01H6PE1MA5YMYFX5B5XM873V1Y).

### Enable Zoom Meeting Media Plugin for PCoIP
<a name="zoom-pcoip"></a>

Users with administrative permission to Active Directory can generate a registry key using their Group Policy Object (GPO). This allows users to send the registry key to all the Windows WorkSpaces within your domain using a forced update. Alternatively, users with administrative rights can also install registry keys individually on their WorkSpaces host.

#### Prerequisites
<a name="zoom-integ-prerequisites-pcoip"></a>

Before using the plugin, make sure the following requirements are met.
+ Windows WorkSpaces client version 5.4.0\$1 with [ Zoom VDI Plugin](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0066757#h_01H6PE29K2S6NPYCC3SWB667AT:~:text=Zoom%20Meeting%20client.-,Install%20the%20Zoom%20VDI%20plugin,-To%20complete%20your) version 5.12.6\$1.
+ Within your WorkSpaces — [ Zoom VDI Meeting](https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0063810) client version 5.12.6\$1.

#### Create the registry key on a Windows WorkSpaces host
<a name="zoom-integ-create-registry-key"></a>

Complete the following procedure to create a registry key on a Windows WorkSpaces host. The registry key is required to use Zoom on Windows WorkSpaces.

1. Open Windows Registry Editor as an administrator.

1. Go to `\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Amazon`.

1. If the **Extension** key doesn't exist, right-click and choose **New** > **Key** and name it **Extension**.

1. In the new **Extension** key, right-click and choose **New** > **DWORD** and name it **enable**. The name must be in lower-case.

1. Choose the new **DWORD** and change the **Value** to **1**.

1. Reboot the computer to complete the process.

1. On your WorkSpaces host, download and install the latest Zoom VDI client. On your WorkSpaces client (5.4 or higher), download and install the latest Zoom VDI client plugin for Amazon WorkSpaces. For more information, see [VDI releases and downloads](https://support.zoom.us/hc/en-us/articles/4415057249549-VDI-releases-and-downloads) on the *Zoom support website*.

Launch Zoom to start your video call.

#### Troubleshooting
<a name="zoom-integ-troubleshoot"></a>

Complete the following actions to troubleshoot Zoom on Windows WorkSpaces.
+ Confirm that The Registry Key Activation and Applied Correctly.
+ Go to `C:\ProgramData\Amazon\Amazon WorkSpaces Extension`. You should see `wse_core_dll`.
+ Make sure that the versions on the host and clients are correct and the same.

If you continue to experience difficulty, contact Support using the [Support Center](https://console.aws.amazon.com/support/home#/). 

You can use the following examples to apply a GPO as an administrator of your directory.
+ **WSE.adml**

  ```
  <?xml version="1.0" encoding="utf-8"?>
  <policyDefinitionResources xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="1.0" schemaVersion="1.0" xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
      <!-- 'displayName' and 'description' don't appear anywhere. All Windows native GPO template files have them set like this. -->
      <displayName>enter display name here</displayName>
      <description>enter description here</description>
  
      <resources>
      <stringTable>
          <string id="SUPPORTED_ProductOnly">N/A</string>
          <string id="Amazon">Amazon</string>
          <string id="Amazon_Help">Amazon Group Policies</string>
          <string id="WorkspacesExtension">Workspaces Extension</string>
          <string id="WorkspacesExtension_Help">Workspace Extension Group Policies</string>
  
          <!-- Extension Itself -->
          <string id="ToggleExtension">Enable/disable Extension Virtual Channel</string>
          <string id="ToggleExtension_Help">
  Allows two-way Virtual Channel data communication for multiple purposes
  
  By default, Extension is disabled.</string>
  
      </stringTable>
      </resources>
  </policyDefinitionResources>
  ```
+ **WSE.admx**

  ```
  <?xml version="1.0" encoding="utf-8"?>
  <policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="1.0" schemaVersion="1.0" xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
      <policyNamespaces>
          <target prefix="WorkspacesExtension" namespace="Microsoft.Policies.Amazon.WorkspacesExtension" />
      </policyNamespaces>
      <supersededAdm fileName="wse.adm" />
      <resources minRequiredRevision="1.0" />
      <supportedOn>
          <definitions>
              <definition name="SUPPORTED_ProductOnly" displayName="$(string.SUPPORTED_ProductOnly)"/>
          </definitions>
      </supportedOn>
      <categories>
          <category name="Amazon" displayName="$(string.Amazon)" explainText="$(string.Amazon_Help)" />
          <category name="WorkspacesExtension" displayName="$(string.WorkspacesExtension)" explainText="$(string.WorkspacesExtension_Help)">
              <parentCategory ref="Amazon" />
          </category>
      </categories>
  
      <policies>
          <policy name="ToggleExtension" class="Machine" displayName="$(string.ToggleExtension)" explainText="$(string.ToggleExtension_Help)" key="Software\Policies\Amazon\Extension" valueName="enable">
              <parentCategory ref="WorkspacesExtension" />
              <supportedOn ref="SUPPORTED_ProductOnly" />
              <enabledValue>
                  <decimal value="1" />
              </enabledValue>
              <disabledValue>
                  <decimal value="0" />
              </disabledValue>
          </policy>
      </policies>
  </policyDefinitions>
  ```

# Manage your Amazon Linux 2 WorkSpaces in WorkSpaces Personal
<a name="manage_linux_workspace"></a>

For workloads that require RPM Package Manager (RPM), we recommend using [ Red Hat Enterprise Linux](https://docs.aws.amazon.com/workspaces/latest/adminguide/manage_rhel_workspace.html) or [Rocky Linux](https://docs.aws.amazon.com/workspaces/latest/adminguide/manage_rockylinux_workspace.html). Amazon Linux 2 may not provide the latest versions of some applications and libraries, such as Firefox and glibc, that you may need.

Because Linux instances do not adhere to Group Policy, we recommend that you use a configuration management solution to distribute and enforce policy. For example, you can use [Ansible](https://www.ansible.com/).

**Note**  
Local printer redirection is not available for Amazon Linux WorkSpaces.

## Control DCV behavior on Amazon Linux WorkSpaces
<a name="wsp_agent_linux"></a>

The behavior of DCV is controlled by configuration settings in the `wsp.conf` file, which is located in the `/etc/wsp/` directory. To deploy and enforce changes to the policy, use a configuration management solution that supports Amazon Linux. Any changes take effect when the agent starts up.

**Note**  
If you make incorrect or unsupported changes to the `wsp.conf` file, policy changes may not be applied to the newly established connections on your WorkSpace.
Amazon Linux WorkSpaces on DCV bundles currently have the following limitations:  
Currently only available in the AWS GovCloud (US-West) and AWS GovCloud (US-East).
Video-in is not supported. 
Disconnect session on screen lock is not supported.

The following sections describe how to enable or disable certain features.

## Configure clipboard redirection for DCV Amazon Linux WorkSpaces
<a name="wsp_linux_clipboard"></a>

By default, WorkSpaces supports clipboard redirection. Use the DCV configuration file to configure this feature, if needed. This setting takes effect when you disconnect and reconnect the WorkSpace.

**To configure clipboard redirection for DCV Amazon Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. 

   ```
   clipboard = X
   ```

   Where the possible values for *X* are:

   `enabled` — Clipboard redirection is enabled in both directions (default)

   `disabled` — Clipboard redirection is disabled in both directions

   `paste-only` — Clipboard redirection is enabled but only allows you to copy contents from the local client device and paste it to the remote host desktop

   `copy-only` — Clipboard redirection is enabled but only allows you to copy contents from the remote host desktop and paste it to the local client device

## Enable or disable audio-in redirection for DCV Amazon Linux WorkSpaces
<a name="wsp_linux_audio"></a>

By default, WorkSpaces supports audio-in redirection. Use the DCV configuration file to disable this feature, if needed. This setting takes effect when you disconnect and reconnect to the WorkSpace.

**To enable or disable audio-in redirection for DCV Amazon Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the file.

   ```
   audio-in = X
   ```

   Where the possible values for *X* are:

   `enabled` — Audio-in redirection is enabled (default)

   `disabled` — Audio-in redirection is disabled

## Enable or disable time zone redirection for DCV Amazon Linux WorkSpaces
<a name="linux_time_zone_wsp"></a>

By default, the time within a Workspace is set to mirror the time zone of the client that is being used to connect to the WorkSpace. This behavior is controlled through time zone redirection. You might want to turn off time zone direction for reasons such as the following: 
+ Your company wants all employees to work in a certain time zone (even if some employees are in other time zones).
+ You have scheduled tasks in a WorkSpace that are meant to run at a certain time in a specific time zone.
+ Your users who travel a lot want to keep their WorkSpaces in one time zone for consistency and personal preference.

Use the DCV configuration file to configure this feature, if needed. This setting takes effect after you disconnect and reconnect to the WorkSpace.

**To enable or disable time zone redirection for DCV Amazon Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp-agent/wsp.conf
   ```

1. Add the following line to the end of the file.

   ```
   timezone_redirect= X
   ```

   Where the possible values for *X* are:

   **enabled** — Time zone redirection is enabled (default)

   **disabled** — Time zone redirection is disabled

## Control PCoIP Agent behavior on Amazon Linux WorkSpaces
<a name="pcoip_agent_linux"></a>

The behavior of the PCoIP Agent is controlled by configuration settings in the `pcoip-agent.conf` file, which is located in the `/etc/pcoip-agent/` directory. To deploy and enforce changes to the policy, use a configuration management solution that supports Amazon Linux. Any changes take effect when the agent starts up. Restarting the agent ends any open connections and restarts the window manager. To apply any changes, we recommend rebooting the WorkSpace. 

**Note**  
If you make incorrect or unsupported changes to the `pcoip-agent.conf` file, you might cause your WorkSpace to stop working. If your WorkSpace stops working, you might need to either [connect to your WorkSpace using SSH](connect-to-linux-workspaces-with-ssh.md) to roll back the changes, or you might have to [ rebuild the WorkSpace](rebuild-workspace.md).

The following sections describe how to enable or disable certain features. For a full listing of the available settings, run `man pcoip-agent.conf` from the terminal on any Amazon Linux WorkSpace.

## Configure clipboard redirection for PCoIP Amazon Linux WorkSpaces
<a name="linux_clipboard"></a>

By default, WorkSpaces supports clipboard redirection. Use the PCoIP Agent conf to disable this feature, if needed. This setting takes effect when you reboot the WorkSpace.

**To configure clipboard redirection for PCoIP Amazon Linux WorkSpaces**

1. Open the `pcoip-agent.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/pcoip-agent/pcoip-agent.conf
   ```

1. Add the following line to the end of the file.

   ```
   pcoip.server_clipboard_state = X
   ```

   Where the possible values for *X* are:

   0 — Clipboard redirection is disabled in both directions

   1 — Clipboard redirection is enabled in both directions

   2 — Clipboard redirection is enabled client to agent only (allow copy and paste only from local client device to the remote host desktop)

   3 — Clipboard redirection is enabled agent to client only (allow copy and paste only from the remote host desktop to the local client device)

**Note**  
Clipboard redirection is implemented as a virtual channel. If virtual channels are disabled, clipboard redirection doesn't work. To enable virtual channels, see [ PCoIP Virtual Channels](https://www.teradici.com/web-help/pcoip_agent/standard_agent/linux/20.07/admin-guide/configuring/configuring/#pcoip-virtual-channels) in the Teradici documentation.

## Enable or disable audio-in redirection for PCoIP Amazon Linux WorkSpaces
<a name="linux_audio"></a>

By default, WorkSpaces supports audio-in redirection. Use the PCoIP Agent conf to disable this feature, if needed. This setting takes effect when you reboot the WorkSpace.

**To enable or disable audio-in redirection for PCoIP Amazon Linux WorkSpaces**

1. Open the `pcoip-agent.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/pcoip-agent/pcoip-agent.conf
   ```

1. Add the following line to the end of the file.

   ```
   pcoip.enable_audio = X
   ```

   Where the possible values for *X* are:

   0 — Audio-in redirection is disabled

   1 — Audio-in redirection is enabled

## Enable or disable time zone redirection for PCoIP Amazon Linux WorkSpaces
<a name="linux_time_zone"></a>

By default, the time within a Workspace is set to mirror the time zone of the client that is being used to connect to the WorkSpace. This behavior is controlled through time zone redirection. You might want to turn off time zone direction for reasons such as the following: 
+ Your company wants all employees to work in a certain time zone (even if some employees are in other time zones).
+ You have scheduled tasks in a WorkSpace that are meant to run at a certain time in a specific time zone.
+ Your users who travel a lot want to keep their WorkSpaces in one time zone for consistency and personal preference.

If needed for Linux WorkSpaces, you can use the PCoIP Agent conf to disable this feature. This setting takes effect when you reboot the WorkSpace.

**To enable or disable time zone redirection for PCoIP Amazon Linux WorkSpaces**

1. Open the `pcoip-agent.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/pcoip-agent/pcoip-agent.conf
   ```

1. Add the following line to the end of the file.

   ```
   pcoip.enable_timezone_redirect= X
   ```

   Where the possible values for *X* are:

   0 — Time zone redirection is disabled

   1 — Time zone redirection is enabled

## Grant SSH access to Amazon Linux WorkSpaces administrators
<a name="linux_ssh"></a>

By default, only assigned users and accounts in the Domain Admins group can connect to Amazon Linux WorkSpaces by using SSH. 

We recommend that you create a dedicated administrators group for your Amazon Linux WorkSpaces administrators in Active Directory.

**To enable sudo access for members of the Linux\$1Workspaces\$1Admins Active Directory group**

1. Edit the `sudoers` file by using `visudo`, as shown in the following example.

   ```
   [example\username@workspace-id ~]$ sudo visudo
   ```

1. Add the following line.

   ```
   %example.com\\Linux_WorkSpaces_Admins ALL=(ALL) ALL 
   ```

After you create the dedicated administrators group, follow these steps to enable login for members of the group.

**To enable login for members of the Linux\$1WorkSpaces\$1Admins Active Directory group**

1. Edit `/etc/security/access.conf` with elevated rights.

   ```
   [example\username@workspace-id ~]$ sudo vi /etc/security/access.conf
   ```

1. Add the following line.

   ```
   +:(example\Linux_WorkSpaces_Admins):ALL 
   ```

For more information about enabling SSH connections, see [Enable SSH connections for your Linux WorkSpaces in WorkSpaces Personal](connect-to-linux-workspaces-with-ssh.md).

## Override the default shell for Amazon Linux WorkSpaces
<a name="linux_shell"></a>

To override the default shell for Linux WorkSpaces, we recommend that you edit the user's `~/.bashrc` file. For example, to use `Z shell` instead of `Bash` shell, add the following lines to `/home/username/.bashrc`.

```
export SHELL=$(which zsh)
[ -n "$SSH_TTY" ] && exec $SHELL
```

**Note**  
After making this change, you must either reboot the WorkSpace or log out of the WorkSpace (not just disconnect) and then log back in for the change to take effect.

## Protect custom repositories from unauthorized access
<a name="password_protect_repos"></a>

To control access to your custom repositories, we recommend using the security features built into Amazon Virtual Private Cloud (Amazon VPC) rather than using passwords. For example, use network access control lists (ACLs) and security groups. For more information about these features, see [Security](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html) in the *Amazon VPC User Guide*.

If you must use passwords to protect your repositories, be sure to create your `yum` repository definition files as shown in [Repository Definition Files](https://docs.fedoraproject.org/en-US/Fedora_Core/3/html/Software_Management_Guide/sn-writing-repodefs.html) in the Fedora documentation.

## Use the Amazon Linux Extras Library repository
<a name="linux_extras"></a>

With Amazon Linux, you can use the Extras Library to install application and software updates on your instances. For information about using the Extras Library, see [Extras Library (Amazon Linux)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-ami-basics.html#extras-library) in the *Amazon EC2 User Guide for Linux Instances*.

**Note**  
If you are using the Amazon Linux repository, your Amazon Linux WorkSpaces must have internet access, or you must configure virtual private cloud (VPC) endpoints to this repository and to the main Amazon Linux repository. For more information, see [Provide internet access for WorkSpaces Personal](amazon-workspaces-internet-access.md).

## Use smart cards for authentication on Linux WorkSpaces
<a name="linux_smart_cards"></a>

Linux WorkSpaces on DCV bundles allow the use of [Common Access Card (CAC)](https://www.cac.mil/Common-Access-Card) and [Personal Identity Verification (PIV)](https://piv.idmanagement.gov/) smart cards for authentication. For more information, see [Use smart cards for authentication in WorkSpaces Personal](smart-cards.md).

## Configure device proxy server settings for internet access
<a name="gp_device_proxy_linux"></a>

By default, the WorkSpaces client applications use the proxy server that’s specified in the device operating system settings for HTTPS (port 443) traffic. The Amazon WorkSpaces client applications use the HTTPS port for updates, registration, and authentication. 

**Note**  
Proxy servers that require authentication with sign-in credentials are not supported.

You can configure the device proxy server settings for your Linux WorkSpaces through Group Policy by following the steps in [ Configure device proxy and internet connectivity settings](https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/configure-proxy-internet) in the Microsoft documentation.

For more information about configuring the proxy settings in the WorkSpaces Windows client application, see [ Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-windows-client.html#windows_proxy_server) in the *Amazon WorkSpaces User Guide*. 

For more information about configuring the proxy settings in the WorkSpaces macOS client application, see [ Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-osx-client.html#osx_proxy_server) in the *Amazon WorkSpaces User Guide*.

For more information about configuring the proxy settings in the WorkSpaces Web Access client application, see [ Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-web-access.html#web-access-proxy) in the *Amazon WorkSpaces User Guide*.

### Proxying desktop traffic
<a name="w2aac11c31c13c35c15"></a>

For PCoIP WorkSpaces, the desktop client applications do not support the use of a proxy server nor TLS decryption and inspection for port 4172 traffic in UDP (for desktop traffic). They require a direct connection to ports 4172. 

For DCV WorkSpaces, the WorkSpaces Windows client application (version 5.1 and above) and macOS client application (version 5.4 and above) support the use of HTTP proxy servers for port 4195 TCP traffic. TLS decryption and inspection are not supported.

DCV does not support the use of proxy for desktop traffic over UDP. Only WorkSpaces Windows and macOS desktop client applications and web access support the use of proxy, for TCP traffic. 

**Note**  
If you choose to use a proxy server, the API calls that the client application makes to the WorkSpaces services are also proxied. Both API calls and desktop traffic should pass through the same proxy server. 

### Recommendation on the use of proxy servers
<a name="w2aac11c31c13c35c17"></a>

We do not recommend the use of a proxy server with your WorkSpaces desktop traffic.

Amazon WorkSpaces desktop traffic is already encrypted, so proxies do not improve security. A proxy represents an additional hop in the network path that could impact streaming quality by introducing latency. Proxies could also potentially reduce throughput if a proxy is not properly sized to handle desktop streaming traffic. Furthermore, most proxies are not designed for supporting long running WebSocket (TCP) connections and may affect streaming quality and stability. 

If you must use a proxy, please locate your proxy server as close to the WorkSpace client as possible, preferably in the same network, to avoid adding network latency, which could negatively impact streaming quality and responsiveness.

# Manage your Ubuntu WorkSpaces in WorkSpaces Personal
<a name="manage_ubuntu_workspace"></a>

Your Ubuntu WorkSpaces bundle includes a subscription of Ubuntu Pro from Canonical. As with Windows and Amazon Linux WorkSpaces, Ubuntu WorkSpaces are domain joined, so you can use Active Directory Users and Groups to:
+ Administer your Ubuntu WorkSpaces
+ Provide access to those WorkSpaces for users

You can manage Ubuntu WorkSpaces with Group Policy by using ADsys. See the [Ubuntu Active Directory integration FAQ](https://ubuntu.com/blog/new-active-directory-integration-features-in-ubuntu-22-04-faq) for more information. You can also use other configuration and management solutions, such as [Landscape](https://ubuntu.com/landscape) and [Ansible](https://www.ansible.com/). 

## Control DCV behavior on Ubuntu WorkSpaces
<a name="wsp_ubuntu"></a>

The behavior of DCV is controlled by configuration settings in the `wsp.conf` file, which is located in the `/etc/wsp/` directory. To deploy and enforce changes to the policy, use a configuration management solution that supports Ubuntu. Any changes take effect when the agent starts up.

**Note**  
If you make incorrect or unsupported changes to the `wsp.conf` policies may not be applied to the new established connections to your WorkSpace.

The following sections describe how to enable or disable certain features.

## Enable or disable clipboard redirection for Ubuntu WorkSpaces
<a name="ubuntu_clipboard"></a>

By default, WorkSpaces supports clipboard redirection. Use the DCV configuration file to disable this feature, if needed.

**To enable or disable clipboard redirection for Ubuntu WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   clipboard = X
   ```

   Where the possible values for *X* are:

   **enabled** — Clipboard redirection is enabled in both directions (default)

   **disabled** — Clipboard redirection is disabled in both directions

   **paste-only** — Clipboard redirection is enabled and only allows you to copy contents from the local client device and paste it to the remote host desktop

   **copy-only** — Clipboard redirection is enabled and only allows you to copy contents from the remote host desktop and paste it to the local client device

## Enable or disable audio-in redirection for Ubuntu WorkSpaces
<a name="ubuntu_audio"></a>

By default, WorkSpaces supports audio-in redirection. Use the DCV configuration file to disable this feature, if needed.

**To enable or disable audio-in redirection for Ubuntu WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   audio-in = X
   ```

   Where the possible values for *X* are:

   **enabled** — Audio-in redirection is enabled (default)

   **disabled** — Audio-in redirection is disabled

## Enable or disable video-in redirection for Ubuntu WorkSpaces
<a name="ubuntu_video"></a>

By default, WorkSpaces supports video-in redirection. Use the DCV configuration file to disable this feature, if needed.

**To enable or disable video-in redirection for Ubuntu WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   video-in = X
   ```

   Where the possible values for *X* are:

   **enabled** — Video-in redirection is enabled (default)

   **disabled** — Video-in redirection is disabled

## Enable or disable time zone redirection for Ubuntu WorkSpaces
<a name="ubuntu-time-zone"></a>

By default, the time within a Workspace is set to mirror the time zone of the client that is being used to connect to the WorkSpace. This behavior is controlled through time zone redirection. You might want to turn off time zone direction for reasons such as the following:
+ Your company wants all employees to work in a certain time zone (even if some employees are in other time zones).
+ You have scheduled tasks in a WorkSpace that are meant to run at a certain time in a specific time zone.
+ Your users travel a lot and want to keep their WorkSpaces in one time zone for consistency and personal preference.

Use the DCV configuration file to configure this feature, if needed.

**To enable or disable time zone redirection for Ubuntu WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   timezone-redirection = X
   ```

   Where the possible values for *X* are:

   **enabled** — Time zone redirection is enabled (default)

   **disabled** — Time zone redirection is disabled

## Enable or disable printer redirection for Ubuntu WorkSpaces
<a name="ubuntu_printer"></a>

By default, WorkSpaces supports printer redirection. Use the DCV configuration file to disable this feature, if needed.

**To enable or disable printer redirection for Ubuntu WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   remote-printing = X
   ```

   Where the possible values for *X* are:

   **enabled** — Printer redirection is enabled (default)

   **disabled** — Printer redirection is disabled

## Enable or disable disconnect session on screen lock for DCV
<a name="ubuntu_screenlock"></a>

Enable disconnect session on screen lock to allow your users to end their WorkSpaces session when the lock screen is detected. To reconnect from the WorkSpaces client, users can use their passwords or their smart cards to authenticate themselves, depending on which type of authentication has been enabled for their WorkSpaces.

By default, WorkSpaces doesn’t support disconnecting session on screen lock. Use the DCV configuration file to enable this feature, if needed.

**To enable or disable disconnect session on screen lock for Ubuntu WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   disconnect-on-lock = X
   ```

   Where the possible values for *X* are:

   **enabled** — Disconnect on screen lock is enabled

   **disabled** — Disconnect on screen lock is disabled (default)

## Grant SSH access to Ubuntu WorkSpaces administrators
<a name="grant_ssh_access_ubuntu"></a>

By default, only assigned users and accounts in the Domain Admins group can connect to Ubuntu WorkSpaces by using SSH. To enable other users and accounts to connect to Ubuntu WorkSpaces using SSH, we recommend that you create a dedicated administrators group for your Ubuntu WorkSpaces administrators in Active Directory.

**To enable sudo access for members of the `Linux_WorkSpaces_Admins` Active Directory group**

1. Edit the `sudoers` file by using `visudo`, as shown in the following example.

   ```
   [username@workspace-id ~]$ sudo visudo
   ```

1. Add the following line.

   ```
   %Linux_WorkSpaces_Admins ALL=(ALL) ALL
   ```

After you create the dedicated administrators group, follow these steps to enable login for members of the group.

**To enable login for members of the `Linux_WorkSpaces_Admins` Active Directory group**

1. Edit /`etc/security/access.conf` with elevated rights.

   ```
   [username@workspace-id ~]$ sudo vi /etc/security/access.conf
   ```

1. Add the following line.

   ```
   +:(Linux_WorkSpaces_Admins):ALL
   ```

 With Ubuntu WorkSpaces you do not need to add a domain name when specifying username for SSH connection, and by default, password authentication is disabled. To connect via SSH, you needs to either add your SSH public key to `$HOME/.ssh/authorized_keys` on your Ubuntu WorkSpace, or edit `/etc/ssh/sshd_config` to set PasswordAuthentication to `yes`. For more information about enabling SSH connections, see [ Enable SSH connections for your Linux WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/connect-to-linux-workspaces-with-ssh.html). 

## Override the default shell for Ubuntu WorkSpaces
<a name="override_default_shell_ubuntu"></a>

To override the default shell for Ubuntu WorkSpaces, we recommend that you edit the user's `~/.bashrc` file. For example, to use `Z shell` instead of `Bash` shell, add the following lines to `/home/username/.bashrc`.

```
export SHELL=$(which zsh)
[ -n "$SSH_TTY" ] && exec $SHELL
```

**Note**  
After making this change, you must either reboot the WorkSpace or log out of the WorkSpace (not just disconnect) and then log back in for the change to take effect.

## Use smart cards for authentication on Ubuntu WorkSpaces
<a name="linux_smart_cards"></a>

Ubuntu WorkSpaces bundles allow the use of [Common Access Card (CAC)](https://www.cac.mil/Common-Access-Card) and [Personal Identity Verification (PIV)](https://piv.idmanagement.gov/) smart cards for authentication. For more information, see [Use smart cards for authentication in WorkSpaces Personal](smart-cards.md).

## Configure device proxy server settings for internet access
<a name="gp_device_proxy_ubuntu"></a>

By default, the WorkSpaces client applications use the proxy server that’s specified in the device operating system settings for HTTPS (port 443) traffic. The Amazon WorkSpaces client applications use the HTTPS port for updates, registration, and authentication. 

**Note**  
Proxy servers that require authentication with sign-in credentials are not supported.

You can configure the device proxy server settings for your Ubuntu WorkSpaces through Group Policy by following the steps in [ Configure device proxy and internet connectivity settings](https://docs.microsoft.com/windows/security/threat-protection/microsoft-defender-atp/configure-proxy-internet) in the Microsoft documentation.

For more information about configuring the proxy settings in the WorkSpaces Windows client application, see [ Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-windows-client.html#windows_proxy_server) in the *Amazon WorkSpaces User Guide*. 

For more information about configuring the proxy settings in the WorkSpaces macOS client application, see [ Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-osx-client.html#osx_proxy_server) in the *Amazon WorkSpaces User Guide*.

For more information about configuring the proxy settings in the WorkSpaces Web Access client application, see [ Proxy Server](https://docs.aws.amazon.com/workspaces/latest/userguide/amazon-workspaces-web-access.html#web-access-proxy) in the *Amazon WorkSpaces User Guide*.

### Proxying desktop traffic
<a name="w2aac11c31c15c29c15"></a>

For PCoIP WorkSpaces, the desktop client applications do not support the use of a proxy server nor TLS decryption and inspection for port 4172 traffic in UDP (for desktop traffic). They require a direct connection to ports 4172. 

For DCV WorkSpaces, the WorkSpaces Windows client application (version 5.1 and above) and macOS client application (version 5.4 and above) support the use of HTTP proxy servers for port 4195 TCP traffic. TLS decryption and inspection are not supported.

DCV does not support the use of proxy for desktop traffic over UDP. Only WorkSpaces Windows and macOS desktop client applications and web access support the use of proxy, for TCP traffic. 

**Note**  
If you choose to use a proxy server, the API calls that the client application makes to the WorkSpaces services are also proxied. Both API calls and desktop traffic should pass through the same proxy server. 

### Recommendation on the use of proxy servers
<a name="w2aac11c31c15c29c17"></a>

We do not recommend the use of a proxy server with your WorkSpaces desktop traffic.

Amazon WorkSpaces desktop traffic is already encrypted, so proxies do not improve security. A proxy represents an additional hop in the network path that could impact streaming quality by introducing latency. Proxies could also potentially reduce throughput if a proxy is not properly sized to handle desktop streaming traffic. Furthermore, most proxies are not designed for supporting long running WebSocket (TCP) connections and may affect streaming quality and stability. 

If you must use a proxy, please locate your proxy server as close to the WorkSpace client as possible, preferably in the same network, to avoid adding network latency, which could negatively impact streaming quality and responsiveness.

# Manage your Rocky Linux WorkSpaces
<a name="manage_rockylinux_workspace"></a>

You can manage Rocky Linux WorkSpaces with configuration and management solutions, such as [Ansible](https://www.ansible.com/). 

**Note**  
You may not remove, modify, or obscure any copyright, trademark, or other proprietary or confidentiality notices that are contained in or on the Rocky Linux software. 

## Control DCV behavior on Rocky Linux WorkSpaces
<a name="wsp_rockylinux"></a>

The behavior of DCV is controlled by configuration settings in the `wsp.conf` file, which is located in the `/etc/wsp/` directory. To deploy and enforce changes to the policy, use a configuration management solution that supports Rocky Linux. Any changes take effect when the agent starts up.

**Note**  
If you make incorrect or unsupported changes to the `wsp.conf` policies may not be applied to the new established connections to your WorkSpace.

The following sections describe how to enable or disable certain features.

## Enable or disable clipboard redirection for Rocky Linux WorkSpaces
<a name="rockylinux_clipboard"></a>

By default, WorkSpaces supports clipboard redirection. Use the DCV configuration file to disable this feature, if needed.

**To enable or disable clipboard redirection for Rocky Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   clipboard = X
   ```

   Where the possible values for *X* are:

   **enabled** — Clipboard redirection is enabled in both directions (default)

   **disabled** — Clipboard redirection is disabled in both directions

   **paste-only** — Clipboard redirection is enabled and only allows you to copy contents from the local client device and paste it to the remote host desktop

   **copy-only** — Clipboard redirection is enabled and only allows you to copy contents from the remote host desktop and paste it to the local client device

## Enable or disable audio-in redirection for Rocky Linux WorkSpaces
<a name="rockylinux_audio"></a>

By default, WorkSpaces supports audio-in redirection. Use the DCV configuration file to disable this feature, if needed.

**To enable or disable audio-in redirection for Rocky Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   audio-in = X
   ```

   Where the possible values for *X* are:

   **enabled** — Audio-in redirection is enabled (default)

   **disabled** — Audio-in redirection is disabled

## Enable or disable video-in redirection for Rocky Linux WorkSpaces
<a name="rockylinux_video"></a>

By default, WorkSpaces supports video-in redirection. Use the DCV configuration file to disable this feature, if needed.

**To enable or disable video-in redirection for Rocky Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   video-in = X
   ```

   Where the possible values for *X* are:

   **enabled** — Video-in redirection is enabled (default)

   **disabled** — Video-in redirection is disabled

## Enable or disable time zone redirection for Rocky Linux WorkSpaces
<a name="rockylinux-time-zone"></a>

By default, the time within a Workspace is set to mirror the time zone of the client that is being used to connect to the WorkSpace. This behavior is controlled through time zone redirection. You might want to turn off time zone direction for reasons such as the following:
+ Your company wants all employees to work in a certain time zone (even if some employees are in other time zones).
+ You have scheduled tasks in a WorkSpace that are meant to run at a certain time in a specific time zone.
+ Your users travel a lot and want to keep their WorkSpaces in one time zone for consistency and personal preference.

Use the DCV configuration file to configure this feature, if needed.

**To enable or disable time zone redirection for Rocky Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   timezone-redirection = X
   ```

   Where the possible values for *X* are:

   **enabled** — Time zone redirection is enabled (default)

   **disabled** — Time zone redirection is disabled

## Enable or disable printer redirection for Rocky Linux WorkSpaces
<a name="rockylinux_printer"></a>

By default, WorkSpaces supports printer redirection. Use the DCV configuration file to disable this feature, if needed.

**To enable or disable printer redirection for Rocky Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   remote-printing = X
   ```

   Where the possible values for *X* are:

   **enabled** — Printer redirection is enabled (default)

   **disabled** — Printer redirection is disabled

## Enable or disable disconnect session on screen lock for DCV
<a name="rockylinux_screenlock"></a>

Enable disconnect session on screen lock to allow your users to end their WorkSpaces session when the lock screen is detected. To reconnect from the WorkSpaces client, users can use their passwords or their smart cards to authenticate themselves, depending on which type of authentication has been enabled for their WorkSpaces.

By default, WorkSpaces doesn’t support disconnecting session on screen lock. Use the DCV configuration file to enable this feature, if needed.

**To enable or disable disconnect session on screen lock for Rocky Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   disconnect-on-lock = X
   ```

   Where the possible values for *X* are:

   **enabled** — Disconnect on screen lock is enabled

   **disabled** — Disconnect on screen lock is disabled (default)

## Grant SSH access to Rocky Linux WorkSpaces administrators
<a name="grant_ssh_access_rockylinux"></a>

By default, only assigned users and accounts in the Domain Admins group can connect to Rocky Linux WorkSpaces by using SSH. To enable other users and accounts to connect to Rocky Linux WorkSpaces using SSH, we recommend that you create a dedicated administrators group for your Rocky Linux WorkSpaces administrators in Active Directory.

**To enable sudo access for members of the `Linux_WorkSpaces_Admins` Active Directory group**

1. Edit the `sudoers` file by using `visudo`, as shown in the following example.

   ```
   [username@workspace-id ~]$ sudo visudo
   ```

1. Add the following line.

   ```
   %Linux_WorkSpaces_Admins ALL=(ALL) ALL
   ```

After you create the dedicated administrators group, follow these steps to enable login for members of the group.

**To enable login for members of the `Linux_WorkSpaces_Admins` Active Directory group**

1. Edit /`etc/security/access.conf` with elevated rights.

   ```
   [username@workspace-id ~]$ sudo vi /etc/security/access.conf
   ```

1. Add the following line.

   ```
   +:(Linux_WorkSpaces_Admins):ALL
   ```

 With Rocky Linux WorkSpaces you do not need to add a domain name when specifying username for SSH connection, and by default, password authentication is disabled. To connect via SSH, you needs to either add your SSH public key to `$HOME/.ssh/authorized_keys` on your Rocky Linux WorkSpace, or edit `/etc/ssh/sshd_config` to set PasswordAuthentication to `yes`. For more information about enabling SSH connections, see [ Enable SSH connections for your Linux WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/connect-to-linux-workspaces-with-ssh.html). 

## Override the default shell for Rocky Linux WorkSpaces
<a name="override_default_shell_rockylinux"></a>

To override the default shell for Rocky Linux WorkSpaces, we recommend that you edit the user's `~/.bashrc` file. For example, to use `Z shell` instead of `Bash` shell, add the following lines to `/home/username/.bashrc`.

```
export SHELL=$(which zsh)
[ -n "$SSH_TTY" ] && exec $SHELL
```

**Note**  
After making this change, you must either reboot the WorkSpace or log out of the WorkSpace (not just disconnect) and then log back in for the change to take effect.

## Use smart cards for authentication on Rocky Linux WorkSpaces
<a name="linux_smart_cards"></a>

Rocky Linux WorkSpaces bundles allow the use of [Common Access Card (CAC)](https://www.cac.mil/Common-Access-Card) and [Personal Identity Verification (PIV)](https://piv.idmanagement.gov/) smart cards for authentication. For more information, see [Use smart cards for authentication in WorkSpaces Personal](smart-cards.md).

# Manage your Red Hat Enterprise Linux WorkSpaces
<a name="manage_rhel_workspace"></a>

You can manage Red Hat Enterprise Linux WorkSpaces with configuration and management solutions, such as [Ansible](https://www.ansible.com/). 

## Control DCV behavior on Red Hat Enterprise Linux WorkSpaces
<a name="wsp_rhel"></a>

The behavior of DCV is controlled by configuration settings in the `wsp.conf` file, which is located in the `/etc/wsp/` directory. To deploy and enforce changes to the policy, use a configuration management solution that supports Red Hat Enterprise Linux. Any changes take effect when the agent starts up.

**Note**  
If you make incorrect or unsupported changes to the `wsp.conf` policies may not be applied to the new established connections to your WorkSpace.

The following sections describe how to enable or disable certain features.

## Enable or disable clipboard redirection for Red Hat Enterprise Linux WorkSpaces
<a name="rhel_clipboard"></a>

By default, WorkSpaces supports clipboard redirection. Use the DCV configuration file to disable this feature, if needed.

**To enable or disable clipboard redirection for Red Hat Enterprise Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   clipboard = X
   ```

   Where the possible values for *X* are:

   **enabled** — Clipboard redirection is enabled in both directions (default)

   **disabled** — Clipboard redirection is disabled in both directions

   **paste-only** — Clipboard redirection is enabled and only allows you to copy contents from the local client device and paste it to the remote host desktop

   **copy-only** — Clipboard redirection is enabled and only allows you to copy contents from the remote host desktop and paste it to the local client device

## Enable or disable audio-in redirection for Red Hat Enterprise Linux WorkSpaces
<a name="rhel_audio"></a>

By default, WorkSpaces supports audio-in redirection. Use the DCV configuration file to disable this feature, if needed.

**To enable or disable audio-in redirection for Red Hat Enterprise Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   audio-in = X
   ```

   Where the possible values for *X* are:

   **enabled** — Audio-in redirection is enabled (default)

   **disabled** — Audio-in redirection is disabled

## Enable or disable video-in redirection for Red Hat Enterprise Linux WorkSpaces
<a name="rhel_video"></a>

By default, WorkSpaces supports video-in redirection. Use the DCV configuration file to disable this feature, if needed.

**To enable or disable video-in redirection for Red Hat Enterprise Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   video-in = X
   ```

   Where the possible values for *X* are:

   **enabled** — Video-in redirection is enabled (default)

   **disabled** — Video-in redirection is disabled

## Enable or disable time zone redirection for Red Hat Enterprise Linux WorkSpaces
<a name="rhel-time-zone"></a>

By default, the time within a Workspace is set to mirror the time zone of the client that is being used to connect to the WorkSpace. This behavior is controlled through time zone redirection. You might want to turn off time zone direction for reasons such as the following:
+ Your company wants all employees to work in a certain time zone (even if some employees are in other time zones).
+ You have scheduled tasks in a WorkSpace that are meant to run at a certain time in a specific time zone.
+ Your users travel a lot and want to keep their WorkSpaces in one time zone for consistency and personal preference.

Use the DCV configuration file to configure this feature, if needed.

**To enable or disable time zone redirection for Red Hat Enterprise Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   timezone-redirection = X
   ```

   Where the possible values for *X* are:

   **enabled** — Time zone redirection is enabled (default)

   **disabled** — Time zone redirection is disabled

## Enable or disable printer redirection for Red Hat Enterprise Linux WorkSpaces
<a name="rhel_printer"></a>

By default, WorkSpaces supports printer redirection. Use the DCV configuration file to disable this feature, if needed.

**To enable or disable printer redirection for Red Hat Enterprise Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   remote-printing = X
   ```

   Where the possible values for *X* are:

   **enabled** — Printer redirection is enabled (default)

   **disabled** — Printer redirection is disabled

## Enable or disable disconnect session on screen lock for DCV
<a name="rhel_screenlock"></a>

Enable disconnect session on screen lock to allow your users to end their WorkSpaces session when the lock screen is detected. To reconnect from the WorkSpaces client, users can use their passwords or their smart cards to authenticate themselves, depending on which type of authentication has been enabled for their WorkSpaces.

By default, WorkSpaces doesn’t support disconnecting session on screen lock. Use the DCV configuration file to enable this feature, if needed.

**To enable or disable disconnect session on screen lock for Red Hat Enterprise Linux WorkSpaces**

1. Open the `wsp.conf` file in an editor with elevated rights by using the following command.

   ```
   [domain\username@workspace-id ~]$ sudo vi /etc/wsp/wsp.conf
   ```

1. Add the following line to the end of the `[policies]` group.

   ```
   disconnect-on-lock = X
   ```

   Where the possible values for *X* are:

   **enabled** — Disconnect on screen lock is enabled

   **disabled** — Disconnect on screen lock is disabled (default)

## Grant SSH access to Red Hat Enterprise Linux WorkSpaces administrators
<a name="grant_ssh_access_rhel"></a>

By default, only assigned users and accounts in the Domain Admins group can connect to Red Hat Enterprise Linux WorkSpaces by using SSH. To enable other users and accounts to connect to Red Hat Enterprise Linux WorkSpaces using SSH, we recommend that you create a dedicated administrators group for your Red Hat Enterprise Linux WorkSpaces administrators in Active Directory.

**To enable sudo access for members of the `Linux_WorkSpaces_Admins` Active Directory group**

1. Edit the `sudoers` file by using `visudo`, as shown in the following example.

   ```
   [username@workspace-id ~]$ sudo visudo
   ```

1. Add the following line.

   ```
   %Linux_WorkSpaces_Admins ALL=(ALL) ALL
   ```

After you create the dedicated administrators group, follow these steps to enable login for members of the group.

**To enable login for members of the `Linux_WorkSpaces_Admins` Active Directory group**

1. Edit /`etc/security/access.conf` with elevated rights.

   ```
   [username@workspace-id ~]$ sudo vi /etc/security/access.conf
   ```

1. Add the following line.

   ```
   +:(Linux_WorkSpaces_Admins):ALL
   ```

 With Red Hat Enterprise Linux WorkSpaces you do not need to add a domain name when specifying username for SSH connection, and by default, password authentication is disabled. To connect via SSH, you needs to either add your SSH public key to `$HOME/.ssh/authorized_keys` on your Red Hat Enterprise Linux WorkSpace, or edit `/etc/ssh/sshd_config` to set PasswordAuthentication to `yes`. For more information about enabling SSH connections, see [ Enable SSH connections for your Linux WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/connect-to-linux-workspaces-with-ssh.html). 

## Override the default shell for Red Hat Enterprise Linux WorkSpaces
<a name="override_default_shell_rhel"></a>

To override the default shell for Red Hat Enterprise Linux WorkSpaces, we recommend that you edit the user's `~/.bashrc` file. For example, to use `Z shell` instead of `Bash` shell, add the following lines to `/home/username/.bashrc`.

```
export SHELL=$(which zsh)
[ -n "$SSH_TTY" ] && exec $SHELL
```

**Note**  
After making this change, you must either reboot the WorkSpace or log out of the WorkSpace (not just disconnect) and then log back in for the change to take effect.

## Use smart cards for authentication on Red Hat Enterprise Linux WorkSpaces
<a name="linux_smart_cards"></a>

Red Hat Enterprise Linux WorkSpaces bundles allow the use of [Common Access Card (CAC)](https://www.cac.mil/Common-Access-Card) and [Personal Identity Verification (PIV)](https://piv.idmanagement.gov/) smart cards for authentication. For more information, see [Use smart cards for authentication in WorkSpaces Personal](smart-cards.md).

# Optimize WorkSpaces for real-time communication in WorkSpaces Personal
<a name="communication-optimization"></a>

Amazon WorkSpaces offers a diverse range of techniques to facilitate the deployment of Unified Communication (UC) applications like Microsoft Teams, Zoom, Webex and others. In contemporary application landscapes, most UC applications consist of a variety of features, including 1:1 chat rooms, collaborative group chat channels, seamless file storage and exchange, live events, webinars, broadcasts, interactive screen sharing and control, whiteboarding, and offline audio/video messaging capabilities. Most of this functionality is seamlessly available on WorkSpaces as standard features, without the need for additional fine-tuning or enhancement. However, it's worth noting that real-time communication elements, particularly one-on-one calling and collective group meetings, represent an exception to this rule. The successful incorporation of such functionality frequently demands dedicated focus and planning during the process of WorkSpaces deployment.

When planning your implementation of real-time communication functionalities of UC applications on Amazon WorkSpaces, you have three distinct Real-Time Communication (RTC) configuration modes to choose from. The selection of which depends on the specific application or applications that you intend to provide to your users and the client devices you plan to use.

This document focus on optimizing the user experience for the most common UC applications in Amazon WorkSpaces. For WorkSpaces Core specific optimizations, please refer to the partner-specific documentation.

**Topics**
+ [

## Overview of media optimization modes
](#media-optimization-modes-overview)
+ [

## Which RTC optimization mode to use?
](#choosing-optimization-mode)
+ [

## RTC Optimization Guidance
](#rtc-optimization-guidance)

## Overview of media optimization modes
<a name="media-optimization-modes-overview"></a>

Following are the media optimization options available.

### Option 1: Media Optimized Real-Time Communication (Media Optimized RTC)
<a name="media-optimized-rtc"></a>

In this mode, third-party UC and VoIP applications are executed on the remote WorkSpace, while their media framework is offloaded to the supported client for direct communication. The following UC applications use this approach on Amazon WorkSpaces:
+ [Zoom meetings](https://support.zoom.us/hc/en-us/articles/10372235268749-Using-Zoom-for-Amazon-WorkSpaces)
+ [Cisco Webex meetings](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/wbxt/vdi/wbx-vdi-deployment-guide.html)
+ [Microsoft Teams 2.0 (Public Preview)](https://learn.microsoft.com/en-us/microsoftteams/vdi-2)

For Media Optimized RTC mode to function, the UC application vendor should develop the integration with WorkSpaces using one of the available Software Development Kits (SDK), such as the [DCV Extension SDK](https://docs.aws.amazon.com/dcv/latest/extsdkguide/what-is.html). This mode requires the UC components to be installed on the client device.

For more information about configuring this mode, see [Configure Media Optimized RTC](#configure-media-optimized-rtc).

### Option 2: In-Session Optimized Real-Time Communication (In-session Optimized RTC)
<a name="in-session-optimized-rtc"></a>

In this mode, the unaltered UC application runs on the WorkSpace, channeling audio and video traffic via the DCV to the client device. Local audio from the microphone and video stream from a webcam are redirected to the WorkSpace, where they are consumed by the UC application. This mode provides broad application compatibility and efficiently delivers the UC application from the remote WorkSpace to a variety of client platforms. You don't need to deploy the UC application components to the client device.

For more information about configuring this mode, see [Configure In-session Optimized RTC](#configure-in-session-optimized-rtc).

### Option 3: Direct Real-Time Communication (Direct RTC)
<a name="direct-rtc"></a>

In this mode, the application operating within the WorkSpace takes control over the physical or virtual telephone set located on the user's desk or client OS. This results in the audio traffic traversing directly from the physical telephone at the user's workstation or the virtual phone operating on the client device to the remote call peer. Notable instances of applications functioning within this mode encompass:
+ [Amazon Connect Optimization for Amazon WorkSpaces](https://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/connect-optimization.html)
+ [Genesys Cloud WebRTC media helper](https://help.mypurecloud.com/articles/about-webrtc-media-helper/)
+ [Microsoft Teams SIP Gateway](https://learn.microsoft.com/en-us/microsoftteams/sip-gateway-plan)
+ [Microsoft Teams Desk phones and Teams displays](https://www.microsoft.com/en-us/microsoft-teams/across-devices/devices/category/desk-phones-teams-displays/34)
+ Participation in audio conferencing through the dial-in or "dial my phone" features of the UC application.

For more information about configuring this mode, see [Configure Direct RTC](#configure-direct-rtc).

## Which RTC optimization mode to use?
<a name="choosing-optimization-mode"></a>

Different RTC optimization modes can be employed concurrently or set up to complement each other as a fallback. For instance, consider enabling Media Optimized RTC for Cisco Webex meetings. This configuration ensures that users experience optimized communication when accessing WorkSpace through a desktop client. However, in scenarios where Webex is accessed from a shared internet kiosk lacking UC optimization components, Webex will seamlessly transition to In-session Optimized RTC mode to maintain functionality. When users engage with multiple UC applications, the RTC configuration modes may vary based on their unique requirements.

The following table represents common UC application features and defines which RTC configuration mode provides the best result.


| Feature | Direct RTC | Media Optimized RTC | In-session Optimized RTC | 
| --- | --- | --- | --- | 
| **1:1 chat** | Does not require RTC configuration | 
| **Group chat rooms** | Does not require RTC configuration | 
| **Group audio conferencing** | Best | Best | Good | 
| **Group video conferencing** | Good | Best | Good | 
| **1:1 audio calls** | Best | Best | Good | 
| **1:1 video calls** | Good | Best | Good | 
| **Whiteboarding** | Does not require RTC configuration | 
| **Audio/video clips/messaging** | Not applicable | Good | Best | 
| **File Sharing** | Not applicable | Depends on UC application | Best | 
| **Screen sharing and control** | Not applicable | Depends on UC application | Best | 
| **Webinars/Broadcast events** | Not applicable | Good | Best | 

## RTC Optimization Guidance
<a name="rtc-optimization-guidance"></a>

### Configure Media Optimized RTC
<a name="configure-media-optimized-rtc"></a>

Media Optimized RTC mode is made possible by the UC application vendor use of the SDKs provided by Amazon. The architecture requires UC vendor to develop a UC-specific plugin or extension and deploy it to the client.

The SDK, which includes publicly available options like the DCV Extension SDK and customized private versions, establishes a control channel between the UC application module operating within the WorkSpace and a plugin on the client side. Typically, this control channel instructs the client extension to initiate or join a call. Once the call is established through the client-side extension, the UC plugin captures audio from the microphone and video from the webcam, which are then transmitted directly to the UC cloud or a call peer. The incoming audio is played locally, and video is overlaid on the remote client UI. The control channel is responsible for communicating the call's status.

![\[Diagram showing the Media Optimized RTC configuration.\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/images/media-optimized-rtc.png)


Amazon WorkSpaces currently supports following applications with Media Optimized RTC mode:
+ [Zoom meetings](https://support.zoom.us/hc/en-us/articles/10372235268749-Using-Zoom-for-Amazon-WorkSpaces) (for PCoIP and DCV WorkSpaces)
+ [Cisco Webex meetings](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/wbxt/vdi/wbx-vdi-deployment-guide.html) (for DCV WorkSpaces only)
+ [Microsoft Teams 2.0 (Public Preview)](https://learn.microsoft.com/en-us/microsoftteams/vdi-2) (for DCV WorkSpaces only)

If you are using an application that is not on the list, it is advisable to engage the application vendor and request support for WorkSpaces Media Optimized RTC. To expedite this process, encourage them to contact [aws-av-offloading@amazon.com](mailto:aws-av-offloading@amazon.com).

While Media Optimized RTC mode enhances call performance and minimizes WorkSpace resource utilization, it does possess certain limitations:
+ The UC client extension must be installed on the client device.
+ The UC client extension requires independent management and updates.
+ UC client extensions might not be available on certain client platforms, such as, mobile platforms, or web clients.
+ Some UC application functionalities could be constrained in this mode; for instance, screen sharing behavior might differ.
+ Usage of client-side extensions might not be suitable for scenarios like Bring Your Own Device (BYOD) or shared kiosks.

If Media Optimized RTC mode proves unsuitable for your environment or certain users are unable to install the client extension, configuring In-session Optimized RTC mode as a fallback option is recommended.

### Configure In-session Optimized RTC
<a name="configure-in-session-optimized-rtc"></a>

In the In-session Optimized RTC mode, the UC application operates on the WorkSpace without any modifications, providing a like-local experience. The audio and video streams generated by the application are captured by DCV and transmitted to the client side. At the client, the microphone (on both DCV and PCoIP WorkSpaces) and webcam (only on DCV WorkSpaces) signals are captured, redirected back to the WorkSpace, and seamlessly passed to the UC application.

Notably, this option ensures exceptional compatibility, even with legacy applications, offering a cohesive user experience regardless of the application's origin. In-session optimization works with web client as well.

![\[Diagram showing the In-session Optimized RTC configuration.\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/images/in-session-optimized-rtc.png)


DCV has been meticulously optimized to enhance the performance of Remote RTC mode. The optimization measures encompass:
+ Utilization of an Adaptive UDP-based QUIC transport, ensuring efficient data transmission.
+ Establishment of a low-latency audio path, facilitating fast audio input and output.
+ Implementation of voice-optimized audio codecs to maintain audio quality while reducing CPU and network utilization.
+ Webcam redirection, enabling the integration of webcam functionalities.
+ Configuration of webcam resolution to optimize performance.
+ Integration of adaptive display codecs to balance speed and visual quality.
+ Audio jitter correction, guaranteeing smooth audio transmission.

These optimizations collectively contribute to a robust and fluid experience in Remote RTC mode.

#### Sizing recommendations
<a name="sizing-recommendations"></a>

To effectively support Remote RTC mode, it's crucial to ensure proper sizing of Amazon WorkSpaces. The remote WorkSpace must meet or exceed the system requirements of the respective Unified Communication (UC) application. The following table outlines the minimum supported and recommended WorkSpaces configurations for popular UC applications when used for video and audio calls:


|   | Video calls | Audio calls |   | Application | CPU requirements for RTC app | RAM requirements for RTC app | Minimally supported WorkSpace | Recommended WorkSpace | Minimally supported WorkSpace | Recommended WorkSpace | Reference | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| Microsoft Teams | 2 core required, 4 core recommended | 4.0 GB RAM | Power (4 vCPU, 16 GB memory) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/communication-optimization.html)  | Performance (2 vCPU, 8 GB memory) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/communication-optimization.html)  | [Hardware requirements for Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/hardware-requirements-for-the-teams-app) | 
| Zoom | 2 core required, 4 core recommended | 4.0 GB RAM | Power (4 vCPU, 16 GB memory) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/communication-optimization.html)  | Performance (2 vCPU, 8 GB memory) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/communication-optimization.html)  | [Zoom system requirements: Windows, macOS, Linux](https://support.zoom.us/hc/en-us/articles/201362023-Zoom-system-requirements-Windows-macOS-Linux) | 
| Webex | 2 core required | 4.0 GB RAM | Power (4 vCPU, 16 GB memory) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/communication-optimization.html)  | Performance (2 vCPU, 8 GB memory) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/communication-optimization.html)  | [System requirements for Webex services](https://help.webex.com/en-us/article/fz1e4b/System-requirements-for-Webex-services) | 

It's important to note that video conferencing involves significant resource usage for video encoding and decoding. In physical machine scenarios, these tasks are offloaded to the GPU. In non-GPU WorkSpaces, these tasks are performed on the CPU in parallel with remote protocol encoding. Therefore, for users regularly engaged in video streaming or video calls, opting for the PowerPro or higher configuration is highly recommended.

Screen sharing also consumes notable resources, with resource consumption increasing with higher resolutions. As result, on non-GPU WorkSpaces, screen sharing is often limited to a lower frame rate.

#### Leverage the UDP-based QUIC transport with DCV
<a name="leaverage-udp-based-quic-transport"></a>

UDP transport is particularly well-suited for transmitting RTC applications. To maximize efficiency, ensure that your network is set up to utilize QUIC transport for DCV. Note that UDP-based transport is available with native clients only.

#### Configure UC application for WorkSpaces
<a name="configure-uc-application"></a>

For enhanced video processing capabilities, such as background blur, virtual backgrounds, reactions, or hosting live events, opting for a GPU-enabled WorkSpace is essential to achieve optimal performance.

Most of the UC applications provide guidance to disable advanced video processing to reduce CPU utilization on non-GPU WorkSpaces.

For more information, refer to the following resources.
+ Microsoft Teams: [Teams for Virtualized Desktop Infrastructure](https://https://learn.microsoft.com/en-us/microsoftteams/vdi-2)
+ Zoom Meetings: [Managing the user experience for incompatible VDI plugins](https://support.zoom.us/hc/en-us/articles/4411856902285-Managing-the-user-experience-for-incompatible-VDI-plugins-)
+ Webex: [Deployment guide for Webex App for Virtual Desktop Infrastructure (VDI) - Manage and troubleshoot Webex App for VDI [Webex App]](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/wbxt/vdi/wbx-vdi-deployment-guide/manage-teams-vdi.html#id_138538)
+ Google Meet: [Using VDI](https://support.google.com/a/answer/1279090?hl=en#VDI)

#### Enable bi-directional audio and webcam redirection
<a name="enable-bi-directional-audio-webcam-redirection"></a>

Amazon WorkSpaces inherently support audio-in, audio-out, and camera redirection through video-in by default. However, if these features have been disabled for any specific reasons, you can follow the provided guidance to re-enable redirection. For more information, refer to [Enable or disable video-in redirection for DCV](https://docs.aws.amazon.com/workspaces/latest/adminguide/group_policy.html#gp_video_in_wsp) in the *Amazon WorkSpaces Administration Guide*. Users need to select the camera they want to use in session after connecting. For more information, users should refer to [Webcams and other video devices](https://docs.aws.amazon.com/workspaces/latest/userguide/peripheral_devices.html#devices-webcams) in the *Amazon WorkSpaces User Guide*.

#### Limit maximum webcam resolution
<a name="limit-maximum-webcam-resolution"></a>

For users employing Power, PowerPro, GeneralPurpose.4xlarge, or GeneralPurpose.8xlarge WorkSpaces for video conferencing, it is strongly recommended to restrict the maximum resolution of redirected webcams. In the case of PowerPro, GeneralPurpose.4xlarge, or GeneralPurpose.8xlarge, the recommended maximum resolution is 640 pixels in width by 480 pixels in height. For Power, the recommended maximum resolution is 320 pixels in width by 240 pixels in height.

Complete the following steps to configure the maximum webcam resolution.

1. Open the Windows Registry Editor.

1. Navigate to the following registry path:

   ```
   HKEY_USERS/S-1-5-18/Software/GSettings/com/nicesoftware/dcv/webcam
   ```

1. Create a string value named `max-resolution` and set it to the desired resolution in the `(X,Y)` format, where `X` represents the horizontal pixel count (width) and `Y` represents the vertical pixel count (height). For example, specify `(640,480)`) to represent a resolution that is 640 pixels in width and 480 pixel in height.

#### Enable voice-optimized audio configuration
<a name="enable-voice-optimized-audio-configuration"></a>

By default, WorkSpaces are set to deliver 7.1 high-fidelity audio from WorkSpaces to the client, ensuring superior music playback quality. However, if your primary use case involves audio or video conferencing, modifying the audio codec profile to a voice-optimized setting can conserve CPU and network resources.

Complete the following steps to set the audio profile to voice optimized.

1. Open the Windows Registry Editor.

1. Navigate to the following registry path:

   ```
   HKEY_USERS/S-1-5-18/Software/GSettings/com/nicesoftware/dcv/audio
   ```

1. Create a string value name `default-profile` and set it to `voice`.

#### Use good quality headsets for audio and video calls
<a name="use-good-quality-headsets"></a>

To enhance the audio experience and prevent echo, it's crucial to utilize high-quality headsets. Utilizing desktop speakers can lead to echo issues on the remote end of the call.

### Configure Direct RTC
<a name="configure-direct-rtc"></a>

The configuration of Direct RTC mode depends on the specific Unified Communication (UC) application and does not necessitate any changes in the WorkSpaces configuration. The following list offers a non-exhaustive compilation of optimizations for various UC applications.

![\[Diagram showing the Direct RTC configuration.\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/images/direct-rtc.png)

+ Microsoft Teams:
  + [Plan for SIP Gateway](https://learn.microsoft.com/en-us/microsoftteams/sip-gateway-plan)
  + [Audio Conferencing in Microsoft 365](https://learn.microsoft.com/en-us/microsoftteams/audio-conferencing-in-office-365)
  + [Plan your Teams voice solution](https://learn.microsoft.com/en-us/microsoftteams/cloud-voice-landing-page)
+ Zoom Meetings:
  + [Enabling or disabling toll call dial-in numbers](https://support.zoom.us/hc/en-us/articles/360060920371-Enabling-or-disabling-toll-call-dial-in-numbers)
  + [Using desk phone call control](https://support.zoom.us/hc/en-us/articles/4912628206477-Using-desk-phone-call-control)
  + [Desk phone companion mode](https://support.zoom.us/hc/en-us/articles/360049007912-Desk-phone-companion-mode)
+ Webex:
  + [Webex App \$1 Make calls with your desk phone](https://help.webex.com/en-us/article/5mgmmb/Webex-App-%7C-Make-calls-with-your-desk-phone)
  + [Webex App \$1 Supported calling options](https://help.webex.com/en-us/article/xga73p/Webex-App-%7C-Supported-calling-options)
+ BlueJeans:
  + [Dialing into a Meeting from a Desk Telephone](https://support.bluejeans.com/s/article/Dialing-into-a-meeting-from-a-Desk-Telephone)
+ Genesys:
  + [Genesys Cloud WebRTC media helper](https://help.mypurecloud.com/articles/about-webrtc-media-helper/)
+ Amazon Connect:
  + [Amazon Connect Optimization for Amazon WorkSpaces](https://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/connect-optimization.html)
+ Google Meet:
  + [Use a phone for audio in a video meeting](https://support.google.com/meet/answer/9518557?hl=en)

# Manage the running mode in WorkSpaces Personal
<a name="running-mode"></a>

The *running mode* of a WorkSpace determines its immediate availability and how you pay for it (monthly or hourly). You can choose between the following running modes when you create the WorkSpace:
+ **AlwaysOn** — Use when paying a fixed monthly fee for unlimited usage of your WorkSpaces. This mode is best for users who use their WorkSpace full time as their primary desktop.
+ **AutoStop** — Use when paying for your WorkSpaces by the hour. With this mode, your WorkSpaces stop after a specified period of disconnection, and the state of apps and data is saved.

For more information, see [WorkSpaces Pricing](https://aws.amazon.com/workspaces/pricing/).

## AutoStop WorkSpaces
<a name="autostop-workspaces"></a>

To set the automatic stop time, select the WorkSpace in the Amazon WorkSpaces console, choose **Actions**, **Modify Running Mode Properties**, and then set **AutoStop Time (hours)**. By default, **AutoStop Time (hours)** is set to 1 hour, which means that the WorkSpace stops automatically an hour after the WorkSpace is disconnected.

After a WorkSpace is disconnected and the AutoStop Time period has expired, it might take several additional minutes for the WorkSpace to automatically stop. However, billing stops as soon as the AutoStop Time period expires, and you aren't charged for that additional time.

When the WorkSpaces support hibernation, the state of the desktop is saved to the root volume of the WorkSpace. The WorkSpace resumes when a user logs in. All open documents and running programs return to their saved state with all WorkSpaces operating systems supporting hibernation.

AutoStop GPU-enabled WorkSpaces and GeneralPurpose.4xlarge or GeneralPurpose.8xlarge do not support hibernation. The state of of applications/data is not preserved. We recommend saving your work when you're done using your WorkSpaces each time to avoid data loss. 

For Bring Your Own License (BYOL) AutoStop WorkSpaces, a large number of concurrent logins could result in significantly increased time for WorkSpaces to be available. If you expect many users to log into your BYOL AutoStop WorkSpaces at the same time, please consult your account manager for advice.

**Important**  
AutoStop WorkSpaces stop automatically only if the WorkSpaces are disconnected.

A WorkSpace is disconnected only in the following circumstances:
+ If the user manually disconnects from the WorkSpace or quits the Amazon WorkSpaces client application.
+ If the client device is shut down.
+ If there's no connection between the client device and the WorkSpace for more than 20 minutes.

As a best practice, AutoStop WorkSpace users should manually disconnect from their WorkSpaces when they're done using them each day. To manually disconnect, choose **Disconnect WorkSpace** or **Quit Amazon WorkSpaces** from the **Amazon WorkSpaces** menu in the WorkSpaces client applications for Linux, macOS, or Windows. For Android or iPad, choose **Disconnect** from the sidebar menu.

**AutoStop WorkSpaces may not stop automatically in the following situations:**
+ If the client device is only locked, sleeping, or otherwise inactive (for example, the laptop lid is closed) instead of shut down, the WorkSpaces application might still be running in the background. As long as the WorkSpaces application is still running, the WorkSpace might not be disconnected, and therefore the WorkSpace might not automatically stop.
+ WorkSpaces can detect disconnection only when users are using WorkSpaces clients. If users are using third-party clients, WorkSpaces might not be able to detect disconnection, and therefore the WorkSpaces might not automatically stop and billing might not be suspended.

## Modify the running mode
<a name="modify-running-mode"></a>

You can switch between running modes at any time.

**To modify the running mode of a WorkSpace**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Select the WorkSpace to modify and choose **Actions**, **Modify running mode**.

1. Select the new running mode, **AlwaysOn** or **AutoStop**, and then choose **Save**.

**To modify the running mode of a WorkSpace using the AWS CLI**  
Use the [modify-workspace-properties](https://docs.aws.amazon.com/cli/latest/reference/workspaces/modify-workspace-properties.html) command.

## Stop and start an AutoStop WorkSpace
<a name="stop-start-workspace"></a>

When your AutoStop WorkSpaces are disconnected, they stop automatically after a specified period of disconnection, and hourly billing is suspended. To further optimize costs, you can manually suspend the hourly charges associated with AutoStop WorkSpaces. The WorkSpace stops and all apps and data are saved for the next time a user logs in to the WorkSpace.

When a user reconnects to a stopped WorkSpace, it resumes from where it left off, typically in under 90 seconds.

You can reboot (restart) AutoStop WorkSpaces that are available or in an error state.

**To stop an AutoStop WorkSpace**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Select the WorkSpace to stop and choose **Actions**, **Stop WorkSpaces**.

1. When prompted for confirmation, choose **Stop WorkSpace**.

**To start an AutoStop WorkSpace**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Select the WorkSpaces to start and choose **Actions**, **Start WorkSpaces**.

1. When prompted for confirmation, choose **Start WorkSpace**.

To remove the fixed infrastructure costs that are associated with AutoStop WorkSpaces, remove the WorkSpace from your account. For more information, see [Delete a WorkSpace in WorkSpaces Personal](delete-workspaces.md).

**To stop and start an AutoStop WorkSpace using the AWS CLI**  
Use the [stop-WorkSpaces](https://docs.aws.amazon.com/cli/latest/reference/workspaces/stop-workspaces.html) and [start-WorkSpaces](https://docs.aws.amazon.com/cli/latest/reference/workspaces/start-workspaces.html) commands.

# Manage applications in WorkSpaces Personal
<a name="manage-applications"></a>

After you launch a WorkSpace, you can see the list of all of the application bundles that are associated with your WorkSpace on the WorkSpaces console.

**To see the list of all the application bundles associated to your WorkSpace**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. From the left navigation pane, choose **WorkSpaces**.

1. Select the WorkSpace and choose **View Details**.

1. Under **Applications**, find the list of applications that are associated with this WorkSpace, along with their installation status.

**You can update the application bundles on your WorkSpace in the following ways:**
+ Install application bundles on your WorkSpace
+ Uninstall application bundles from your WorkSpace
+ Install application bundles and uninstall a different set of application bundles on your WorkSpace

**Note**  
To update application bundles, the WorkSpace must have a status of `AVAILABLE` or `STOPPED`.
Manage applications is only available for Windows WorkSpaces.
Manage applications is only available for application bundles that are subscribed through AWS.

## Supported bundles for Manage applications
<a name="w2aac11c31c25c11"></a>

Manage applications allows you install and uninstall the following applications on your WorkSpaces. For Microsoft Office 2016 bundle and Microsoft Office 2019, you can only uninstall.

**End of Support Notice**  
Microsoft Office, Visio, and Project 2021 (Standard and Professional editions) will reach end of support on **October 13, 2026**. After this date, these applications will no longer receive security updates or technical support from Microsoft.  
**Recommended action**: Migrate to the 2024 LTSC Professional/Standard versions of Office, Visio, and Project.
+ Microsoft Office LTSC Professional Plus 2024
+ Microsoft Visio LTSC Professional 2024
+ Microsoft Project Professional 2024
+ Microsoft Office LTSC Standard 2024
+ Microsoft Visio LTSC Standard 2024
+ Microsoft Project Standard 2024
+ Microsoft Office LTSC Professional Plus 2021
+ Microsoft Visio LTSC Professional 2021
+ Microsoft Project Professional 2021
+ Microsoft Office LTSC Standard 2021
+ Microsoft Visio LTSC Standard 2021
+ Microsoft Project Standard 2021
+ Microsoft Visual Studio Professional 2022
+ Microsoft Visual Studio Enterprise 2022

The following table shows the list of supported and unsupported application and operating system combinations:


|  | Microsoft Office Professional Plus 2016 (32-bit) | Microsoft Office Professional Plus 2019 (64-bit) | Microsoft LTSC Office Professional Plus / Standard 2024 (64-bit) | Microsoft Project Professional / Standard 2024 (64-bit) | Microsoft Visio Professional / Standard 2024 (64-bit) | Microsoft LTSC Office Professional Plus / Standard 2021 (64-bit) | Microsoft Project Professional / Standard 2021 (64-bit) | Microsoft LTSC Visio Professional / Standard 2021 (64-bit) | Microsoft Visual Studio Professional / Enterprise 2022 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| Windows Server 2016 | Uninstall | Not supported | Not supported | Not supported | Not supported | Not supported | Not supported | Not supported | Not supported | 
| Windows Server 2019 | Not supported | Uninstall | Not supported | Not supported | Not supported | Install/uninstall | Install/uninstall | Install/uninstall | Not supported | 
| Windows Server 2022 | Not supported | Uninstall | Install/uninstall | Install/uninstall | Install/uninstall | Install/uninstall | Install/uninstall | Install/uninstall | Install/uninstall | 
| Windows Server 2025 | Not supported | Uninstall | Install/uninstall | Install/uninstall | Install/uninstall | Not supported | Not supported | Not supported | Install/uninstall | 
| Windows 10 | Uninstall | Uninstall | Not supported | Not supported | Not supported | Install/uninstall | Install/uninstall | Install/uninstall | Install/uninstall | 
| Windows 11 | Uninstall | Uninstall | Install/uninstall | Install/uninstall | Install/uninstall | Install/uninstall | Install/uninstall | Install/uninstall | Install/uninstall | 

**Important**  
Microsoft Office/Visio/Project must follow the same editions. For example, you cannot mix Standard applications with Professional applications.
Microsoft Office/Visio/Project must follow the same versions. For example, you cannot mix 2019 applications with 2021 applications.
Microsoft Office/Visio/Project 2021 Standard/Professional are not supported for Value, Graphics, and GraphicsPro WorkSpaces bundles.
Microsoft Office/Visio/Project versions 2010 and 2013 (Standard or Professional editions) are no longer supported.
Microsoft Office/Visio/Project 2024 (Standard or Professional editions) is not supported for Value bundles.
Plus applications bundles with Office 2016 or Office 2019 will no longer be supported after October 14, 2025. We recommend migrating your WorkSpaces bundles with those Office version to use Office 2021 or Office 2024. For more information, see [Manage applications in WorkSpaces Personal](manage-applications).
Microsoft Office, Project and Visio require up to 25 GB of free space for the 2024 versions and up to 20 GB for the 2021 versions.
Value, Standard, Graphics, and GraphicsPro WorkSpaces bundles are not supported for Microsoft Visual Studio 2022 Enterprise/Professional. Performance bundles can be used for Visual Studio workloads that are less resource intensive. However, for best results, we recommended using Visual Studio with quad-core or higher bundle types. The bundle types Power, PowerPro, General Purpose.4xlarge, General Purpose.8xlarge, Graphics.g6, Graphics.g4dn, and GraphicsPro.g4dn meet this requirement. For more information, see [Visual Studio 2022 Product Family System Requirements](https://learn.microsoft.com/en-us/visualstudio/releases/2022/system-requirements).
When you uninstall **Plus applications bundle for Microsoft Office 2016** from your WorkSpaces, you will lose access to any Trend Micro solutions that were included as part of that Amazon WorkSpaces bundle. If you want to continue using Trend Micro solutions with your Amazon WorkSpaces, you can purchase them separately on the [AWS marketplace](https://aws.amazon.com/marketplace/pp/prodview-u2in6sa3igl7c). 
In order to install/uninstall Microsoft 365 apps, you need to bring in your own tools and installers, Manage application workflow cannot install/uninstall Microsoft 365 apps.
You can create a custom image of WorkSpaces with applications installed/uninstalled through Manage applications.
For opt-in Regions, such as Africa (Cape Town), WorkSpaces internet connection must be enabled at the directory level.

## Update application bundles on a WorkSpace
<a name="w2aac11c31c25c13"></a>

1. 

   Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Select the WorkSpace and choose **Actions**, **Manage applications**.

1. Under **Current applications** you will see a list of application bundles that are already installed on this WorkSpace and under **Choose applications** you have a list of application bundles that are available to install on this WorkSpace.

1. To install application bundles on this WorkSpace:

   1. Select an application bundle that you want to install on this WorkSpace, and choose **Associate**.

   1. Repeat the previous step to install other application bundles.

   1. While the application bundles are installing, you will see them under **Current applications** with the `Pending install deployment` status.

1. To uninstall application bundles from this WorkSpace:

   1. Under **Choose applications**, select an application bundle that you want to uninstall and choose **Disassociate**.

   1. Repeat the previous step to uninstall other application bundles.

   1. While the application bundles are uninstalling, you will see them under **Current applications** with the `Pending uninstall deployment` status.

1. To revert the bundles installation or installation state, do one of the following.
   + If you want to revert the bundles from the `Pending uninstall deployment` state, select the application you want to revert, then choose **Associate**.
   + If you want to revert the bundles from the `Pending install deployment` state, select the application you want to revert, then choose **Disassociate**.

1. After the application bundles you chose to install or uninstall are in pending states, choose **Deploy applications**.
**Important**  
After you select **Deploy applications**, the end user session will terminate and WorkSpaces will not be accessible while the applications are being installed or uninstalled.

1. To confirm your actions, type **confirm**. Choose **force** to install or uninstall applications bundles that are in an **Error** state.

1. To monitor the progress of your application bundles:

   1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

   1. In the navigation pane, choose **WorkSpaces**. You can see the status under **Status** including the following.
      + **UPDATING** - The application bundle update is still ongoing.
      + **AVAILABLE / STOPPED** - The application bundle update is complete and the WorkSpace is back to its original state.

   1. To monitor the installation or uninstallation status of your application bundles, select the WorkSpace and choose **View Details**. Under **Applications**, you can see the status under **Status**, including `Pending install`, `Pending uninstall`, and `Installed`.
**Note**  
If your users observe that their newly installed application bundles through Managed Applications are not license activated, you can perform a manual WorkSpace reboot. Your users can begin using those applications following a reboot. For additional support, contact [AWS Support](https://console.aws.amazon.com/support/home#/).

## Update Microsoft Visual Studio 2022 workloads on a WorkSpace
<a name="w2aac11c31c25c15"></a>

By default Microsoft Visual Studio 2022 is installed with the following workloads and requires 18 GB of hard disk space:
+ Visual Studio core editor
+ Azure development
+ Data storage and processing
+ .NET desktop development
+ NET Multi-platform App UI development
+ ASP.NET and web development
+ Node.js development

Users have the flexibility to add or remove workloads and individual components, allowing them to tailor the application to their specific requirements. It's important to note that installing additional workloads requires more disk space. To learn more about workload configurations, see [Modify Visual Studio workloads, components, and language packs](https://learn.microsoft.com/en-us/visualstudio/install/modify-visual-studio?view=vs-2022).

## Managing WorkSpaces modified using Manage applications
<a name="w2aac11c31c25c17"></a>

After installing or uninstalling application bundles on your WorkSpaces, the following actions can impact existing configurations.
+ **Restore a WorkSpace** - Restoring a WorkSpace recreates both the root volume and user volume, based on the most recent snapshots of these volumes that were created when the WorkSpace was healthy. Full WorkSpace snapshots are taken every 12 hours. For more information, see [ Restore a WorkSpace](https://docs.aws.amazon.com/workspaces/latest/adminguide/restore-workspace.html). Ensure you wait for at least 12 hours before restoring your WorkSpaces that were modified using Manage applications. Restoring your WorkSpaces before the next full snapshot, which were modified using Manage applications, will result in the following:
  +  The application bundles that were installed on your WorkSpaces using the Manage applications workflow will be removed from your WorkSpaces but the license will still be activated and your WorkSpaces will be billed for those applications. To get those application bundles back on your WorkSpaces you need to run the Manage application workflow again, uninstall the application to start fresh, and then install again. 
  +  The application bundles that were removed from your WorkSpaces using the Manage applications workflow will be back on your WorkSpaces. However, those application bundles won’t work properly because the license activation will be missing. In order to get rid of those application bundles, run a manual uninstall of those application bundles from your WorkSpaces. 
+ **Rebuild a WorkSpace** - Rebuilding a WorkSpace recreates the root volume. For more information, see [Rebuild a WorkSpace](https://docs.aws.amazon.com/workspaces/latest/adminguide/rebuild-workspace.html). Rebuilding your WorkSpaces that were modified using Manage applications will result in the following:
  +  The application bundles that were installed on your WorkSpaces using the Manage applications workflow will be removed and deactivated from your WorkSpaces. In order to get those applications back on your WorkSpaces you need to run the Manage applications workflow again. 
  +  The application bundles that were removed from your WorkSpaces via Manage applications workflow will be installed and activated on your WorkSpaces. In order to remove those application bundles from your WorkSpaces, you need to run the Manage applications workflow again. 
+ **Migrate a WorkSpace** - The migration process recreates the WorkSpace by using a new root volume from the target bundle image and the user volume from the last available snapshot of the original WorkSpace. A new WorkSpace with a new WorkSpace ID is created. For more information, see [Migrate a WorkSpace](https://docs.aws.amazon.com/workspaces/latest/adminguide/migrate-workspaces.html) Migrating your WorkSpaces that were modified using Manage applications will result in the following:
  +  All the application bundle from the source WorkSpaces will be removed and deactivated. The new destination WorkSpaces will inherit applications from the destination WorkSpaces bundle. Source WorkSpaces application bundles will be billed for the full month but application bundles on destination bundle will have a pro-rated bill. 

# Modify a WorkSpace in WorkSpaces Personal
<a name="modify-workspaces"></a>

After you launch a WorkSpace, you can modify its configuration in three ways: 
+ You can change the size of its root volume (for Windows, drive C; for Linux, /) and its user volume (for Windows, drive D; for Linux /home).
+ You can change its compute type to select a new bundle.
+ You can modify the streaming protocol using the AWS CLI or Amazon WorkSpaces API if your WorkSpace was created with PCoIP bundles.

To see the current modification state of a WorkSpace, select the arrow to show more details about that WorkSpace. The possible values for **State** are **Modifying Compute**, **Modifying Storage,** and **None**.

If you want to modify a WorkSpace, it must have a status of `AVAILABLE` or `STOPPED`. You can't change the volume size and the compute type at the same time.

Changing the volume size or compute type of a WorkSpace will change the billing rate for the WorkSpace.

To allow your users to modify their volumes and compute types themselves, see [Enable self-service WorkSpaces management capabilities for your users in WorkSpaces Personal](enable-user-self-service-workspace-management.md).

## Modify volume sizes
<a name="modify_volume_sizes"></a>

You can increase the size of the root and user volumes for a WorkSpace, up to 2000 GB each. WorkSpace root and user volumes come in set groups that can't be changed. The available groups are:


| [Root (GB), User (GB)] | 
| --- | 
| [80, 10] | 
| [80, 50] | 
| [80, 100] | 
| [175 to 2000, 100 to 2000] | 

You can expand the root and user volumes whether they are encrypted or unencrypted, and you can expand both volumes once in a 6-hour period. However, you can't increase the size of the root and user volumes at the same time. For more information, see [Limitations for Increasing Volumes](#limitations_increasing_volumes).

**Note**  
When you expand a volume for a WorkSpace, WorkSpaces automatically extends the volume's partition within Windows or Linux. When the process is finished, you must reboot the WorkSpace for the changes to take effect. 

To ensure that your data is preserved, you cannot decrease the size of the root or user volumes after you launch a WorkSpace. Instead, make sure that you specify the minimum sizes for these volumes when launching a WorkSpace.
+ You can launch a Value, Standard, Performance, Power, or PowerPro WorkSpace with a minimum of 80 GB for the root volume and 10 GB for the user volume.
+ You can launch a GeneralPurpose.4xlarge or GeneralPurpose.8xlarge WorkSpace with a minimum of 175GB for the root volume and 100 GB for the user volume.
+ You can launch a Graphics.g6, Graphics.g4dn, GraphicsPro.g4dn, or GraphicsPro WorkSpace with a minimum of 100 GB for the root volume and 100 GB for the user volume. Volume sizing requirements vary based on larger graphics instance types.

While a WorkSpace disk size increase is in progress, users can perform most tasks on their WorkSpace. However, they can't change their WorkSpace compute type, switch the WorkSpace running mode, rebuild their WorkSpace, or reboot (restart) their WorkSpace.

**Note**  
If you want your users to be able to use their WorkSpaces while the disk size increase is in progress, make sure the WorkSpaces have a status of `AVAILABLE` instead of `STOPPED` before you resize the volumes of the WorkSpaces. If the WorkSpaces are `STOPPED`, they can't be started while the disk size increase is in progress.

In most cases, the disk size increase process might take up to two hours. However, if you're modifying the volume sizes for a large number of WorkSpaces, the process can take significantly longer. If you have a large number of WorkSpaces to modify, we recommend contacting AWS Support for assistance.

**Limitations for increasing volumes**
+ You can resize only SSD volumes.
+ When you launch a WorkSpace, you must wait 6 hours before you can modify the sizes of its volumes.
+ You cannot increase the size of the root and user volumes at the same time. To increase the root volume, you must first change the user volume to 100 GB. After that change is made, you can then update the root volume to any value between 175 and 2000 GB. After the root volume has been changed to any value between 175 and 2000 GB, you can then update the user volume further, to any value between 100 and 2000 GB.
**Note**  
If you want to increase both volumes, you must wait 20-30 minutes for the first operation to finish before you can start the second operation.
+ Non-GPU-enabled WorkSpaces’ root volume cannot be less than 175 GB when the user volume is 100 GB. Storage requirements for GPU-enabled WorkSpaces scale proportionally with instance sizing. As you select larger GPU-enabled WorkSpaces configurations, you must allocate correspondingly larger storage volumes to maintain optimal performance and accommodate increased workload demands. For the smallest instance size, begin with the following storage allocation: Root: 100 GB, User: 100 GB. GPU-enabled WorkSpaces support a minimum of 100 GB for the root volume and 100 GB for the user volume.
+ If the user volume is 50 GB, you cannot update the root volume to anything other than 80 GB. If the root volume is 80 GB, the user volume can only be 10, 50, or 100 GB.

**To modify the root volume of a WorkSpace**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Select the WorkSpace and choose **Actions**, **Modify root volume.**.

1. Under **Root volume sizes**, choose a volume size or choose **Custom** to enter a custom volume size.

1. Choose **Save changes**.

1. When the disk size increase is finished, you must [ reboot the WorkSpace](reboot-workspaces.md) for the changes to take effect. To avoid data loss, make sure the user saves any open files before you reboot the WorkSpace.

**To modify the user volume of a WorkSpace**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Select the WorkSpace and choose **Actions**, **Modify user volume.**.

1. Under **User volume sizes**, choose a volume size or choose **Custom** to enter a custom volume size.

1. Choose **Save changes**.

1. When the disk size increase is finished, you must [ reboot the WorkSpace](reboot-workspaces.md) for the changes to take effect. To avoid data loss, make sure the user saves any open files before you reboot the WorkSpace.

**To change the volume sizes of a WorkSpace**  
Use the [modify-workspace-properties](https://docs.aws.amazon.com/cli/latest/reference/workspaces/modify-workspace-properties.html) command with the `RootVolumeSizeGib` or `UserVolumeSizeGib` property.

## Modify compute type
<a name="modify_compute"></a>

You can switch a WorkSpace between the Standard, Power, Performance, PowerPro GeneralPurpose.4xlarge, and GeneralPurpose.8xlarge compute types. For more information about these compute types, see [Amazon WorkSpaces Bundles](https://aws.amazon.com/workspaces/features/#Amazon_WorkSpaces_Bundles).

**Note**  
If your source operating system is anything other than Windows Server 2022 or Windows 11, you cannot change your compute type from PowerPro to GeneralPurpose.
If you are modifying the compute type from a non-GPU-enabled bundles to GeneralPurpose.4xlarge or GeneralPurpose.8xlarge, your WorkSpaces must meet the minimum root volume size of 175 GB and user volume size of 100 GB. To increase the volume size of your WorkSpaces, see [Modify volume sizes](#modify_volume_sizes).
GPU-enabled WorkSpaces support compute type modifications within the same instance family but do not support cross-family modifications. For example, you can modify the compute type between G4dn instances or between G6 instances, but you cannot change from a G4dn instance to a G6 instance family. To move between GPU-enabled WorkSpace bundles powered by different instance families, use Migrate a WorkSpace feature. For more information, see [Migrate a WorkSpace in WorkSpaces Personal](migrate-workspaces.md)
GraphicsPro bundle reaches end-of-life on October 31, 2025. We recommend migrating your GraphicsPro WorkSpaces to supported bundles before October 31, 2025. For more information, see [Migrate a WorkSpace in WorkSpaces Personal](migrate-workspaces.md).
You cannot change the compute type of Graphics and GraphicsPro to any other value.

When you request a compute change, WorkSpaces reboots the WorkSpace using the new compute type. WorkSpaces preserves the operating system, applications, data, and storage settings for the WorkSpace.

You can request a larger compute type once in a 6-hour period or a smaller compute type once every 30 days. For a newly launched WorkSpace, you must wait 6 hours before requesting a larger compute type.

When a WorkSpace compute type change is in progress, users are disconnected from their WorkSpace, and they can't use or change the WorkSpace. The WorkSpace is automatically rebooted during the compute type change process.

**Important**  
To avoid data loss, make sure users save any open documents and other application files before you change the WorkSpace compute type.

The compute type change process might take up to an hour.

**To change the compute type of a WorkSpace**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Select the WorkSpace and choose **Actions**, **Modify compute type**.

1. Under **Compute type**, choose a compute type.

1. Choose **Save changes**.

**To change the compute type of a WorkSpace**  
Use the [modify-workspace-properties](https://docs.aws.amazon.com/cli/latest/reference/workspaces/modify-workspace-properties.html) command with the `ComputeTypeName` property.

## Modify protocols
<a name="modify_protocols"></a>

 If your WorkSpace is created with PCoIP bundles, you can modify their streaming protocol using the AWS CLI or the Amazon WorkSpaces API. This allows you to migrate the protocol using your existing WorkSpace without using the WorkSpace migration feature. This also allows you to use DCV and maintain your root volume without re-creating existing PCoIP WorkSpaces during the migration process. 
+ You can only modify your protocol if your WorkSpace was created with PCoIP bundles and is not a GPU-enabled WorkSpace.
+ Before you modify the protocol to DCV, ensure that your WorkSpace meets the following requirements for a DCV WorkSpace.
  + Your WorkSpaces client supports DCV
  + The region where your WorkSpace is deployed supports DCV
  + The IP address and port requirements for DCV are open. For more information, see [IP address and port requirements for WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html).
  + Ensure your current bundle is available with DCV.
  + For the best experience with video conferencing we recommend using Power, PowerPro, GeneralPurpose.4xlarge, or GeneralPurpose.8xlarge only.

**Note**  
We highly recommend testing with your non-production WorkSpaces before you start changing the protocol.
If you modify the protocol from PCoIP to DCV, and then modify the protocol back to PCoIP, you won't be able to connect to WorkSpaces through Web Access.

**To change the protocol of a WorkSpace**

1. [Optional] Reboot your WorkSpace and wait until it’s in the `AVAILABLE` state before modifying the protocol.

1. [Optional] Use the `describe-workspaces` command to list the WorkSpace properties. Ensure that it’s in the `AVAILABLE` state and its current `Protocol` is accurate. 

1. Use the `modify-workspace-properties` command and modify the `Protocols` property from `PCOIP` to `DCV`, or the other way around.

   ```
   aws workspaces modify-workspace-properties
   --workspace-id <value>
   --workspace-properties "Protocols=[WSP]"
   ```
**Important**  
The `Protocols` property is case-sensitive. Ensure that you use `PCOIP` or `DCV`.

1. After you run the command, it can take up to 20 minutes for the WorkSpace to reboot and complete the necessary configurations.

1. Use the `describe-workspaces` command again to list the WorkSpace properties and verify that it’s in an `AVAILABLE` state and the current `Protocols` property has been changed to the correct protocol.
**Note**  
Modifying the WorkSpace's protocol will not update the bundle description in the console. The **Launch Bundle** description will not change.
If the WorkSpace remains in an `UNHEALTHY` state after 20 min, reboot the WorkSpace in the console.

1. You can now connect to your WorkSpace.

# Customize branding in WorkSpaces Personal
<a name="customize-branding"></a>

Amazon WorkSpaces allows you to create a familiar WorkSpaces experience for your users by using APIs to customize the appearance of your WorkSpace's login page with your own branding logo, IT support information, forgot password link, and login message. Your branding will be displayed to your users in their WorkSpace login page rather than the default WorkSpaces branding. 

The following clients are supported:
+ Windows
+ Linux
+ Android
+ MacOS
+ iOS
+ Web Access

## Import custom branding
<a name="import-custom-branding"></a>

To import your client branding customization, use the action `ImportClientBranding`, which includes the following elements. See [ ImportClientBranding API reference](https://docs.aws.amazon.com/workspaces/latest/api/API_ImportClientBranding.html) for more information.

**Important**  
Client branding attributes are public facing. Ensure that you don't include sensitive information.

Depending on whether your directories are using the legacy or new user login flow, your users will see your custom client branding attributes as shown in the below screenshots.


|  |  | 
| --- |--- |
|  ![\[WorkSpaces client sign in screen - Legacy login flow\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/images/client-cobranding-legacy.png)  |  ![\[WorkSpaces client sign in screen - New login flow\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/images/client-cobranding-new.png)  | 

1. Support link

1. Logo

1. Forgot password link

1. Login message


**Custom branding elements**  

| Branding element | Description | Requirements and recommendations | 
| --- | --- | --- | 
| Support link | Allows you to specify a support email link for users to contact for help with their WorkSpaces. You can use the SupportEmail attribute or provide a link to your support page using the SupportLink attribute. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/customize-branding.html) | 
| Logo | Allows you to customize your organization's logo using the Logo attribute. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/customize-branding.html) | 
| Forgot password link | Allows you to add a web address using the ForgotPasswordLink attribute that users can go to if they forget their password to their WorkSpace. | Length Constraints: Minimum length of 1. Maximum length of 200. | 
| Login message | Allows you to customize a message using the LoginMessage attribute on the sign in screen. |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/customize-branding.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/customize-branding.html)  | 

The following are sample code snippets for using ImportClientBranding.

### AWS CLI Version 2
<a name="import-client-branding-cli"></a>

**Warning**  
Importing custom branding overwrites the attributes, within that platform, that you specify with your custom data. It also overwrites the attributes that you don't specify with default custom branding attribute values. You must include the data for any attribute that you don't want to overwrite.

```
aws workspaces import-client-branding \
--cli-input-json file://~/Downloads/import-input.json \
--region us-west-2
```

The import JSON file should look like the following sample code:

```
{
    "ResourceId": "<directory-id>",
    "DeviceTypeOsx": {
        "Logo": "iVBORw0KGgoAAAANSUhEUgAAAAIAAAACCAYAAABytg0kAAAAC0lEQVR42mNgQAcAABIAAeRVjecAAAAASUVORK5CYII=",
        "ForgotPasswordLink": "https://amazon.com/",
        "SupportLink": "https://amazon.com/",
        "LoginMessage": {
            "en_US": "Hello!!"
        }
    }
}
```

The following sample Java code snippet converts the logo image into a base64-encoded string:

```
// Read image as BufferImage
BufferedImage bi = ImageIO.read(new File("~/Downloads/logo.png"));
   
// convert BufferedImage to byte[]
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ImageIO.write(bi, "png", baos);
byte[] bytes = baos.toByteArray();
       
//convert byte[] to base64 format and print it
String bytesBase64 = Base64.encodeBase64String(bytes);
System.out.println(bytesBase64);
```

The following sample Python code snippet converts the logo image into a base64-encoded string:

```
# Read logo into base64-encoded string
with open("~/Downloads/logo.png", "rb") as image_file:
    f = image_file.read()
    base64_string = base64.b64encode(f)
    print(base64_string)
```

### Java
<a name="import-client-branding-java"></a>

**Warning**  
Importing custom branding overwrites the attributes, within that platform, that you specify with your custom data. It also overwrites the attributes that you don't specify with default custom branding attribute values. You must include the data for any attribute that you don't want to overwrite.

```
// Create WS Client
WorkSpacesClient client = WorkSpacesClient.builder().build();

// Read image as BufferImage
BufferedImage bi = ImageIO.read(new File("~/Downloads/logo.png"));

// convert BufferedImage to byte[]
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ImageIO.write(bi, "png", baos);
byte[] bytes = baos.toByteArray();
    
// Create import attributes for the plateform 
DefaultImportClientBrandingAttributes attributes =
        DefaultImportClientBrandingAttributes.builder()
                .logo(SdkBytes.fromByteArray(bytes))
                .forgotPasswordLink("https://aws.amazon.com/")
                .supportLink("https://aws.amazon.com/")
                .build();
                    
// Create import request
ImportClientBrandingRequest request = 
        ImportClientBrandingRequest.builder()
                .resourceId("<directory-id>")
                .deviceTypeOsx(attributes)
                .build();
                    
// Call ImportClientBranding API
ImportClientBrandingResponse response = client.importClientBranding(request);
```

### Python
<a name="import-client-branding-python"></a>

**Warning**  
Importing custom branding overwrites the attributes, within that platform, that you specify with your custom data. It also overwrites the attributes that you don't specify with default custom branding attribute values. You must include the data for any attribute that you don't want to overwrite.

```
import boto3

# Read logo into bytearray
with open("~/Downloads/logo.png", "rb") as image_file:
    f = image_file.read()
    bytes = bytearray(f)

# Create WorkSpaces client
client = boto3.client('workspaces')

# Call import API
response = client.import_client_branding(
    ResourceId='<directory-id>',
    DeviceTypeOsx={
        'Logo': bytes,
        'SupportLink': 'https://aws.amazon.com/',
        'ForgotPasswordLink': 'https://aws.amazon.com/',
        'LoginMessage': {
            'en_US': 'Hello!!'
        }
    }
)
```

### PowerShell
<a name="import-client-branding-powershell"></a>

```
#Requires -Modules @{ ModuleName="AWS.Tools.WorkSpaces"; ModuleVersion="4.1.56"}

# Specify Image Path
$imagePath = "~/Downloads/logo.png"

# Create Byte Array from image file
$imageByte = ([System.IO.File]::ReadAllBytes($imagePath))

# Call import API
Import-WKSClientBranding -ResourceId <directory-id> `
    -DeviceTypeLinux_LoginMessage @{en_US="Hello!!"} `
    -DeviceTypeLinux_Logo $imageByte `
    -DeviceTypeLinux_ForgotPasswordLink "https://aws.amazon.com/" `
    -DeviceTypeLinux_SupportLink "https://aws.amazon.com/"
```

To preview the login page, launch the WorkSpaces application or web login page.

**Note**  
Changes may take up to 1 minute to appear.

## Describe custom branding
<a name="describe-custom-branding"></a>

To see the details of the client branding customization you currently have, use the action `DescribeCustomBranding`. The following is the sample script for using DescribeClientBranding. See [ DescribeClientBranding API reference](https://docs.aws.amazon.com/workspaces/latest/api/API_DescribeClientBranding.html) for more information.

```
aws workspaces describe-client-branding \
--resource-id <directory-id> \
--region us-west-2
```

## Delete custom branding
<a name="delete-custom-branding"></a>

To delete your client branding customization, use the action `DeleteCustomBranding`. The following is the sample script for using DeleteClientBranding. See [ DeleteClientBranding API reference](https://docs.aws.amazon.com/workspaces/latest/api/API_DeleteClientBranding.html) for more information.

```
aws workspaces delete-client-branding \ 
--resource-id <directory-id> \
--platforms DeviceTypeAndroid DeviceTypeIos \  
--region us-west-2
```

**Note**  
Changes may take up to 1 minute to appear.

# Tag resources in WorkSpaces Personal
<a name="tag-workspaces-resources"></a>

You can organize and manage the resources for your WorkSpaces by assigning your own metadata to each resource in the form of *tags*. You specify a *key* and a *value* for each tag. A key can be a general category, such as "project," "owner," or "environment," with specific associated values. Using tags is a simple yet powerful way to manage AWS resources and to organize data, including billing data.

When you add tags to an existing resource, those tags don't appear in your cost allocation report until the first day of the following month. For example, if you add tags to an existing WorkSpace on July 15, the tags won't appear in your cost allocation report until August 1. For more information, see [Using Cost Allocation Tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) in the *AWS Billing User Guide*.

**Note**  
To view your WorkSpaces resource tags in the Cost Explorer, you must activate the tags that you have applied to your WorkSpaces resources by following the instructions in [Activating User-Defined Cost Allocation Tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) in the *AWS Billing User Guide*.  
Although tags appear 24 hours after activation, it can take 4 to 5 days for values associated with those tags to appear in the Cost Explorer. Additionally, to appear and provide cost data in Cost Explorer, WorkSpaces resources that have been tagged must incur charges during that time. Cost Explorer only shows cost data from the time when the tags were activated and onward. No historical data is available at this time.

**Resources that you can tag**
+ You can add tags to the following resources when you create them—WorkSpaces, imported images, and IP access control groups.
+ You can add tags to existing resources of the following types—WorkSpaces, registered directories, custom bundles, images, and IP access control groups.

**Tag restrictions**
+ Maximum number of tags per resource—50
+ Maximum key length—127 Unicode characters
+ Maximum value length—255 Unicode characters
+ Tag keys and values are case-sensitive. Allowed characters are letters, spaces, and numbers representable in UTF-8, plus the following special characters: \$1 - = . \$1 : / @. Do not use leading or trailing spaces.
+ Do not use the `aws:` or `aws:workspaces:` prefixes in your tag names or values because they are reserved for AWS use. You can't edit or delete tag names or values with these prefixes.

**To update the tags for an existing resource using the console (directories, WorkSpaces, or IP access control groups)**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose one of the following resource types: **Directories**, **WorkSpaces**, or **IP Access Controls**.

1. Select the resource to open its details page.

1. Do one or more of the following:
   + To update a tag, edit the values of **Key** and **Value**.
   + To add a tag, choose **Add Tag** and then edit the values of **Key** and **Value**.
   + To delete a tag, choose the delete icon (X) next to the tag.

1. When you are finished updating tags, choose **Save**.

**To update the tags for an existing resource using the console (images or bundles)**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose one of the following resource types: **Bundles** or **Images**.

1. Choose the resource to open its details page.

1. Under **Tags**, choose **Manage tags**.

1. Do one or more of the following:
   + To update a tag, edit the values of **Key** and **Value**.
   + To add a tag, choose **Add new tag** and then edit the values of **Key** and **Value**.
   + To delete a tag, choose **Remove** next to the tag.

1. When you are finished updating tags, choose **Save changes**.

**To update the tags for an existing resource using the AWS CLI**  
Use the [create-tags](https://docs.aws.amazon.com/cli/latest/reference/workspaces/create-tags.html) and [delete-tags](https://docs.aws.amazon.com/cli/latest/reference/workspaces/delete-tags.html) commands.

# Maintenance in WorkSpaces Personal
<a name="workspace-maintenance"></a>

We recommend that you maintain your WorkSpaces on a regular basis. WorkSpaces schedules default maintenance windows for your WorkSpaces. During the maintenance window, the WorkSpace installs important updates from Amazon WorkSpaces and reboots as necessary. If available, operating system updates are also installed from the OS update server that the WorkSpace is configured to use. During maintenance, your WorkSpaces might be unavailable.

By default, your Windows WorkSpaces are configured to receive updates from Windows Update. To configure your own automatic update mechanisms for Windows, see the documentation for [ Windows Server Update Services (WSUS)](https://docs.microsoft.com/windows-server/administration/windows-server-update-services/deploy/deploy-windows-server-update-services) and [Configuration Manager](https://docs.microsoft.com/configmgr/sum/deploy-use/deploy-software-updates).

**Requirement**  
Your WorkSpaces must have access to the internet so that you can install updates to the operating system and deploy applications. For more information, see [Provide internet access for WorkSpaces Personal](amazon-workspaces-internet-access.md).

## Maintenance windows for AlwaysOn WorkSpaces
<a name="alwayson-maintenance"></a>

For AlwaysOn WorkSpaces, the maintenance window is determined by operating system settings. The default is a four-hour period from 00h00 to 04h00, in the time zone of the WorkSpace, each Sunday morning. By default, the time zone of an AlwaysOn WorkSpace is the time zone of the AWS Region for the WorkSpace. However, if you connect from another Region and time zone redirection is enabled, and then you disconnect, the time zone of the WorkSpace is updated to the time zone of the Region that you connected from.

You can [disable time zone redirection for Windows WorkSpaces](group_policy.md#gp_time_zone) using Group Policy. You can [disable time zone redirection for Linux WorkSpaces](manage_linux_workspace.md#linux_time_zone) by using the PCoIP Agent conf.

For Windows WorkSpaces, you can configure the maintenance window using Group Policy; see [Configure Group Policy Settings for Automatic Updates](https://docs.microsoft.com/windows-server/administration/windows-server-update-services/deploy/4-configure-group-policy-settings-for-automatic-updates). You cannot configure the maintenance window for Linux WorkSpaces.

## Maintenance windows for AutoStop WorkSpaces
<a name="autostop-maintenance"></a>

AutoStop WorkSpaces are started automatically once a month in order to install important updates. Beginning on the third Monday of the month, and for up to two weeks, the maintenance window is open each day from about 00h00 to 05h00, in the time zone of the AWS Region for the WorkSpace. The WorkSpace can be maintained on any one day in the maintenance window. During this window, only WorkSpaces older than 7 days are maintained.

During the time period when the WorkSpace is undergoing maintenance, the state of the WorkSpace is set to `MAINTENANCE`.

Although you cannot modify the time zone that is used for maintaining AutoStop WorkSpaces, you can disable the maintenance window for your AutoStop WorkSpaces as follows. If you disable maintenance mode, your WorkSpaces are not rebooted and do not enter the `MAINTENANCE` state.

**To disable maintenance mode**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **Directories**.

1. Select your directory, and choose **Actions**, **Update Details**.

1. Expand **Maintenance Mode**.

1. To enable automatic updates, choose **Enabled**. If you prefer to manage updates manually, choose **Disabled**.

1. Choose **Update and Exit**.

## Manual maintenance
<a name="admin-maintenance"></a>

If you prefer, you can maintain your WorkSpaces on your own schedule. When you perform maintenance tasks, we recommend that you change the state of the WorkSpace to **Maintenance**. When you are finished, change the state of the WorkSpace to **Available**.

When a WorkSpace is in **Maintenance** state, the following behaviors occur:
+ The WorkSpace does not respond to requests to reboot, stop, start, or rebuild.
+ Users cannot log in to the WorkSpace.
+ An AutoStop WorkSpace is not hibernated.

**To change the state of the WorkSpace using the console**
**Note**  
To change the state of a WorkSpace, the WorkSpace must be in the **Available** state. The **Modify state** setting is not available when a WorkSpace is not in the **Available** state.

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Select your WorkSpace, and choose **Actions**, **Modify state**.

1. Under **Modify state**, choose **Available** or **Maintenance**.

1. Choose **Save**.

**To change the state of the WorkSpace using the AWS CLI**  
Use the [modify-workspace-state](https://docs.aws.amazon.com/cli/latest/reference/workspaces/modify-workspace-state.html) command.

# Encrypted WorkSpaces in WorkSpaces Personal
<a name="encrypt-workspaces"></a>

WorkSpaces is integrated with the AWS Key Management Service (AWS KMS). This enables you to encrypt storage volumes of WorkSpaces using AWS KMS Key. When you launch a WorkSpace, you can encrypt the root volume (for Microsoft Windows, the C drive; for Linux, /) and the user volume (for Windows, the D drive; for Linux, /home). Doing so ensures that the data stored at rest, disk I/O to the volume, and snapshots created from the volumes are all encrypted.

**Note**  
In addition to encrypting your WorkSpaces, you can also use FIPS endpoint encryption in certain AWS US Regions. For more information, see [Configure FedRAMP authorization or DoD SRG compliance for WorkSpaces Personal](fips-encryption.md).
Windows BitLocker encryption is not supported for Amazon WorkSpaces.  Amazon WorkSpaces will attempt to decrypt any volumes detected during boot on all Windows Operating Systems where applicable.  Volumes can become unresponsive during boot process if any combination of passwords, pins, or startup keys are enabled for any volumes on the WorkSpace it can become unhealthy and unable to boot properly.

**Topics**
+ [

## Prerequisites
](#encryption_prerequisites)
+ [

## Limits
](#encryption_limits)
+ [

## Overview of WorkSpaces encryption using AWS KMS
](#kms-workspaces-overview)
+ [

## WorkSpaces encryption context
](#kms-workspaces-encryption-context)
+ [

## Grant WorkSpaces permission to use a KMS Key on your behalf
](#kms-workspaces-permissions)
+ [

## Encrypt a WorkSpace
](#encrypt_workspace)
+ [

## View encrypted WorkSpaces
](#maintain_encryption)

## Prerequisites
<a name="encryption_prerequisites"></a>

You need an AWS KMS Key before you can begin the encryption process. This KMS Key can be either the [AWS managed KMS Key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) for Amazon WorkSpaces (**aws/workspaces**) or a symmetric [ customer managed KMS Key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk).
+ **AWS managed KMS Keys** – The first time that you launch an unencrypted WorkSpace from the WorkSpaces console in a Region, Amazon WorkSpaces automatically creates an AWS managed KMS Key (**aws/workspaces**) in your account. You can select this AWS managed KMS Key to encrypt the user and root volumes of your WorkSpace. For details, see [Overview of WorkSpaces encryption using AWS KMS](#kms-workspaces-overview).

  You can view this AWS managed KMS Key, including its policies and grants, and can track its use in AWS CloudTrail logs, but you cannot use or manage this KMS Key. Amazon WorkSpaces creates and manages this KMS Key. Only Amazon WorkSpaces can use this KMS Key, and WorkSpaces can use it only to encrypt WorkSpaces resources in your account. 

  AWS managed KMS Key, including the one that Amazon WorkSpaces supports, are rotated every year. For details, see [Rotating AWS KMS Key](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) in the *AWS Key Management Service Developer Guide*.
+ **Customer managed KMS Key** – Alternatively, you can select a symmetric customer managed KMS Key that you created using AWS KMS. You can view, use, and manage this KMS Key, including setting its policies. For more information about creating KMS Keys, see [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the *AWS Key Management Service Developer Guide*. For more information about creating KMS Keys using the AWS KMS API, see [Working with Keys](https://docs.aws.amazon.com/kms/latest/developerguide/programming-keys.html) in the *AWS Key Management Service Developer Guide*.

  Customer managed KMS Keys are not automatically rotated unless you decide to enable automatic key rotation. For details, see [Rotating AWS KMS Keys](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) in the *AWS Key Management Service Developer Guide*.

**Important**  
When you manually rotate KMS Keys, you must keep both the original KMS Key and the new KMS Key enabled so that AWS KMS can decrypt the WorkSpaces that the original KMS Key encrypted. If you don't want to keep the original KMS Key enabled, you must recreate your WorkSpaces and encrypt them using the new KMS Key.

You must meet the following requirements to use an AWS KMS Key to encrypt your WorkSpaces:
+ **The KMS Key must be symmetric.** Amazon WorkSpaces does not support asymmetric KMS Keys. For information about distinguishing between symmetric and asymmetric KMS Keys, see [ Identifying Symmetric and Asymmetric KMS Keys](https://docs.aws.amazon.com/kms/latest/developerguide/find-symm-asymm.html) in the *AWS Key Management Service Developer Guide*.
+ **The KMS Key must be enabled.** To determine whether a KMS Key is enabled, see [ Displaying KMS Key Details](https://docs.aws.amazon.com/kms/latest/developerguide/viewing-keys-console.html#viewing-console-details) in the *AWS Key Management Service Developer Guide*.
+ **You must have the correct permissions and policies associated with the KMS Key.** For more information, see [Part 2: Grant WorkSpaces administrators additional permissions using an IAM policy](#kms-permissions-iam-policy).

## Limits
<a name="encryption_limits"></a>
+ You can't encrypt an existing WorkSpace. You must encrypt a WorkSpace when you launch it.
+ Creating a custom image from an encrypted WorkSpace is not supported.
+ Disabling encryption for an encrypted WorkSpace is not currently supported.
+ WorkSpaces launched with root volume encryption enabled might take up to an hour to provision.
+ To reboot or rebuild an encrypted WorkSpace, first make sure that the AWS KMS Key is enabled; otherwise, the WorkSpace becomes unusable. To determine whether a KMS Key is enabled, see [ Displaying KMS Key Details](https://docs.aws.amazon.com/kms/latest/developerguide/viewing-keys-console.html#viewing-console-details) in the *AWS Key Management Service Developer Guide*.

## Overview of WorkSpaces encryption using AWS KMS
<a name="kms-workspaces-overview"></a>

When you create WorkSpaces with encrypted volumes, WorkSpaces uses Amazon Elastic Block Store (Amazon EBS) to create and manage those volumes. Amazon EBS encrypts your volumes with a data key using the industry-standard AES-256 algorithm. Both Amazon EBS and Amazon WorkSpaces use your KMS Key to work with the encrypted volumes. For more information about EBS volume encryption, see [Amazon EBS Encryption](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) in the *Amazon EC2 User Guide*.

When you launch WorkSpaces with encrypted volumes, the end-to-end process works like this:

1. You specify the KMS Key to use for encryption as well as the user and directory for the WorkSpace. This action creates a [grant](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) that allows WorkSpaces to use your KMS Key only for this WorkSpace—that is, only for the WorkSpace associated with the specified user and directory.

1. WorkSpaces creates an encrypted EBS volume for the WorkSpace and specifies the KMS Key to use as well as the volume's user and directory. This action creates a grant that allows Amazon EBS to use your KMS Key only for this WorkSpace and volume—that is, only for the WorkSpace associated with the specified user and directory, and only for the specified volume.

1. <a name="WSP-EBS-requests-encrypted-volume-data-key"></a>Amazon EBS requests a volume data key that is encrypted under your KMS Key and specifies the WorkSpace user's Active Directory security identifier (SID) and AWS Directory Service directory ID as well as the Amazon EBS volume ID as the [encryption context](#kms-workspaces-encryption-context).

1. <a name="WSP-KMS-creates-data-key"></a>AWS KMS creates a new data key, encrypts it under your KMS Key, and then sends the encrypted data key to Amazon EBS.

1. <a name="WSP-uses-EBS-to-attach-encrypted-volume"></a>WorkSpaces uses Amazon EBS to attach the encrypted volume to your WorkSpace. Amazon EBS sends the encrypted data key to AWS KMS with a [https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) request and specifies the WorkSpace user's SID, the directory ID, and the volume ID, which is used as the encryption context.

1. AWS KMS uses your KMS Key to decrypt the data key, and then sends the plain text data key to Amazon EBS.

1. Amazon EBS uses the plain text data key to encrypt all data going to and from the encrypted volume. Amazon EBS keeps the plain text data key in memory for as long as the volume is attached to the WorkSpace.

1. Amazon EBS stores the encrypted data key (received at [Step 4](#WSP-KMS-creates-data-key)) with the volume metadata for future use in case you reboot or rebuild the WorkSpace.

1. When you use the AWS Management Console to remove a WorkSpace (or use the [https://docs.aws.amazon.com/workspaces/latest/devguide/API_TerminateWorkspaces.html](https://docs.aws.amazon.com/workspaces/latest/devguide/API_TerminateWorkspaces.html) action in the WorkSpaces API), WorkSpaces and Amazon EBS retire the grants that allowed them to use your KMS Key for that WorkSpace.

## WorkSpaces encryption context
<a name="kms-workspaces-encryption-context"></a>

WorkSpaces doesn't use your KMS Key directly for cryptographic operations (such as [https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html), [https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html), [https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html), etc.), which means WorkSpaces doesn't send requests to AWS KMS that include an [ encryption context](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context). However, when Amazon EBS requests an encrypted data key for the encrypted volumes of your WorkSpaces ([Step 3](#WSP-EBS-requests-encrypted-volume-data-key) in the [Overview of WorkSpaces encryption using AWS KMS](#kms-workspaces-overview)) and when it requests a plain text copy of that data key ([Step 5](#WSP-uses-EBS-to-attach-encrypted-volume)), it includes encryption context in the request.

 The encryption context provides [additional authenticated data](https://docs.aws.amazon.com/crypto/latest/userguide/cryptography-concepts.html#term-aad) (AAD) that AWS KMS uses to ensure data integrity. The encryption context is also written to your AWS CloudTrail log files, which can help you understand why a given KMS Key was used. Amazon EBS uses the following for the encryption context:
+ The security identifier (SID) of the Active Directory user that is associated with the WorkSpace
+ The directory ID of the AWS Directory Service directory that is associated with the WorkSpace
+ The Amazon EBS volume ID of the encrypted volume

The following example shows a JSON representation of the encryption context that Amazon EBS uses:

```
{
  "aws:workspaces:sid-directoryid": "[S-1-5-21-277731876-1789304096-451871588-1107]@[d-1234abcd01]",
  "aws:ebs:id": "vol-1234abcd"
}
```

## Grant WorkSpaces permission to use a KMS Key on your behalf
<a name="kms-workspaces-permissions"></a>

You can protect your WorkSpace data under the AWS managed KMS Key for WorkSpaces (**aws/workspaces**) or a customer managed KMS Key. If you use a customer managed KMS Key, you need to grant WorkSpaces permission to use the KMS Key on behalf of the WorkSpaces administrators in your account. The AWS managed KMS Key for WorkSpaces has the required permissions by default.

To prepare your customer managed KMS Key for use with WorkSpaces, use the following procedure.

1. [Add your WorkSpaces administrators to the list of key users in the KMS Key's key policy](#kms-permissions-key-users)

1. [Give your WorkSpaces administrators additional permissions with an IAM policy](#kms-permissions-iam-policy)

Your WorkSpaces administrators also need permission to use WorkSpaces. For more information about these permissions, go to [Identity and access management for WorkSpaces](workspaces-access-control.md).

### Part 1: Add WorkSpaces administrators to as key users
<a name="kms-permissions-key-users"></a>

To give WorkSpaces administrators the permissions that they require, you can use the AWS Management Console or the AWS KMS API.

#### To add WorkSpaces administrators as key users for a KMS Key (console)
<a name="kms-permissions-users-consoleAPI"></a>

1. Sign in to the AWS Management Console and open the AWS Key Management Service (AWS KMS) console at [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).

1. To change the AWS Region, use the Region selector in the upper-right corner of the page.

1. In the navigation pane, choose **Customer managed keys**.

1. Choose the key ID or alias of your preferred customer managed KMS Key.

1. Choose the **Key policy** tab. Under **Key users**, choose **Add**.

1. In the list of IAM users and roles, select the users and roles that correspond to your WorkSpaces administrators, and then choose **Add**.

#### To add WorkSpaces administrators as key users for a KMS Key (API)
<a name="kms-permissions-users-api"></a>

1. Use the [GetKeyPolicy](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html) operation to get the existing key policy, and then save the policy document to a file.

1. Open the policy document in your preferred text editor. Add the IAM users and roles that correspond to your WorkSpaces administrators to the policy statements that [ give permission to key users](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users). Then save the file.

1. Use the [PutKeyPolicy](https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html) operation to apply the key policy to the KMS Key.

### Part 2: Grant WorkSpaces administrators additional permissions using an IAM policy
<a name="kms-permissions-iam-policy"></a>

If you select a customer managed KMS Key to use for encryption, you must establish IAM policies that allow Amazon WorkSpaces to use the KMS Key on behalf of an IAM user in your account who launches encrypted WorkSpaces. That user also needs permission to use Amazon WorkSpaces. For more information about creating and editing IAM user policies, see [ Managing IAM Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) in the *IAM User Guide* and [Identity and access management for WorkSpaces](workspaces-access-control.md).

WorkSpaces encryption requires limited access to the KMS Key. The following is a sample key policy that you can use. This policy separates the principals who can manage the AWS KMS Key from those who can use it. Before you use this sample key policy, replace the example account ID and IAM user name with actual values from your account.

The first statement matches the default AWS KMS key policy. It gives your account permission to use IAM policies to control access to the KMS Key. The second and third statements define which AWS principals can manage and use the key, respectively. The fourth statement enables AWS services that are integrated with AWS KMS to use the key on behalf of the specified principal. This statement enables AWS services to create and manage grants. The statement uses a condition element that limits grants on the KMS Key to those made by AWS services on behalf of users in your account.

**Note**  
If your WorkSpaces administrators use the AWS Management Console to create WorkSpaces with encrypted volumes, the administrators need permission to list aliases and list keys (the `"kms:ListAliases"` and `"kms:ListKeys"` permissions). If your WorkSpaces administrators use only the Amazon WorkSpaces API (not the console), you can omit the `"kms:ListAliases"` and `"kms:ListKeys"` permissions.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:user/Alice"},
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*"
       ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:user/Alice"},
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncryptFrom",
        "kms:ReEncryptTo",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:user/Alice"},
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {"Bool": {"kms:GrantIsForAWSResource": "true"}}
    }
  ]
}
```

------

The IAM policy for a user or role that is encrypting a WorkSpace must include usage permissions on the customer managed KMS Key, as well as access to WorkSpaces. To give an IAM user or role WorkSpaces permissions, you can attach the following sample policy to the IAM user or role.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ds:*",
                "ds:DescribeDirectories",
                "workspaces:*",
                "workspaces:DescribeWorkspaceBundles",
                "workspaces:CreateWorkspaces",
                "workspaces:DescribeWorkspaceBundles",
                "workspaces:DescribeWorkspaceDirectories",
                "workspaces:DescribeWorkspaces",
                "workspaces:RebootWorkspaces",
                "workspaces:RebuildWorkspaces"
            ],
            "Resource": "*"
        }
    ]
}
```

------

The following IAM policy is required by the user for using AWS KMS. It gives the user read-only access to the KMS Key along with the ability to create grants.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:CreateGrant",
                "kms:Describe*",
                "kms:List*"
            ],
            "Resource": "*"
        }
    ]
}
```

------

If you want to specify the KMS Key in your policy, use an IAM policy similar to the following. Replace the example KMS Key ARN with a valid one.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "kms:CreateGrant",
      "Resource": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
    },
    {
      "Effect": "Allow",
      "Action": [
        "kms:ListAliases",
        "kms:ListKeys"
      ],
      "Resource": "*"
    }
  ]
}
```

------

## Encrypt a WorkSpace
<a name="encrypt_workspace"></a>

**To encrypt a WorkSpace**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. Choose **Launch WorkSpaces** and complete the first three steps.

1. For the **WorkSpaces Configuration** step, do the following:

   1. Select the volumes to encrypt: **Root Volume**, **User Volume**, or both volumes.

   1. For **Encryption Key**, select an AWS KMS Key, either the AWS managed KMS Key created by Amazon WorkSpaces or a KMS Key that you created. The KMS Key that you select must be symmetric. Amazon WorkSpaces does not support asymmetric KMS Keys.

   1. Choose **Next Step**.

1. Choose **Launch WorkSpaces**.

## View encrypted WorkSpaces
<a name="maintain_encryption"></a>

To see which WorkSpaces and volumes have been encrypted from the WorkSpaces console, choose **WorkSpaces** from the navigation bar on the left. The **Volume Encryption** column shows whether each WorkSpace has encryption enabled or disabled. To see which specific volumes have been encrypted, expand the WorkSpace entry to see the **Encrypted Volumes** field.

# Reboot a WorkSpace in WorkSpaces Personal
<a name="reboot-workspaces"></a>

Occasionally, you might need to reboot (restart) a WorkSpace manually. Rebooting a WorkSpace disconnects the user and then performs a shutdown and reboot of the WorkSpace. To avoid data loss, make sure the user saves any open documents and other application files before you reboot the WorkSpace. The user data, operating system, and system settings are not affected.

**Warning**  
To reboot an encrypted WorkSpace, first make sure that the AWS KMS Key is enabled; otherwise, the WorkSpace becomes unusable. To determine whether a KMS Key is enabled, see [ Displaying KMS Key Details](https://docs.aws.amazon.com/kms/latest/developerguide/viewing-keys-console.html#viewing-console-details) in the *AWS Key Management Service Developer Guide*.

**To reboot a WorkSpace**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Select the WorkSpaces to reboot and choose **Actions**, **Reboot WorkSpaces**.

1. When prompted for confirmation, choose **Reboot WorkSpaces**.

**To reboot a WorkSpace using the AWS CLI**  
Use the [reboot-workspaces](https://docs.aws.amazon.com/cli/latest/reference/workspaces/reboot-workspaces.html) command.

**To bulk reboot WorkSpaces**  
Use the [amazon-workspaces-admin-module](https://github.com/aws-samples/amazon-workspaces-admin-module/tree/main).

# Rebuild a WorkSpace in WorkSpaces Personal
<a name="rebuild-workspace"></a>

Rebuilding a WorkSpace recreates the root volume of the most recent image of the bundle that the WorkSpace was launched from, its user volume, and its primary elastic network interface. Rebuilding a WorkSpace deletes more data than restoring a WorkSpace, but it only requires you to have a snapshot of the user volume. To restore a WorkSpace, see [Restore a WorkSpace in WorkSpaces Personal](restore-workspace.md).

Rebuilding a WorkSpace causes the following to occur:
+ The root volume (for Microsoft Windows, drive C; for Linux, /) is refreshed with the most recent image of the bundle that the WorkSpace was created from. Any applications that were installed, or system settings that were changed after the WorkSpace was created, are lost.
+ The user volume (for Microsoft Windows, the D drive; for Linux, /home) is recreated from the most recent snapshot. The current contents of the user volume are overwritten.

  Automatic snapshots for use when rebuilding a WorkSpace are scheduled every 12 hours. These snapshots of the user volume are taken regardless of the health of the WorkSpace. When you choose **Actions**, **Rebuild / Restore WorkSpace**, the date and time of the most recent snapshot is shown.

  When you rebuild a WorkSpace, new snapshots are also taken soon after the rebuild is finished (often within 30 minutes).
+ The primary elastic network interface is recreated. The WorkSpace receives a new private IP address.

**Important**  
After January 14, 2020, WorkSpaces created from a public Windows 7 bundle can no longer be rebuilt. You might want to consider migrating your Windows 7 WorkSpaces to Windows 10. For more information, see [Migrate a WorkSpace in WorkSpaces Personal](migrate-workspaces.md).

You can rebuild a WorkSpace only if the following conditions are met:
+ The WorkSpace must have a state of `AVAILABLE`, `ERROR`, `UNHEALTHY`, `STOPPED`, or `REBOOTING`. To rebuild a WorkSpace in the `REBOOTING` state, you must use the [ RebuildWorkspaces](https://docs.aws.amazon.com/workspaces/latest/api/API_RebuildWorkspaces.html) API operation or the [ rebuild-workspaces](https://docs.aws.amazon.com/cli/latest/reference/workspaces/rebuild-workspaces.html) AWS CLI command.
+ A snapshot of the user volume must exist.

**To rebuild a WorkSpace**
**Warning**  
To rebuild an encrypted WorkSpace, first make sure that the AWS KMS Key is enabled; otherwise, the WorkSpace becomes unusable. To determine whether a KMS Key is enabled, see [ Displaying KMS Key Details](https://docs.aws.amazon.com/kms/latest/developerguide/viewing-keys-console.html#viewing-console-details) in the *AWS Key Management Service Developer Guide*.

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Select the WorkSpace to rebuild and choose **Actions**, **Rebuild / Restore WorkSpace**.

1. Under **Snapshot**, select the snapshot's time stamp.

1. Choose **Rebuild**.

**To rebuild a WorkSpace using the AWS CLI**  
Use the [rebuild-workspaces](https://docs.aws.amazon.com/cli/latest/reference/workspaces/rebuild-workspaces.html) command.

**Troubleshooting**  
If you rebuild a WorkSpace after changing the user's **sAMAccountName** user naming attribute in Active Directory, you might receive the following error message:

```
"ErrorCode": "InvalidUserConfiguration.Workspace"
"ErrorMessage": "The user was either not found or is misconfigured."
```

To work around this issue, either revert to the original user naming attribute and then re-initiate the rebuild, or create a new WorkSpace for that user.

**Rebuild Microsoft Entra ID-joined WorkSpaces**  
When a user logs in to their WorkSpace for the first time after rebuilding, they need to go through the out-of-box experience (OOBE) again, similar to when they were assigned a new WorkSpace. As a result, a new user profile folder is created on the WorkSpace, overriding the original user profile folder. Hence, during the rebuild of an Entra joined WorkSpace, the content from the original user profile folder is saved under `D:\Users\<USERNAME%MMddyyTHHmmss%.NotMigrated>` on the rebuilt WorkSpace. The user needs to copy the original profile content from `D:\Users\<USERNAME%MMddyyTHHmmss%.NotMigrated>` to the user's profile folder at D:\$1Users\$1<USERNAME> to restore all user profile data including desktop icons, shortcuts, and data files.

**Note**  
For Microsoft Entra ID-joined WorkSpaces, we recommend to always use Restore WorkSpaces, when possible, instead of Rebuild WorkSpaces.

# Restore a WorkSpace in WorkSpaces Personal
<a name="restore-workspace"></a>

Restoring a WorkSpace recreates both the root volume and user volume using a snapshot of each volume that was taken when the WorkSpace was health. Restoring a WorkSpace rolls back the data on both the root and user volumes to the point in time when the snapshots were created. Rebuilding a WorkSpace only rolls back the data on the user volume. This means that restoring requires you to have snapshots of both the root volume and user volume, while rebuilding a WorkSpace only requires a snapshot of the user volume. To rebuild a WorkSpace, see [Rebuild a WorkSpace in WorkSpaces Personal](rebuild-workspace.md).

Restoring a WorkSpace causes the following to occur:
+ The root volume (for Microsoft Windows, drive C; for Linux, /) is restored to the date and time specified using a snapshot. Any applications that were installed, or system settings that were changed after the snapshot was created, are lost.
+ The user volume (for Microsoft Windows, the D drive; for Linux, /home) is recreated to the date and time specified using a snapshot. The current contents of the user volume are overwritten.

**The restore point**  
When you choose **Actions** and **Rebuild / Restore WorkSpace**, the date and time of the snapshots used for the operation are shown. To verify the date and time of the snapshots used for the operation using the AWS CLI, use the [describe-workspace-snapshots](https://docs.aws.amazon.com/cli/latest/reference/workspaces/describe-workspace-snapshots.html) command. 

**When snapshots are taken**  
Snapshots of the root and user volume are taken on the following basis. 
+ **After a WorkSpace is first created** — Typically, the initial snapshots of the root and user volumes are taken soon after a WorkSpace is created (often within 30 minutes). In some AWS Regions, it might take several hours to take the initial snapshots after a WorkSpace is created.

  If a WorkSpace becomes unhealthy before the initial snapshots are taken, the WorkSpace can't be restored. In that case, you can try [ rebuilding the WorkSpace](rebuild-workspace.md) or contact AWS Support for assistance.
+ **During regular use** — Automatic snapshots for use when restoring a WorkSpace are scheduled every 12 hours. If the WorkSpace is healthy, snapshots of both the root volume and user volume are created around the same time. If the WorkSpace is unhealthy, snapshots are created only for the user volume.
+ **After a WorkSpace has been restored** — When you restore a WorkSpace, new snapshots are taken soon after the restore is finished (often within 30 minutes). In some AWS Regions, it might take several hours to take these snapshots after a WorkSpace is restored.

  After a WorkSpace has been restored, if the WorkSpace becomes unhealthy before new snapshots can be taken, the WorkSpace can't be restored again. In that case, you can try [rebuilding the WorkSpace](rebuild-workspace.md) or contact AWS Support for assistance.

You can restore a WorkSpace only if the following conditions are met:
+ The WorkSpace must have a state of `AVAILABLE`, `ERROR`, `UNHEALTHY`, or `STOPPED`.
+ Snapshots of the root and user volumes must exist.

**To restore a WorkSpace**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Select the WorkSpace to restore and choose **Actions**, **Rebuild / Restore WorkSpace**.

1. Under **Snapshot**, select the snapshot's time stamp.

1. Choose **Restore**.

**To restore a WorkSpace using the AWS CLI**  
Use the [restore-workspace](https://docs.aws.amazon.com/cli/latest/reference/workspaces/restore-workspace.html) command.

# Microsoft 365 Bring Your Own License (BYOL) in WorkSpaces Personal
<a name="byol-microsoft365-licenses"></a>

Amazon WorkSpaces allows you to bring your own Microsoft 365 licenses if they meet Microsoft's licensing requirements. These licenses allow you to install and activate Microsoft 365 Apps for enterprise software on WorkSpaces that are powered by the following operating systems:
+ Windows 10 (Bring Your Own License)
+ Windows 11 (Bring Your Own License)
+ Windows Server 2016
+ Windows Server 2019
+ Windows Server 2022
+ Windows Server 2025

To use Microsoft 365 Apps for enterprise on WorkSpaces, you must have subscription to Microsoft 365 E3/E5, Microsoft 365 A3/A5, Microsoft 365 G3/G5, or Microsoft 365 Business Premium.

On your Amazon WorkSpaces you can use your Microsoft 365 licenses to install and activate Microsoft 365 Apps for enterprise, including the following:
+ Microsoft Word
+ Microsoft Excel
+ Microsoft PowerPoint
+ Microsoft Outlook
+ Microsoft OneDrive

For more information, see the [full list of Microsoft 365 Apps for enterprise](https://www.microsoft.com/en/microsoft-365/enterprise/microsoft-365-apps-for-enterprise-product?activetab=pivot%3Aoverviewtab&market=af&ranMID=24542&ranEAID=QKfOgZNb5HA&ranSiteID=QKfOgZNb5HA-uvIr8evP5gLQf8n3Z0NLJA&epi=QKfOgZNb5HA-uvIr8evP5gLQf8n3Z0NLJA&irgwc=1&OCID=AIDcmm549zy227_aff_7593_1243925&tduid=%28ir__caugvllhggkfbgesuvvv2g21je2xb3afmz3ilkpl00%29%287593%29%281243925%29%28QKfOgZNb5HA-uvIr8evP5gLQf8n3Z0NLJA%29%28%29&irclickid=_caugvllhggkfbgesuvvv2g21je2xb3afmz3ilkpl00).

You can also install Microsoft applications not included with Microsoft 365, such as Microsoft Project, Microsoft Visio, and Microsoft Power Automate on WorkSpaces but you need to bring in your own additional licenses. 

You can install and use Microsoft 365 and other Microsoft applications on primary WorkSpaces and failover WorkSpaces using [Multi-Region Resilience](https://docs.aws.amazon.com/workspaces/latest/adminguide/multi-region-resilience.html).

**Topics**
+ [

## Create WorkSpaces with Microsoft 365 Apps for enterprise
](#create-workspaces-microsoft365)
+ [

## Migrate your existing WorkSpaces to use Microsoft 365 Apps for enterprise
](#migrate-workspaces-microsoft365)
+ [

## Update your Microsoft 365 Apps for enterprise on WorkSpaces
](#microsoft365-update)

## Create WorkSpaces with Microsoft 365 Apps for enterprise
<a name="create-workspaces-microsoft365"></a>

To create WorkSpaces with Microsoft 365 Apps for enterprise, you must create a custom image with the applications installed, and use it to create a custom bundle. You can use the bundle to launch new WorkSpaces that have the applications installed. WorkSpaces does not provide public bundles with Microsoft 365 Apps for enterprise.

**To create WorkSpaces with Microsoft 365 Apps for enterprise:**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. Launch a WorkSpace that you want to use as the image for other Microsoft application WorkSpaces. This is where you will install your Microsoft applications. For more information about launching a WorkSpace, see [Launch a virtual desktop using WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspaces-tutorials.html). 

1. Start the client application at [https://clients.amazonworkspaces.com/](https://clients.amazonworkspaces.com/), enter the registration code from your invitation email, and choose **Register**.

1. When prompted to sign in, enter the user's sign-in credentials, and then choose **Sign In**.

1. Install and configure your Microsoft 365 Apps for enterprise.

1. Create a custom image from the WorkSpace, and use it to create a custom bundle. For more information about creating custom images and bundles, see [Create a custom WorkSpaces image and bundle](https://docs.aws.amazon.com/workspaces/latest/adminguide/create-custom-bundle.html).

1. Launch WorkSpaces using the custom bundle that you created. These WorkSpaces have Microsoft 365 Apps for enterprise installed.

## Migrate your existing WorkSpaces to use Microsoft 365 Apps for enterprise
<a name="migrate-workspaces-microsoft365"></a>

If your WorkSpaces don't have a Microsoft Office license through AWS, you can install and configure Microsoft 365 Apps for enterprise on your WorkSpaces. 

 If your WorkSpaces do have a Microsoft Office license through AWS, you must first deregister your Microsoft Office license before installing Microsoft 365 Apps for enterprise. 

**Important**  
Uninstalling Microsoft Office applications from your WorkSpaces doesn't deregister the licenses. To avoid being charged for Microsoft Office licenses, deregister your WorkSpaces from Microsoft Office applications through AWS by doing either of the following:  
 **Manage applications** (recommended) – You can uninstall Microsoft Office version licenses from your WorkSpaces. For more information, see [Manage applications](manage-applications). After you uninstall, you can install Microsoft 365 Apps for enterprise on your WorkSpaces. 
 **Migrate a WorkSpace** – You can migrate a WorkSpace from one bundle to another while retaining the data on the user volume.   
Migrate your WorkSpaces to a bundle with an image that doesn’t have a Microsoft Office subscription. After the migration is complete, you can install Microsoft 365 Apps for enterprise on your WorkSpaces.
Or, create a custom WorkSpaces image and bundle that already has Microsoft 365 Apps for enterprise installed on the image, and then migrate your WorkSpaces to this new custom bundle. After migration is complete, your WorkSpaces users can start using Microsoft 365 Apps for enterprise.
For more information on how to migrate WorkSpaces, see [Migrate a WorkSpace](migrate-workspaces).

## Update your Microsoft 365 Apps for enterprise on WorkSpaces
<a name="microsoft365-update"></a>

By default, your WorkSpaces running on the Microsoft Windows Operating System are configured to receive updates from Windows Update. However, updates for Microsoft 365 Apps for enterprise aren't available using Windows Update. Set up updates to run automatically from the Office CDN, or use Windows Server Update Services (WSUS) in conjunction with Microsoft Configuration Manager to update Microsoft 365 Apps for enterprise. For more information, see [ Manage updates to Microsoft 365 Apps with Microsoft Configuration Manager](https://learn.microsoft.com/en-us/deployoffice/updates/manage-microsoft-365-apps-updates-configuration-manager). To set the frequency of Microsoft 365 application updates, specify an update channel and set it to Current or Monthly Enterprise to comply with the Microsoft 365 on WorkSpaces licensing policy.

# Upgrade Windows BYOL WorkSpaces in WorkSpaces Personal
<a name="upgrade-windows-10-byol-workspaces"></a>

On your Windows Bring Your Own License (BYOL) WorkSpaces, you can upgrade to a newer version of Windows using the in-place upgrade process. Follow the instructions in this topic to do so.

The in-place upgrade process applies only to Windows 10 and 11 BYOL WorkSpaces.

**Important**  
Do not run Sysprep on an upgraded WorkSpace. If you do so, an error that prevents Sysprep from finishing might occur. If you plan to run Sysprep, do so only on a WorkSpace that hasn't been upgraded.

**Note**  
You can use this process to upgrade your Windows 10 and 11 WorkSpaces to a newer version. However, this process cannot be used to upgrade your Windows 10 WorkSpaces to Windows 11.

**Topics**
+ [

## Prerequisites
](#upgrade_byol_prerequisites)
+ [

## Considerations
](#upgrade_byol_important_considerations)
+ [

## Known limitations
](#byol-known-limitations)
+ [

## Summary of registry key settings
](#upgrade_byol_registry_summary)
+ [

## Perform an in-place upgrade
](#upgrade_byol_procedure)
+ [

## Troubleshooting
](#byol-troubleshooting)
+ [

## Update your WorkSpace registry using a PowerShell script
](#update-windows-10-byol-script)

## Prerequisites
<a name="upgrade_byol_prerequisites"></a>
+ If you have deferred or paused Windows 10 and 11 upgrades by using Group Policy or System Center Configuration Manager (SCCM), enable operating system upgrades for your Windows 10 and 11 WorkSpaces.
+ If the WorkSpace is an AutoStop WorkSpace, change it to an AlwaysOn WorkSpace before the in-place upgrade process so that it won't stop automatically while updates are being applied. For more information, see [Modify the running mode](running-mode.md#modify-running-mode). If you prefer to keep the WorkSpace set to AutoStop, change the AutoStop time to three hours or more while the upgrade takes place.
+ The in-place upgrade process recreates the user profile by making a copy of a special profile named Default User (`C:\Users\Default`). Do not use this default user profile to make customizations. We recommend making any customizations to the user profile through Group Policy Objects (GPOs) instead. Customizations made through GPOs can be easily modified or rolled back and are less prone to error.
+ The in-place upgrade process can back up and recreate only one user profile. If you have multiple user profiles on drive D, delete all the profiles except for the one that you need.

## Considerations
<a name="upgrade_byol_important_considerations"></a>

The in-place upgrade process uses two registry scripts (`enable-inplace-upgrade.ps1` and `update-pvdrivers.ps1`) to make the necessary changes to your WorkSpaces that enable the Windows Update process to run. These changes involve creating a (temporary) user profile on drive C instead of drive D. If a user profile already exists on drive D, the data in that original user profile remains on drive D.

By default, WorkSpaces creates the user profile in `D:\Users\%USERNAME%`. The `enable-inplace-upgrade.ps1` script configures Windows to create a new user profile in `C:\Users\%USERNAME%` and redirects the user shell folders to `D:\Users\%USERNAME%`. This new user profile is created when a user logs on the first time.

After the in-place upgrade, you have the choice of leaving your user profiles on drive C to allow your users to use the Windows Update process to upgrade their machines in the future. However, be aware that WorkSpaces with profiles stored on drive C can't be rebuilt or migrated without losing all of the data in the user's profile unless you back up and restore that data yourself. If you decide to leave the profiles on drive C, you can use the **UserShellFoldersRedirection** registry key to redirect the user shell folders to drive D, as explained later in this topic.

To ensure that you can rebuild or migrate your WorkSpaces and to avoid any potential problems with user shell folder redirection, we recommend that you choose to restore your user profiles to drive D after the in-place upgrade. You can do so by using the **PostUpgradeRestoreProfileOnD** registry key, as explained later in this topic. 

## Known limitations
<a name="byol-known-limitations"></a>
+ The user profile location change from drive D to drive C does not happen during WorkSpace rebuilds or migrations. If you perform an in-place upgrade on a Windows 10 or 11 BYOL WorkSpace and then rebuild or migrate it, the new WorkSpace will have the user profile on drive D.
**Warning**  
If you leave the user profile on drive C after the in-place upgrade, the user profile data stored on drive C will be lost during rebuilds or migrations unless you manually back up the user profile data prior to rebuilding or migrating, and then manually restore the user profile data after running the rebuild or migration process.
+ If your default BYOL bundle contains an image that is based on an earlier release of Windows 10 and 11, you must perform the in-place upgrade again after the WorkSpace is rebuilt or migrated.

## Summary of registry key settings
<a name="upgrade_byol_registry_summary"></a>

To enable the in-place upgrade process and to specify where you would like the user profile to be after the upgrade, you must set a number of registry keys.


**Registry path: **HKLM:\$1Software\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1****  

| Registry key | Type | Values | 
| --- | --- | --- | 
| Enabled | DWORD |  **0** – (Default) Disables in-place upgrade **1** – Enables in-place upgrade  | 
| PostUpgradeRestoreProfileOnD | DWORD |  **0** – (Default) Does not attempt to restore the user profile path after the in-place upgrade **1** – Restores the user profile path (**ProfileImagePath**) after the in-place upgrade  | 
| UserShellFoldersRedirection | DWORD |  **0** – Does not enable redirection of user shell folders **1** – (Default) Enables redirection of user shell folders to `D:\Users\%USERNAME%` after the user profile is regenerated on `C:\Users\%USERNAME%`  | 
| NoReboot | DWORD |  **0** – (Default) Allows you to control when a reboot occurs after modifying the registry for the user profile **1** – Does not allow the script to reboot the WorkSpace after modifying the registry for the user profile  | 


**Registry path: **HKLM:\$1Software\$1Amazon\$1WorkSpacesConfig\$1update-pvdrivers.ps1****  

| Registry key | Type | Values | 
| --- | --- | --- | 
| Enabled | DWORD |  **0** – (Default) Disables AWS PV drivers update **1** – Enables AWS PV drivers update  | 

## Perform an in-place upgrade
<a name="upgrade_byol_procedure"></a>

To enable in-place Windows upgrades on your BYOL WorkSpaces, you must set certain registry keys, as described in the following procedure. You must also set certain registry keys to indicate the drive (C or D) where you want the user profiles to be after the in-place upgrades are finished.

You can make these registry changes manually. If you have multiple WorkSpaces to update, you can use Group Policy or SCCM to push a PowerShell script. For a sample PowerShell script, see [Update your WorkSpace registry using a PowerShell script](#update-windows-10-byol-script).

**To perform an in-place upgrade of Windows 10 and 11**

1. Make note of which version of Windows is currently running on the Windows 10 and 11 BYOL WorkSpaces that you are updating, and then reboot them.

1. Update the following Windows system registry keys to change the value data for **Enabled** from **0** to **1**. These registry changes enable in-place upgrades for the WorkSpace.
   + **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1**
   + **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1update-pvdrivers.ps1**
**Note**  
If these keys do not exist, reboot the WorkSpace. The keys should be added when the system is rebooted.

   (Optional) If you are using a managed workflow such as SCCM Task Sequences to perform the upgrade, set the following key value to **1** to prevent the computer from rebooting:

   **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1\$1NoReboot**

1. Decide which drive you want user profiles to be on after the in-place upgrade process (for more information, see [Considerations](#upgrade_byol_important_considerations)), and set the registry keys as follows:
   + Settings if you want the user profile on drive C after the upgrade:

     **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1**

     Key name: **PostUpgradeRestoreProfileOnD**

     Key value: **0**

     Key name: **UserShellFoldersRedirection**

     Key value: **1**
   + Settings if you want the user profile on drive D after the upgrade:

     **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1**

     Key name: **PostUpgradeRestoreProfileOnD**

     Key value: **1**

     Key name: **UserShellFoldersRedirection**

     Key value: **0**

1. After saving the changes to the registry, reboot the WorkSpace again so that the changes are applied.
**Note**  
After the reboot, logging in to the WorkSpace creates a new user profile. You might see placeholder icons in the **Start** menu. This behavior is automatically resolved after the in-place upgrade is complete.
Allow 10 minutes to ensure that the WorkSpace is unblocked.

   (Optional) Confirm that the following key value is set to **1**, which unblocks the WorkSpace for updating:

   **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1\$1profileImagePathDeleted**

1. Perform the in-place upgrade. You can use whichever method you like, such as SCCM, ISO, or Windows Update (WU). Depending on your original Windows 10 and 11 version and how many apps were installed, this process can take from 40 to 120 minutes.
**Note**  
The in-place upgrade process may take at least an hour. The WorkSpace instance status may appear as `UNHEALTHY` during the upgrade.

1. After the update process is finished, confirm that the Windows version has been updated.
**Note**  
If the in-place upgrade fails, Windows automatically rolls back to use the Windows 10 and 11 version that was in place before you started the upgrade. For more information about troubleshooting, see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows/deployment/upgrade/resolve-windows-10-upgrade-errors).

   (Optional) To confirm that the update scripts have been run successfully, verify that the following key value is set to **1**:

   **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1WorkSpacesConfig\$1enable-inplace-upgrade.ps1\$1scriptExecutionComplete**

1. If you modified the running mode of the WorkSpace by setting it to AlwaysOn or by changing the AutoStop time period so that the in-place upgrade process could run without interruption, set the running mode back to your original settings. For more information, see [Modify the running mode](running-mode.md#modify-running-mode).

If you haven't set the **PostUpgradeRestoreProfileOnD** registry key to **1**, the user profile is regenerated by Windows and placed in `C:\Users\%USERNAME%` after the in-place upgrade, so that you do not have to go through the above steps again for future Windows 10 and 11 in-place upgrades. By default, the `enable-inplace-upgrade.ps1` script redirects the following shell folders to drive D:
+ `D:\Users\%USERNAME%\Downloads`
+ `D:\Users\%USERNAME%\Desktop`
+ `D:\Users\%USERNAME%\Favorites`
+ `D:\Users\%USERNAME%\Music`
+ `D:\Users\%USERNAME%\Pictures`
+ `D:\Users\%USERNAME%\Videos`
+ `D:\Users\%USERNAME%\Documents`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Network Shortcuts`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Printer Shortcuts`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Recent`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\SendTo`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Start Menu`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup`
+ `D:\Users\%USERNAME%\AppData\Roaming\Microsoft\Windows\Templates`

If you redirect the shell folders to other locations on your WorkSpaces, perform the necessary operations on the WorkSpaces after the in-place upgrades.

## Troubleshooting
<a name="byol-troubleshooting"></a>

If you encounter any issues with the update, you can check the following items to assist with troubleshooting:
+ Windows Logs, which are located, by default, in the following locations:

  `C:\Program Files\Amazon\WorkSpacesConfig\Logs\`

  `C:\Program Files\Amazon\WorkSpacesConfig\Logs\TRANSMITTED`
+ Windows Event Viewer

  Windows Logs > Application > Source: Amazon WorkSpaces

**Tip**  
During the in-place upgrade process, if you see that some icon shortcuts on the desktop no longer work, it's because WorkSpaces moves any user profiles located on drive D to drive C to prepare for the upgrade. After the upgrade is completed, the shortcuts will work as expected.

### Windows 11 24H2 Upgrade using ISO error resolution
<a name="upgrade-iso-resolution"></a>

The Windows 11 24H2 upgrade process may encounter a critical boot failure during the second boot phase, specifically presenting error code 0xC1900101 - 0x40017. This error typically occurs due to a missing or corrupted system driver file that prevents the installation from completing successfully during the boot operation phase.

*Error Code:*0xC1900101 - 0x40017

*Error Description:*Installation failure during SECOND\$1BOOT phase with BOOT operation error

1. Ensure you have the Windows 11 24H2 ISO file.

1. Open a command prompt as administrator.

1. Copy the required system file using this command:

   ```
   copy "ISO-Drive:\Sources\WinSetupMon.sys" "C:\Windows\System32\Drivers\"
   ```

   Replace **ISO-Drive** with your ISO drive information.

1. Verify the file copy by using:

   ```
   C:\Windows\System32\Drivers\
   ```

1. Initiate Windows 11 24H2 upgrade using the ISO file.

## Update your WorkSpace registry using a PowerShell script
<a name="update-windows-10-byol-script"></a>

You can use the following sample PowerShell script to update the registry on your WorkSpaces to enable in-place upgrades. Follow the [Perform an in-place upgrade](#upgrade_byol_procedure), but use this script to update the registry on each WorkSpace.

```
# AWS WorkSpaces 1.28.20
# Enable In-Place Update Sample Scripts
# These registry keys and values will enable scripts to run on the next reboot of the WorkSpace.
 
$scriptlist = ("update-pvdrivers.ps1","enable-inplace-upgrade.ps1")
$wsConfigRegistryRoot="HKLM:\Software\Amazon\WorkSpacesConfig"
$Enabled = 1
$script:ErrorActionPreference = "Stop"
 
foreach ($scriptName in $scriptlist)
{
    $scriptRegKey = "$wsConfigRegistryRoot\$scriptName"
    
    try
    {
        if (-not(Test-Path $scriptRegKey))
        {        
            Write-Host "Registry key not found. Creating registry key '$scriptRegKey' with 'Update' enabled."
            New-Item -Path $wsConfigRegistryRoot -Name $scriptName | Out-Null
            New-ItemProperty -Path $scriptRegKey -Name Enabled -PropertyType DWord -Value $Enabled | Out-Null
            Write-Host "Value created. '$scriptRegKey' Enabled='$((Get-ItemProperty -Path $scriptRegKey).Enabled)'"
        }
        else
        {
            Write-Host "Registry key is already present with value '$scriptRegKey' Enabled='$((Get-ItemProperty -Path $scriptRegKey).Enabled)'"
            if((Get-ItemProperty -Path $scriptRegKey).Enabled -ne $Enabled)
            {
                Set-ItemProperty -Path $scriptRegKey -Name Enabled -Value $Enabled
                Write-Host "Value updated. '$scriptRegKey' Enabled='$((Get-ItemProperty -Path $scriptRegKey).Enabled)'"
            }
        }
    }
    catch
    {
        write-host "Stopping script, the following error was encountered:" `r`n$_ -ForegroundColor Red
        break
    }
}
```

# Migrate a WorkSpace in WorkSpaces Personal
<a name="migrate-workspaces"></a>

**Note**  
If you want to unsubscribe from or uninstall Microsoft Office version licenses through AWS from your WorkSpace, we recommend using [Manage applications](manage-applications).

You can migrate a WorkSpace from one bundle to another, while retaining the data on the user volume. The following are example scenarios:
+ You can migrate WorkSpaces from the Windows 7 desktop experience to the Windows 10 desktop experience.
+ You can migrate WorkSpaces from the PCoIP protocol to DCV.
+ You can migrate WorkSpaces from the 32-bit Microsoft Office on Windows Server 2016-powered WorkSpaces bundle to the 64-bit Microsoft Office on Windows Server 2019 and Windows Server 2022-powered WorkSpaces bundles.
+ You can migrate WorkSpaces from one public or custom bundle to another. For example, you can migrate from GPU-enabled (Graphics.g6, Graphics.g4dn. GraphicsPro.g4dn, Graphics, and GraphicsPro) bundles to non-GPU-enabled bundles, as well as in the other direction.
+ You can migrate WorkSpaces from the Windows 10 BYOL to the Windows 11 BYOL but migration from Windows 11 to Windows 10 is not supported.
+ Value bundles are not supported on Windows 11. To migrate your Windows 7 or 10 value bundle WorkSpaces to Windows 11, you need to switch your Value WorkSpaces to a bigger bundle offering first. 
+ Before migrating WorkSpaces from Windows 7 to Windows 11, you need to migrate it to Windows 10. Log in to Windows 10 WorkSpace at least once before migrating it to Windows 11. Migrating from Windows 7 WorkSpaces directly to Windows 11 is not supported.
+ You can migrate Windows WorkSpaces that use Microsoft Office through AWS to a custom WorkSpaces bundle with Microsoft 365 applications. After the migration, your WorkSpaces are unsubscribed from Microsoft Office.
+ You can migrate Windows WorkSpaces that use Microsoft Office through AWS to a WorkSpaces bundle with no Office 2016/2019 subscription. After the migration, your WorkSpaces are unsubscribed from Microsoft Office.
+ You can migrate BYOL BYOP WorkSpaces from Windows 10 to Windows 11, and license-included BYOP WorkSpaces from Windows Server 2019 to Windows Server 2022.
+ You can migrate any Windows Server powered WorkSpace bundle to Windows Server 2025. Once migrated, you will be using DCV streaming protocol to enable high-performance remote desktop streaming, even with graphics-intensive applications, over varying network conditions, even with less powerful client devices.
+ You can migrate any Windows Server license-included BYOP WorkSpace bundle to BYOP Windows Server 2025. 

For more information about Amazon WorkSpaces bundles, see [Bundles and images for WorkSpaces Personal](amazon-workspaces-bundles.md).

The migration process recreates the WorkSpace by using a new root volume from the target bundle image and the user volume from the last available snapshot of the original WorkSpace. A new user profile is generated during migration for better compatibility. The old user profile is renamed, and then certain files in the old user profile are moved to the new user profile. (For details about what gets moved, see [What happens during migration](#during-migration).)

The migration process takes up to one hour per WorkSpace. When you initiate the migration process, a new WorkSpace is created. If an error occurs that prevents successful migration, the original WorkSpace is recovered and returned to its original state, and the new WorkSpace is terminated.

**Contents**
+ [

## Migration limits
](#migration-limits)
+ [

## Migration scenarios
](#migration-scenarios)
+ [

## What happens during migration
](#during-migration)
+ [

## Best practices
](#migration-best-practices)
+ [

## Troubleshooting
](#migration_troubleshooting)
+ [

## How billing is affected
](#migration-billing)
+ [

## Migrating a WorkSpace
](#migration-workspaces)

## Migration limits
<a name="migration-limits"></a>
+ You cannot migrate to a public or custom Windows 7 desktop experience bundle. You also cannot migrate to Bring Your Own License (BYOL) Windows 7 bundles.
+ You can migrate BYOL WorkSpaces only to other BYOL bundles. To migrate a BYOL WorkSpace from PCoIP to DCV, you must first create a BYOL bundle with the DCV protocol. You can then migrate your PCoIP BYOL WorkSpaces to that DCV BYOL bundle. 
+ You cannot migrate a WorkSpace created from public or custom bundles to a BYOL bundle.
+ DCV Protocol supports Graphics G6 bundles, Graphics.g4dn, and GraphicsPro.g4dn on Windows. On Ubuntu, only Graphics.g4dn and GraphicsPro.g4dn are available.
+ PCoIP Protocol supports Graphics.g4dn and GraphicsPro.g4dn bundles on Windows only.
+ Migrating Linux WorkSpaces is not currently supported.
+ In AWS Regions that support more than one language, you can migrate WorkSpaces between language bundles.
+ The source and target bundles must be different. (However, in Regions that support more than one language, you can migrate to the same Windows 10 bundle as long as the languages differ.) If you want to refresh your WorkSpace using the same bundle, [rebuild the WorkSpace](rebuild-workspace.md) instead.
+ You cannot migrate WorkSpaces across Regions.
+ In some cases, if migration is unable to finish successfully, you might not receive an error message, and it might appear that the migration process did not start. If the WorkSpace bundle remains the same one hour after attempting migration, the migration is unsuccessful. Contact the [AWS Support Center](https://console.aws.amazon.com/support/home#/) for assistance.
+ You cannot migrate BYOP WorkSpaces to PCoIP or DCV WorkSpaces.
+ You cannot migrate Active Directory domain-joined WorkSpaces to Microsoft Entra-joined WorkSpaces.

## Migration scenarios
<a name="migration-scenarios"></a>

The following table shows which migration scenarios are available:


| Source OS | Target OS | Available? | 
| --- | --- | --- | 
|  Public or custom bundle Windows 7  |  Public or custom bundle Windows 10  |  Yes  | 
|  Custom bundle Windows 7  |  Public bundle Windows 7  |  No  | 
|  Custom bundle Windows 7  |  Custom bundle Windows 7  |  No  | 
|  Public bundle Windows 7  |  Custom bundle Windows 7  |  No  | 
|  Public or custom bundle Windows 10  |  Public or custom bundle Windows 7  |  No  | 
|  Public or custom bundle Windows 10  |  Custom bundle Windows 10  |  Yes  | 
|  Windows 7 BYOL bundle  |  Windows 7 BYOL bundle  | No | 
| Windows 7 BYOL bundle |  Windows 10 BYOL bundle  |  Yes  | 
|  Windows 10 BYOL bundle  |  Windows 7 BYOL bundle  |  No  | 
|  Windows 10 BYOL bundle  |  Windows 10 BYOL bundle  |  Yes  | 
|  Windows Server 2016-powered Public Windows 10 bundle  |  Windows Server 2019-powered Public Windows 10 bundle  |  Yes  | 
|  Windows Server 2019-powered Public Windows 10 bundle  |  Windows Server 2016-powered Public Windows 10 bundle  |  Yes  | 
|  Windows 10 BYOL bundle  |  Windows 11 BYOL bundle  |  Yes  | 
|  Windows 11 BYOL bundle  |  Windows 10 BYOL bundle  |  No  | 
|  Windows Server 2016-powered custom Windows 10 bundle  |  Windows Server 2019-powered Public Windows 10 bundle  |  Yes  | 
|  Windows Server 2016-powered custom Windows 10 bundle  |  Windows Server 2022-powered Public Windows 10 bundle  |  Yes  | 
|  Windows Server 2019-powered custom Windows 10 bundle  |  Windows Server 2022-powered Public Windows 10 bundle  |  Yes  | 
| Windows 10 BYOP BYOL | Windows 11 BYOP BYOL | Yes | 
| Windows 11 BYOP BYOL | Windows 10 BYOP BYOL | No | 
| Windows Server 2019-powered Public BYOP  | Windows Server 2022-powered Public BYOP  | Yes | 
| Windows Server 2022-powered Public BYOP  | Windows Server 2019-powered Public BYOP  | No | 
| Windows Server 2019-powered Public BYOP  | Windows Server 2025-powered Public BYOP  | Yes | 
| Windows Server 2025-powered Public BYOP  | Windows Server 2019-powered Public BYOP  | No | 
| Windows Server 2022-powered Public BYOP  | Windows Server 2025-powered Public BYOP  | Yes | 
| Windows Server 2025-powered Public BYOP  | Windows Server 2022-powered Public BYOP  | No | 
| Windows Server 2019-powered Public Windows 10 bundle  | Windows Server 2025-powered Public BYOP  | Yes | 
| Windows Server 2019-powered Custom Windows 10 bundle  | Windows Server 2025-powered Public BYOP  | Yes | 
| Windows Server 2022-powered Public Windows 10 bundle  | Windows Server 2025-powered Public BYOP  | Yes | 
| Windows Server 2022-powered Custom Windows 10 bundle  | Windows Server 2025-powered Public BYOP  | Yes | 

**Note**  
Web access is not available for the Windows Server 2019-powered Public Windows 10 bundle PCoIP branch.

## What happens during migration
<a name="during-migration"></a>

During migration, the data on the user volume (drive D) is preserved, but all of the data on the root volume (drive C) is lost. This means that none of the installed applications, settings, and changes to the registry are preserved. The old user profile folder is renamed with the `.NotMigrated` suffix, and a new user profile is created.

The migration process recreates drive D based on the last snapshot of the original user volume. During the first boot of the new WorkSpace, the migration process moves the original `D:\Users\%USERNAME%` folder to a folder named `D:\Users\%USERNAME%MMddyyTHHmmss%.NotMigrated`. A new `D:\Users\%USERNAME%\` folder is generated by the new OS.

After the new user profile is created, the files in the following user shell folders are moved from the old `.NotMigrated` profile to the new profile:
+ `D:\Users\%USERNAME%\Desktop`
+ `D:\Users\%USERNAME%\Documents`
+ `D:\Users\%USERNAME%\Downloads`
+ `D:\Users\%USERNAME%\Favorites`
+ `D:\Users\%USERNAME%\Music`
+ `D:\Users\%USERNAME%\Pictures`
+ `D:\Users\%USERNAME%\Videos`

**Important**  
The migration process attempts to move the files from the old user profile to the new profile. Any files that weren't moved during migration remain in the `D:\Users\%USERNAME%MMddyyTHHmmss%.NotMigrated` folder. If the migration is successful, you can see which files got moved in `C:\Program Files\Amazon\WorkspacesConfig\Logs\MigrationLogs`. You can manually move any files that didn't get moved automatically.  
By default, the public bundles have local search indexing disabled. If you were to enable it, the default is to search `C:\Users` and not `D:\Users`, so you need to adjust that as well. If you've set local search indexing specifically to `D:\Users\username` and not to `D:\Users`, then local search indexing might not work post-migration for any user files that are in the `D:\Users\%USERNAME%MMddyyTHHmmss%.NotMigrated` folder.

Any tags assigned to the original WorkSpace are carried over during migration, and the running mode of the WorkSpace is preserved. However, the new WorkSpace gets a new WorkSpace ID, computer name, and IP address.

## Best practices
<a name="migration-best-practices"></a>

Before you migrate a WorkSpace, do the following:
+ Back up any important data on drive C to another location. All data on drive C is erased during migration.
+ Make sure that the WorkSpace being migrated is at least 12 hours old, to ensure that a snapshot of the user volume has been created. On the **Migrate WorkSpaces** page in the Amazon WorkSpaces console, you can see the time of the last snapshot. Any data created after the last snapshot is lost during migration.
+ To avoid potential data loss, make sure that your users log out of their WorkSpaces and don't log back in until after the migration process is finished. Note that WorkSpaces cannot be migrated when they are in `ADMIN_MAINTENANCE` mode.
+ Make sure that the WorkSpaces you want to migrate have a status of `AVAILABLE`, `STOPPED`, or `ERROR`.
+ Make sure that you have enough IP addresses for the WorkSpaces you are migrating. During migration, new IP addresses will be allocated for the WorkSpaces.
+ If you are using scripts to migrate WorkSpaces, migrate them in batches of no more than 25 WorkSpaces at a time.

## Troubleshooting
<a name="migration_troubleshooting"></a>
+ If your users report missing files after migration, check to see if their user profile files did not get moved during the migration process. You can see which files got moved in `C:\Program Files\Amazon\WorkspacesConfig\Logs\MigrationLogs`. The files that didn't get moved will be located in the `D:\Users\%USERNAME%MMddyyTHHmmss%.NotMigrated` folder. You can manually move any files that didn't get moved automatically. 
+ If you are using the API to migrate WorkSpaces and the migration does not succeed, the target WorkSpace ID returned by the API will not be used, and the WorkSpace will still have the original WorkSpace ID.
+ If a migration does not successfully finish, check the Active Directory to see if it was cleaned up accordingly. You might need to manually remove WorkSpaces that you no longer need.

## How billing is affected
<a name="migration-billing"></a>

During the month in which migration occurs, you are charged prorated amounts for both the new and the original WorkSpaces. For example, if you migrate WorkSpace A to WorkSpace B on May 10, you will be charged for WorkSpace A from May 1 to May 10, and you will be charged for WorkSpace B from May 11 to May 30.

**Note**  
If you are migrating a WorkSpace to a different bundle type (for example, from Performance to Power, or Value to Standard), the size of the root volume (drive C) and the user volume (drive D) might increase during the migration process. If necessary, the root volume increases to match the default root volume size for the new bundle. However, if you had already specified a different size (higher or lower) for the user volume than the default for the original bundle, that same user volume size is retained during the migration process. Otherwise, the migration process uses the larger of the source WorkSpace user volume size and the default user volume size for the new bundle.

## Migrating a WorkSpace
<a name="migration-workspaces"></a>

You can migrate WorkSpaces through the Amazon WorkSpaces console, the AWS CLI or the Amazon WorkSpaces API.

**To migrate a WorkSpace**

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Select your WorkSpace and choose **Actions**, **Migrate WorkSpaces**.

1. Under **Bundles**, select the bundle that you'd like to migrate your WorkSpace to.
**Note**  
To migrate a BYOL WorkSpace from PCoIP to DCV, you must first create a BYOL bundle with the DCV protocol. You can then migrate your PCoIP BYOL WorkSpaces to that DCV BYOL bundle. 

1. Choose **Migrate WorkSpaces**.

   A new WorkSpace with a status of `PENDING` appears in the Amazon WorkSpaces console. When the migration is finished, the original WorkSpace is terminated, and the status of the new WorkSpace is set to `AVAILABLE`.

1. (Optional) To delete any custom bundles and images that you no longer need, see [Delete a custom bundle or image in WorkSpaces Personal](delete_bundle.md).

To migrate WorkSpaces through the AWS CLI, use the [migrate-workspace](https://docs.aws.amazon.com/cli/latest/reference/workspaces/migrate-workspace.html) command. To migrate WorkSpaces through the Amazon WorkSpaces API, see [MigrateWorkSpace](https://docs.aws.amazon.com/workspaces/latest/api/API_MigrateWorkspace.html) in the *Amazon WorkSpaces API Reference*.

# Delete a WorkSpace in WorkSpaces Personal
<a name="delete-workspaces"></a>

When you are finished with a WorkSpace, you can delete it. You can also delete related resources.

**Warning**  
Deleting a WorkSpace is a permanent action and cannot be undone. The WorkSpace user's data does not persist and is destroyed. For help with backing up user data, contact AWS Support.

**Note**  
Simple AD and AD Connector are available to you free of charge to use with WorkSpaces. If there are no WorkSpaces being used with your Simple AD or AD Connector directory for 30 consecutive days, this directory will be automatically deregistered for use with Amazon WorkSpaces, and you will be charged for this directory as per the [AWS Directory Service pricing terms](https://aws.amazon.com/directoryservice/pricing/).  
To delete empty directories, see [Delete a directory for WorkSpaces Personal](delete-workspaces-directory.md). If you delete your Simple AD or AD Connector directory, you can always create a new one when you want to start using WorkSpaces again.

**To delete a WorkSpace**

You can delete a WorkSpace that is in any state except **Suspended**.

1. Open the WorkSpaces console at [https://console.aws.amazon.com/workspaces/v2/home](https://console.aws.amazon.com/workspaces/v2/home).

1. In the navigation pane, choose **WorkSpaces**.

1. Select your WorkSpace and choose **Delete**.

1. When prompted for confirmation, choose **Delete WorkSpace**. It takes approximately 5 minutes to delete a WorkSpace. During deletion, the status of the WorkSpace is set to **Terminating**. When the deletion is complete, the WorkSpace disappears from the console.

1. (Optional) To delete any custom bundles and images that you are finished with, see [Delete a custom bundle or image in WorkSpaces Personal](delete_bundle.md).

1. (Optional) After you delete all WorkSpaces in a directory, you can delete the directory. For more information, see [Delete a directory for WorkSpaces Personal](delete-workspaces-directory.md).

1. (Optional) After you delete all resources in the virtual private cloud (VPC) for your directory, you can delete the VPC and release the Elastic IP address used for the NAT gateway. For more information, see [ Deleting your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#VPC_Deleting) and [ Working with Elastic IP addresses](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-eips.html#WorkWithEIPs) in the *Amazon VPC User Guide*.

**To delete a WorkSpace using the AWS CLI**  
Use the [terminate-workspaces](https://docs.aws.amazon.com/cli/latest/reference/workspaces/terminate-workspaces.html) command.