Troubleshooting Amazon WorkSpaces Issues - Amazon WorkSpaces

Troubleshooting Amazon WorkSpaces Issues

The following information can help you troubleshoot issues with your WorkSpaces.

Enabling Advanced Logging

To help troubleshoot issues that your users might experience, you can enable advanced logging on any Amazon WorkSpaces client. Advanced logging is enabled for every subsequent client session until you disable it.

Advanced logging generates log files that contain diagnostic information and debugging-level details, including verbose performance data. For the 1.0+ and 2.0+ clients, these advanced logging files are automatically uploaded to a database in AWS.

Note

To have AWS review the log files that are generated by advanced logging and to receive technical support for issues with your WorkSpaces clients, contact AWS Support. For more information, see AWS Support Center.

Windows clients

    The Windows client logs are stored in the following location:

    %LOCALAPPDATA%\Amazon Web Services\Amazon WorkSpaces\logs

    To enable advanced logging for Windows clients

    1. Close the Amazon WorkSpaces client.

    2. Open the Command Prompt app.

    3. Launch the WorkSpaces client with the -l3 flag.

      c:

      cd "C:\Program Files (x86)\Amazon Web Services, Inc\Amazon WorkSpaces"

      workspaces.exe -l3

    macOS clients

      The macOS client logs are stored in the following location:

      ~/Library/"Application Support"/"Amazon Web Services"/"Amazon WorkSpaces"/logs

      To enable advanced logging for macOS clients

      1. Close the Amazon WorkSpaces client.

      2. Open Terminal.

      3. Run the following command.

        open -a workspaces --args -l3

      Linux clients

        The Linux client logs are stored in the following location:

        ~/.local/share/Amazon Web Services/Amazon WorkSpaces/logs

        To enable advanced logging for Linux clients

        1. Close the Amazon WorkSpaces client.

        2. Open Terminal.

        3. Run the following command.

          /opt/workspacesclient/workspacesclient -l3

        1. Open the WorkSpaces client.

        2. Choose the gear icon in the upper-right corner of the client application.

        3. Choose Advanced Settings.

        4. Select the Enable Advanced Logging check box.

        5. Choose Save.

        The Windows client logs are stored in the following location:

        %LOCALAPPDATA%\Amazon Web Services\Amazon WorkSpaces\1.0\Logs

        The macOS client logs are stored in the following location:

        ~/Library/Logs/Amazon Web Services/Amazon WorkSpaces/1.0

        Troubleshooting for Specific Issues

        The following information can help you troubleshoot specific issues with your WorkSpaces.

        Issues

        I can't create an Amazon Linux WorkSpace because there are non-valid characters in the user name

        For Amazon Linux WorkSpaces, user names:

        • Can contain a maximum of 20 characters

        • Can contain letters, spaces, and numbers that are representable in UTF-8

        • Can include the following special characters: _.-#

        • Cannot begin with a dash symbol (-) as the first character of the user name

        Note

        These limitations do not apply to Windows WorkSpaces. Windows WorkSpaces support the @ and - symbols for all characters in the user name.

        I changed the shell for my Amazon Linux WorkSpace and now I can't provision a PCoIP session

        To override the default shell for Linux WorkSpaces, see Override the Default Shell for Amazon Linux WorkSpaces.

        My Amazon Linux WorkSpaces won't start

        Starting July 20, 2020, Amazon Linux WorkSpaces will be using new license certificates. These new certificates are compatible only with versions 2.14.1.1, 2.14.7, and 2.14.9 of the PCoIP agent.

        If you're using an unsupported version of the PCoIP agent, you must upgrade it to the latest version (2.14.9), which has the latest fixes and performance improvements that are compatible with the new certificates. If you don't make these upgrades by July 20, session provisioning for your Linux WorkSpaces will fail and your end users won't be able to connect to their WorkSpaces.

        To upgrade your PCoIP agent to the latest version

        1. Open the Amazon WorkSpaces console at https://console.aws.amazon.com/workspaces/.

        2. In the navigation pane, choose WorkSpaces.

        3. Select your Linux WorkSpace, and reboot it by choosing Actions, Reboot WorkSpaces. If the WorkSpace status is STOPPED, you must choose Actions, Start WorkSpaces first and wait until its status is AVAILABLE before you can reboot it.

        4. After your WorkSpace has rebooted and its status is AVAILABLE, we recommend that you change the status of the WorkSpace to ADMIN_MAINTENANCE while you are performing this upgrade. When you are finished, change the status of the WorkSpace to AVAILABLE. For more information about ADMIN_MAINTENANCE mode, see Manual Maintenance.

          To change the status of a WorkSpace to ADMIN_MAINTENANCE, do the following:

          1. Select the WorkSpace and choose Actions, Modify WorkSpace.

          2. Choose Modify State.

          3. For Intended State, select ADMIN_MAINTENANCE.

          4. Choose Modify.

        5. Connect to your Linux WorkSpace through SSH. For more information, see Enable SSH Connections for Your Linux WorkSpaces.

        6. To update the PCoIP agent, run the following command:

          sudo yum --enablerepo=pcoip-stable install pcoip-agent-standard-2.14.9
        7. To verify the agent version and to confirm that the update succeeded, run the following command:

          rpm -q pcoip-agent-standard

          The verification command should produce following result:

          pcoip-agent-standard-2.14.9-27877.el7.x86_64
        8. Disconnect from the WorkSpace and reboot it again.

        9. If you set the status of the WorkSpace to ADMIN_MAINTENANCE in Step 4, repeat Step 4 and set Intended State to AVAILABLE.

        If your Linux WorkSpace still fails to start after you upgrade the PCoIP agent, contact AWS Support.

        Launching WorkSpaces in my connected directory often fails

        Verify that the two DNS servers or domain controllers in your on-premises directory are accessible from each of the subnets that you specified when you connected to your directory. You can verify this connectivity by launching an Amazon EC2 instance in each subnet and joining the instance to your directory using the IP addresses of the two DNS servers.

        Launching WorkSpaces fails with an internal error

        Check whether your subnets are configured to automatically assign IPv6 addresses to instances launched in the subnet. To check this setting, open the Amazon VPC console, select your subnet, and choose Subnet Actions, Modify auto-assign IP settings. If this setting is enabled, you cannot launch WorkSpaces using the Performance or Graphics bundles. Instead, disable this setting and specify IPv6 addresses manually when you launch your instances.

        My users can't connect to a Windows WorkSpace with an interactive logon banner

        If an interactive logon message has been implemented to display a logon banner, this prevents users from being able to access their Windows WorkSpaces. The interactive logon message Group Policy setting is not currently supported by Amazon WorkSpaces. Move the WorkSpaces to an organizational unit (OU) where the Interactive logon: Message text for users attempting to log on Group Policy isn’t applied.

        My users can't connect to a Windows WorkSpace

        My users receive the following error when they try to connect to their Windows WorkSpaces:

        "An error occurred while launching your WorkSpace. Please try again."

        This error often occurs when the WorkSpace can't load the Windows desktop using PCoIP. Check the following:

        • This message appears if the PCoIP Standard Agent for Windows service is not running. Connect using RDP to verify that the service is running, that it's set to start automatically, and that it can communicate over the management interface (eth0).

        • If the PCoIP agent was uninstalled, reboot the WorkSpace through the Amazon WorkSpaces console to reinstall it automatically.

        • You might also receive this error on the Amazon WorkSpaces client after a long delay if the WorkSpaces security group was modified to restrict outbound traffic. Restricting outbound traffic prevents Windows from communicating with your directory controllers for login. Verify that your security groups allow your WorkSpaces to communicate with your directory controllers on all required ports over the primary network interface.

        Another cause of this error is related to the User Rights Assignment Group Policy. If the following group policy is incorrectly configured, it prevents users from being able to access their Windows WorkSpaces:

        Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

        • Incorrect policy:

          Policy: Access this computer from the network

          Setting: Domain name\Domain Computers

          Winning GPO: Allow File Access

        • Correct policy:

          Policy: Access this computer from the network

          Setting: Domain name\Domain Users

          Winning GPO: Allow File Access

        Note

        This policy setting should be applied to Domain Users instead of Domain Computers.

        For more information, see Access this computer from the network - security policy setting and Configure security policy settings in the Microsoft Windows documentation.

        My users are having issues when they try to log on to WorkSpaces from WorkSpaces Web Access

        Amazon WorkSpaces relies on a specific logon screen configuration to enable users to successfully log on from their Web Access client.

        To enable Web Access users to log on to their WorkSpaces, you must configure a Group Policy setting and three Security Policy settings. If these settings are not correctly configured, users might experience long logon times or black screens when they try to log on to their WorkSpaces. To configure these settings, see Enable and Configure Amazon WorkSpaces Web Access.

        Important

        Beginning October 1, 2020, customers will no longer be able to use the Amazon WorkSpaces Web Access client to connect to Windows 7 custom WorkSpaces or to Windows 7 Bring Your Own License (BYOL) WorkSpaces.

        The Amazon WorkSpaces client displays a gray "Loading..." screen for a while before returning to the login screen. No other error message appears.

        This behavior usually indicates that the WorkSpaces client can authenticate over port 443, but can't establish a streaming connection over port 4172. This situation can occur when network prerequisites aren't met. Issues on the client side often cause the network check in the bottom-right corner of the client to fail. To see which health checks are failing, choose the network check icon (typically a red triangle with an exclamation point).

        Note

        The most common cause of this problem is a client-side firewall or proxy preventing access over port 4172 (TCP and UDP). If this health check fails, check your local firewall settings.

        If the network check passes, there might be a problem with the network configuration of the WorkSpace. For example, a Windows Firewall rule might block port UDP 4172 on the management interface. Connect to the WorkSpace using a Remote Desktop Protocol (RDP) client to verify that the WorkSpace meets the necessary port requirements.

        My users receive the message "WorkSpace Status: Unhealthy. We were unable to connect you to your WorkSpace. Please try again in a few minutes."

        This error usually indicates the SkyLightWorkSpacesConfigService service isn't responding to health checks.

        If you just rebooted or started your WorkSpace, wait a few minutes, and then try again.

        If the WorkSpace has been running for some time and you still see this error, connect using RDP to verify that the SkyLightWorkSpacesConfigService service:

        • Is running.

        • Is set to start automatically.

        • Can communicate over the management interface (eth0).

        • Isn't blocked by any third-party antivirus software.

        My users receive the message "This device is not authorized to access the WorkSpace. Please contact your administrator for assistance."

        This error indicates that IP access control groups are configured on the WorkSpace directory, but the client IP address isn't whitelisted.

        Check the settings on your directory. Confirm that the public IP address the user is connecting from allows access to the WorkSpace.

        The WorkSpaces client gives my users a network error, but they are able to use other network-enabled apps on their devices

        The WorkSpaces client applications rely on access to resources in the AWS Cloud, and require a connection that provides at least 1 Mbps download bandwidth. If a device has an intermittent connection to the network, the WorkSpaces client application might report an issue with the network.

        Amazon WorkSpaces enforces the use of digital certificates issued by Amazon Trust Services, as of May 2018. Amazon Trust Services is already a trusted Root CA on the operating systems that are supported by Amazon WorkSpaces. If the Root CA list for the operating system is not up to date, the device cannot connect to WorkSpaces and the client gives a network error.

        To recognize connection issues due to certificate failures

        • PCoIP zero clients — The following error message is displayed.

          Failed to connect. The server provided a certificate that is invalid. See below for details:
          - The supplied certificate is invalid due to timestamp
          - The supplied certificate is not rooted in the devices local certificate store
        • Other clients — The health checks fail with a red warning triangle for Internet.

        Windows Client Application

        Use one of the following solutions for certificate failures.

        Solution 1: Update the client application

        Download and install the latest Windows client application from Amazon WorkSpaces Client Downloads. During installation, the client application ensures that your operating system trusts certificates issued by Amazon Trust Services.

        Solution 2: Add Amazon Trust Services to the local Root CA list

        1. Open https://www.amazontrust.com/repository/.

        2. Download the Starfield certificate in DER format (2b071c59a0a0ae76b0eadb2bad23bad4580b69c3601b630c2eaf0613afa83f92).

        3. Open the Microsoft Management Console. (From the Command Prompt, run mmc.)

        4. Choose File, Add/Remove Snap-in, Certificates, Add.

        5. On the Certificates snap-in page, select Computer account and choose Next. Keep the default, Local computer. Choose Finish. Choose OK.

        6. Expand Certificates (Local Computer) and select Trusted Root Certification Authorities. Choose Action, All Tasks, Import.

        7. Follow the wizard to import the certificate that you downloaded.

        8. Exit and restart the WorkSpaces client application.

        Solution 3: Deploy Amazon Trust Services as a trusted CA using Group Policy

        Add the Starfield certificate to the trusted Root CAs for the domain using Group Policy. For more information, see Use Policy to Distribute Certificates.

        PCoIP Zero Clients

        To connect directly to a WorkSpace using firmware version 6.0 or later, download and install the certificate issued by Amazon Trust Services.

        To add Amazon Trust Services as a trusted Root CA

        1. Open https://certs.secureserver.net/repository/.

        2. Download the certificate under Starfield Certificate Chain with the thumbprint 14 65 FA 20 53 97 B8 76 FA A6 F0 A9 95 8E 55 90 E4 0F CC 7F AA 4F B7 C2 C8 67 75 21 FB 5F B6 58.

        3. Upload the certificate to the zero client. For more information, see Uploading Certificates in the Teradici documentation.

        Other Client Applications

        Add the Starfield certificate (2b071c59a0a0ae76b0eadb2bad23bad4580b69c3601b630c2eaf0613afa83f92) from Amazon Trust Services. For more information about how to add a Root CA, see the following documentation:

        My WorkSpace users see the following error message: "Device can't connect to the registration service. Check your network settings."

        When a registration service failure occurs, your WorkSpace users might see the following error message on the Connection Health Check page: "Your device is not able to connect to the WorkSpaces Registration service. You will not be able to register your device with WorkSpaces. Please check your network settings."

        This error occurs when the WorkSpaces client application can't reach the registration service. Typically, this happens when the WorkSpaces directory has been deleted. To resolve this error, make sure that the registration code is valid and corresponds to a running directory in the AWS Cloud.

        My PCoIP zero client users are receiving the error "The supplied certificate is invalid due to timestamp"

        If Network Time Protocol (NTP) isn't enabled in Teradici, your PCoIP zero client users might receive certificate failure errors. To set up NTP, see Set Up PCoIP Zero Client for WorkSpaces.

        My users skipped updating their Windows or macOS client applications and aren't getting prompted to install the latest version

        When users skip updates to the Amazon WorkSpaces Windows client application, the SkipThisVersion registry key gets set, and they are no longer prompted to update their clients when a new version of the client is released. To update to the latest version, you can edit the registry as described in Update the WorkSpaces Windows Client Application to a Newer Version in the Amazon WorkSpaces User Guide. You can also run the following PowerShell command:

        Remove-ItemProperty -Path "HKCU:\Software\Amazon Web Services. LLC\Amazon WorkSpaces\WinSparkle" -Name "SkipThisVersion"

        When users skip updates to the Amazon WorkSpaces macOS client application, the SUSkippedVersion preference gets set, and they are no longer prompted to update their clients when a new version of the client is released. To update to the latest version, you can reset this preference as described in Update the WorkSpaces macOS Client Application to a Newer Version in the Amazon WorkSpaces User Guide.

        My users are unable to install the Android client application on their Chromebooks

        Version 2.4.13 is the final release of the Amazon WorkSpaces Chromebook client application. Because Google is phasing out support for Chrome Apps, there will be no further updates to the WorkSpaces Chromebook client application, and its use is unsupported.

        For Chromebooks that support installing Android applications, we recommend using the Amazon WorkSpaces Android client application instead.

        In some cases, you might need to enable your users' Chromebooks to install Android applications. For more information, see Set Up Android for Chromebooks.

        My users aren't receiving invitation emails or password reset emails

        Users do not automatically receive welcome or password reset emails for WorkSpaces that were created using AD Connector.

        To manually send welcome emails to these users, see Send an Invitation Email.

        To reset user passwords, see Set Up Active Directory Administration Tools for Amazon WorkSpaces.

        My users don't see the Forgot password? option on the client login screen

        If you're using AD Connector, your users won't be able to reset their own passwords. (The Forgot password? option on the WorkSpaces client application login screen won't be available.) For information about how to reset user passwords, see Set Up Active Directory Administration Tools for Amazon WorkSpaces.

        I receive the message "The system administrator has set policies to prevent this installation" when I try to install applications on a Windows WorkSpace

        You can address this issue by modifying the Windows Installer Group Policy setting. To deploy this policy to multiple WorkSpaces in your directory, apply this setting to a Group Policy object that is linked to the WorkSpaces organizational unit (OU) from a domain-joined EC2 instance. If you are using AD Connector, you can make these changes from a domain controller. For more information about using the Active Directory administration tools to work with Group Policy objects, see Installing the Active Directory Administration Tools in the AWS Directory Service Administration Guide.

        The following procedure shows how to configure the Windows Installer setting for the Amazon WorkSpaces Group Policy object.

        1. Make sure that the most recent Amazon WorkSpaces Group Policy administrative template is installed in your domain.

        2. Open the Group Policy Management tool on your Windows WorkSpace client and navigate to and select the WorkSpaces Group Policy object for your WorkSpaces machine accounts. From the main menu, choose Action, Edit.

        3. In the Group Policy Management Editor, choose Computer Configuration, Policies, Administrative Templates, Classic Administrative Templates, Windows Components, Windows Installer.

        4. Open the Turn Off Windows Installer setting.

        5. In the Turn Off Windows Installer dialog box, change Not Configured to Enabled, and then set Disable Windows Installer to Never.

        6. Choose OK.

        7. 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).

          • From an administrative command prompt, enter gpupdate /force.

        No WorkSpaces in my directory can connect to the internet

        WorkSpaces cannot communicate with the internet by default. You must explicitly provide internet access. For more information, see Provide Internet Access from Your WorkSpace.

        My WorkSpace has lost its internet access

        If your WorkSpace has lost access to the internet and you can't connect to the WorkSpace by using RDP, this issue is probably caused by the loss of the public IP address for the WorkSpace. If you have enabled automatic assignment of Elastic IP addresses at the directory level, an Elastic IP address (from the Amazon-provided pool) is assigned to your WorkSpace when it is launched. However, if you associate an Elastic IP address that you own to a WorkSpace, and then you later disassociate that Elastic IP address from the WorkSpace, the WorkSpace loses its public IP address, and it doesn't automatically get a new one from the Amazon-provided pool.

        To associate a new public IP address from the Amazon-provided pool with the WorkSpace, you must rebuild the WorkSpace. If you don't want to rebuild the WorkSpace, you must associate another Elastic IP address that you own to the WorkSpace.

        We recommend that you not modify the elastic network interface of a WorkSpace after the WorkSpace is launched. After an Elastic IP address has been assigned to a WorkSpace, the WorkSpace retains the same public IP address (unless the WorkSpace is rebuilt, in which case it gets a new public IP address).

        I receive a "DNS unavailable" error when I try to connect to my on-premises directory

        You receive an error message similar to the following when connecting to your on-premises directory.

        DNS unavailable (TCP port 53) for IP: dns-ip-address

        AD Connector must be able to communicate with your on-premises DNS servers via TCP and UDP over port 53. Verify that your security groups and on-premises firewalls allow TCP and UDP communication over this port.

        I receive a "Connectivity issues detected" error when I try to connect to my on-premises directory

        You receive an error message similar to the following when connecting to your on-premises directory.

        Connectivity issues detected: LDAP unavailable (TCP port 389) for IP: ip-address
        Kerberos/authentication unavailable (TCP port 88) for IP: ip-address
        Please ensure that the listed ports are available and retry the operation.

        AD Connector must be able to communicate with your on-premises domain controllers via TCP and UDP over the following ports. Verify that your security groups and on-premises firewalls allow TCP and UDP communication over these ports:

        • 88 (Kerberos)

        • 389 (LDAP)

        I receive an "SRV record" error when I try to connect to my on-premises directory

        You receive an error message similar to one or more of the following when connecting to your on-premises directory.

        SRV record for LDAP does not exist for IP: dns-ip-address
        
        SRV record for Kerberos does not exist for IP: dns-ip-address

        AD Connector needs to obtain the _ldap._tcp.dns-domain-name and _kerberos._tcp.dns-domain-name SRV records when connecting to your directory. You get this error if the service cannot obtain these records from the DNS servers that you specified when connecting to your directory. Make sure that your DNS servers contain these SRV records. For more information, see SRV Resource Records on Microsoft TechNet.

        My Windows WorkSpace goes to sleep when it's left idle

        To resolve this issue, connect to the WorkSpace and change the power plan to High performance by using the following procedure:

        1. From the WorkSpace, open Control Panel, then choose Hardware and Sound.

        2. Under Power Options, choose Choose a power plan.

        3. In the Choose or customize a power plan pane, choose the High performance power plan. If this plan isn't visible, choose the arrow to the right of Show additional plans to display it.

        If the preceding steps do not solve the issue, do the following:

        1. In the Choose or customize a power plan pane, choose the Change plan settings link to the right of the High performance power plan, then choose the Change advanced power settings link.

        2. In the Power Options dialog box, in the list of settings, choose the plus sign to the left of Hard disk to display the relevant settings.

        3. Verify that the Turn off hard disk after value for Plugged in is greater than the value for On battery (the default value is 20 minutes).

        4. Choose the plus sign to the left of PCI Express, and do the same for Link State Power Management.

        5. Verify that the Link State Power Management settings are Off.

        6. Choose OK (or Apply if you changed any settings) to close the dialog box.

        7. In the Change settings for the plan pane, if you changed any settings, choose Save changes.

        One of my WorkSpaces has a state of "Unhealthy"

        The Amazon WorkSpaces service periodically sends status requests to a WorkSpace. A WorkSpace is marked Unhealthy when it fails to respond to these requests. Common causes for this problem are:

        • An application on the WorkSpace is blocking network ports, which prevents the WorkSpace from responding to the status request.

        • High CPU utilization is preventing the WorkSpace from responding to the status request in a timely manner.

        • The computer name of the WorkSpace has been changed. This prevents a secure channel from being established between Amazon WorkSpaces and the WorkSpace.

        You can attempt to correct the situation using the following methods:

        • Reboot the WorkSpace from the Amazon WorkSpaces console.

        • Connect to the unhealthy WorkSpace using the following procedure, which should be used only for troubleshooting purposes:

          1. Connect to an operational WorkSpace in the same directory as the unhealthy WorkSpace.

          2. From the operational WorkSpace, use Remote Desktop Protocol (RDP) to connect to the unhealthy WorkSpace using the IP address of the unhealthy WorkSpace. Depending on the extent of the problem, you might not be able to connect to the unhealthy WorkSpace.

          3. On the unhealthy WorkSpace, confirm that the minimum port requirements are met.

        • Rebuild the WorkSpace from the Amazon WorkSpaces console. Because rebuilding a WorkSpace can potentially cause a loss of data, this option should only be used if all other attempts to correct the problem have been unsuccessful.

        My WorkSpace is unexpectedly crashing or rebooting

        If your WorkSpace is repeatedly crashing or rebooting and your error logs or crash dumps are pointing to problems with spacedeskHookKmode.sys or spacedeskHookUmode.dll, or if you're receiving the following error messages, you might need to disable Web Access to the WorkSpace:

        The kernel power manager has initiated a shutdown transition.
        Shutdown reason: Kernel API
                    
        The computer has rebooted from a bugcheck.
                    
        Note

        You should disable Web Access only if you aren't allowing your users to use Web Access.

        To disable Web Access to the WorkSpace, you must set a group policy and modify two registry settings. For information about using the Active Directory administration tools to work with Group Policy Objects, see Installing the Active Directory Administration Tools in the AWS Directory Service Administration Guide.

        Step 1: Set a Group Policy to disable Web Access at the directory level

        You can make these changes either from the machine that you use to administer the domain, or from a domain controller.

        1. Open the Group Policy Management Editor (gpmc.msc) and locate the Group Policy Object (GPO) policy at the domain controller level of your directory.

        2. Choose Action, Edit.

        3. Navigate to the following setting:

          Computer Configuration\Windows Settings\Security Settings\System Services\STXHD Hosted Application Service

        4. In the STXHD Hosted Application Service Properties dialog box, on the Security Policy Setting tab, select the Define this policy setting check box.

        5. Under Select Service Startup Mode, select Disabled.

        6. Choose OK.

        7. Prevent the machine from rebooting until you have finished editing the registry (Step 2).

        Step 2: Edit the Registry to disable Web Access

        We recommend that you push out these registry changes through GPO.

        1. Set the following registry key value to 1 (enabled):

          KeyPath = HKEY_LOCAL_MACHINE\SOFTWARE\Amazon\WorkSpacesConfig\update-webaccess.ps1

          KeyName = RebootCount

          KeyType = DWORD

          KeyValue = 1

        2. Set the following registry key value to 4 (disabled):

          KeyPath = HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\spacedeskHookKmode

          KeyName = Start

          KeyType = DWORD

          KeyValue = 4

        3. Reboot the machine.

        The same username has more than one WorkSpace, but the user can log in to only one of the WorkSpaces

        If you delete a user in Active Directory (AD) without first deleting their WorkSpace and then you add the user back to Active Directory and create a new WorkSpace for that user, the same username will now have two WorkSpaces in the same directory. However, if the user tries to connect to their original WorkSpace, they will receive the following error:

        "Unrecognized user. No WorkSpace found under your username. Contact your administrator to request one."

        Additionally, searches for the username in the Amazon WorkSpaces console return only the new WorkSpace, even though both WorkSpaces still exist. (You can find the original WorkSpace by searching for the WorkSpace ID instead of the username.)

        This behavior can also occur if you rename a user in Active Directory without first deleting their WorkSpace. If you then change their username back to the original username and create a new WorkSpace for the user, the same username will have two WorkSpaces in the directory.

        This problem occurs because Active Directory uses the user's security identifier (SID), rather than the username, to uniquely identify the user. When a user is deleted and recreated in Active Directory, the user is assigned a new SID, even if their username remains the same. During searches for a username, the Amazon WorkSpaces console uses the SID to search Active Directory for matches. The Amazon WorkSpaces clients also use the SID to identify users when they are connecting to WorkSpaces.

        To resolve this problem, do one of the following:

        • If this problem occurred because the user was deleted and recreated in Active Directory, you might be able to restore the original deleted user object if you have enabled the Recycle Bin feature in Active Directory. If you're able to restore the original user object, make sure the user can connect to their original WorkSpace. If they can, you can delete the new WorkSpace after manually backing up and transferring any user data from the new WorkSpace to the original WorkSpace (if needed).

        • If you can't restore the original user object, delete the user's original WorkSpace. The user should be able to connect to and use their new WorkSpace instead. Be sure to manually back up and transfer any user data from the original WorkSpace to the new WorkSpace.

          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.

        I'm having trouble using Docker with Amazon WorkSpaces

        Nested virtualization (including the use of Docker) is not supported on Amazon WorkSpaces for Windows or Linux. For more information, see the Docker documentation.

        I receive ThrottlingException errors to some of my API calls

        The default allowed rate for Amazon WorkSpaces API calls is a constant rate of two API calls per second, with a maximum allowed "burst" rate of five API calls per second. The following table shows how the burst rate limit works for API requests.

        Second Number of Requests Sent Net Requests Allowed Details

        1

        0

        5

        During the first second (second 1), five requests are allowed, up to the burst rate maximum of five calls per second.

        2

        2

        5

        Because two or fewer calls were issued in second 1, the full burst capacity of five calls is still available.

        3

        5

        5

        Because only two calls were issued in second 2, the full burst capacity of five calls is still available.

        4

        2

        2

        Because the full burst capacity was used in second 3, only the constant rate of two calls per second is available.

        5

        3

        2

        Because there is no remaining burst capacity, only two calls are allowed at this time. This means that one of the three API calls is throttled. The one throttled call will respond after a short delay.

        6

        0

        1

        Because one of the calls from second 5 is being retried in second 6, there is capacity for only one additional call in second 6 because of the constant rate limit of two calls per second.

        7

        0

        3

        Now that there are no longer any throttled API calls in the queue, the rate limit continues to increase, up to the burst rate limit of five calls.

        8

        0

        5

        Because no calls were issued in second 7, the maximum number of requests is allowed.

        9

        0

        5

        Even though no calls were issued in second 8, the rate limit does not increase above five.