Why can't I create a new WorkSpace?

5 minute read
0

I want to create a new WorkSpace with Amazon WorkSpaces, but the process fails.

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. So, you must first 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 WorkSpaces.

Creating WorkSpaces with encrypted volumes

AWS Key Management Service (AWS KMS) allows you to encrypt the storage volume of a WorkSpace using AWS KMS keys (KMS keys). If WorkSpace creation fails, then 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 key to encrypt your WorkSpaces. For more information, see Encrypted WorkSpaces.

WorkSpaces quotas

You might have reached the quota for creating WorkSpaces in a specific AWS 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. Deactivate 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 such as 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 (on the Microsoft website).

User profile already exists in C:\

If you create a WorkSpace from a custom image, then creation fails if the new user's profile already exists in C:\ of that image. This happens if you launch a Remote Desktop Protocol (RDP) session to the user's WorkSpace and create a custom image from that WorkSpace. Then, you deploy the custom image for that user.

For example, suppose that you launch an RDP session to a WorkSpace from user1. Then, you use this WorkSpace to create a custom image, and you name the image Image_1. The WorkSpace creation from Image_1 fails because a user profile for user1 already exists in C:\ of the WorkSpace, where Image_1 was created from.

To fix this issue, delete any additional user profiles in C:\ from the WorkSpace that you're 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, then 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\Windows NT\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\Windows NT\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 successfully launches 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 How can I troubleshoot a WorkSpace that fails to join a domain?

Related information

How do I troubleshoot WorkSpaces image creation issues?

AWS OFFICIAL
AWS OFFICIALUpdated 2 years ago