Why am I unable to create a new WorkSpace?

Last updated: 2020-04-06

I want to create a new WorkSpace with Amazon WorkSpaces, but the process is failing. Why is this happening, and how can I fix this? 

Resolution

The creation of a WorkSpace using either Amazon-provided images or custom images can fail due to a number of causes. Review the following common reasons and troubleshooting steps for WorkSpace creation failures:

Missing IAM policy

By default, AWS Identity and Access Management (IAM) users don't have permissions for Amazon WorkSpaces resources and operations. First, you must create an IAM policy that explicitly grants permissions to a user. Then, attach the policy to the IAM users or groups that require those permissions.

For more information, see Identity and Access Management for Amazon WorkSpaces.

Creating WorkSpaces with encrypted volumes

AWS Key Management Service (AWS KMS) allows you to encrypt the storage volume of a WorkSpace using customer master keys (CMKs). If WorkSpace creation is failing, you might not have the required permissions for AWS KMS.

Verify that your IAM role has the required permissions and that you meet the prerequisites to use an AWS KMS CMK to encrypt your WorkSpaces. For more information, see Encrypted WorkSpaces.

Amazon WorkSpaces quotas

You might have reached the quota for creating WorkSpaces in a specific Region on your account. For more information about quotas and how to request an increase, see Amazon WorkSpaces Quotas.

Antivirus software

Antivirus software might cause failures when creating a WorkSpace from a custom image. Disable or uninstall any antivirus software. Then, try again to create a new WorkSpace.

Incorrect AD Connector service account password

First, reset the AD Connector account password. Then, update the service account credentials in AWS Directory Service. Try again to create a new WorkSpace.

AD Connector security groups are deleted or changed

When a directory is created and registered for Workspaces, two security groups are created. The security group names are as follows, with your directory’s ID in the place of directoryID.

  • directoryID_workspacesMembers
  • directoryID_controllers

Changes to either security group name might prevent the WorkSpace from communicating with the directory when you create a new WorkSpace. This communication error can lead to issues like domain join failures.

To fix this issue, update the security group to allow inbound traffic from the on-premises domain controllers on the required ports.

User profile already exists in C:\

If you create a WorkSpace from a custom image, creation fails if a user profile for the new user already exists in C:\. This happens if you launch a Remote Desktop Protocol (RDP) session from a WorkSpace with a specific user, and then create a custom image named Image_1 for that same user.

Example: You have a WorkSpace for user1. You launch an RDP session in this WorkSpace from user2. Then, you create a custom image from this WorkSpace named Image_1 for user2. The WorkSpace creation fails, as a user profile for user2 already exists in C:\ of the WorkSpace where Image_1 was created.

To fix this issue, delete any additional user profiles in C:\ from the WorkSpace that you are using to create an image. Be sure to also remove any remnants of the additional users in the registry. Follow these steps:

1.    Access the WorkSpace that was used to create the image for the custom bundle.

Note: If this WorkSpace no longer exists, access a WorkSpace that successfully launched from the custom bundle.

2.    Open the Start menu, and then expand Windows System. Open the context (right-click) menu for This PC, and then choose Properties

3.    Choose Advanced system settings from the navigation pane.

4.    From the Advanced tab, for User Profiles, choose Settings.

5.    Important: Remove only those users that belong to your domain (<domain>\UserName).

Select the user profile, and then choose Delete.

6.    Navigate to the C:\Users folder to confirm that the user folders are removed. The Administrator and Public folders should remain.

Note: The C:\ drive is hidden by default. Open File Explorer, and then enter C:\ in the address bar to display the folders.

7.    Verify that the removed user’s security identifier (SID) is removed from the registry. Open the Start menu, and then enter cmd to open a command prompt. Run the following command:

wmic useraccount get name,sid

8.    Note the SID for the removed user.

9.    Open the Start menu, and then enter regedit to open the Registry Editor. Navigate to the following location: HKLM\Software\Microsoft\WindowsNT\CurrentVersion\ProfileList

If you don’t see a key with the SID from step 8, then no further action is needed. If you find a key with the SID, then proceed to the next step.

10.    Remove the key, and then look for the SID in the following registry location: HKLM\Software\Microsoft\WindowsNT\CurrentVersion\ProfileGuid

If you don’t see a key with the SID from step 8, then no further action is needed. If you find a key with the SID, then remove the key.

You can now create an image of this WorkSpace for your custom bundle that will successfully launch for the user that was removed in this process.

Domain join errors

When a directory or AD Connector is created, two subnets are chosen for high availability. Communication between the directory and the WorkSpace’s subnets can fail due to a VPN issue or a firewall blocking the necessary ports. To troubleshoot domain join errors, see Why am I getting a domain join error when I create a WorkSpace?


Did this article help you?

Anything we could improve?


Need more help?