

# Manage directories for WorkSpaces Personal
<a name="manage-workspaces-directory"></a>

WorkSpaces uses a directory to store and manage information for your WorkSpaces and users. You can use one of the following options:
+ AD Connector — Use your existing on-premises Microsoft Active Directory. Users can sign into their WorkSpaces using their on-premises credentials and access on-premises resources from their WorkSpaces.
+ AWS Managed Microsoft AD — Create a Microsoft Active Directory hosted on AWS.
+ Simple AD — Create a directory that is compatible with Microsoft Active Directory, powered by Samba 4, and hosted on AWS.
+ Cross trust — Create a trust relationship between your AWS Managed Microsoft AD directory and your on-premises domain.
+ Microsoft Entra ID — Create a directory that uses Microsoft Entra ID as its identity source (through IAM Identity Center). Personal WorkSpaces in the directory are joined using Microsoft Entra's native authentication and are enrolled into Microsoft Intune through Microsoft Windows Autopilot user-driven mode. Directories using Microsoft Entra ID only support Windows 10 and 11 Bring Your Own Licenses WorkSpaces.
+ Custom — Create a directory that use an identity provider of your choice (through IAM Identity Center). WorkSpaces in the directory are managed using the device management solution of your choice such as JumpCloud. Directories using custom identity providers only support Windows 10 and 11 Bring Your Own Licenses WorkSpaces.

For tutorials that demonstrate how to set up these directories and launch WorkSpaces, see [Create a directory for WorkSpaces Personal](launch-workspaces-tutorials.md).

**Tip**  
For a detailed exploration of directory and virtual private cloud (VPC) design considerations for various deployment scenarios, see [Best Practices for Deploying Amazon WorkSpaces](https://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/best-practices-deploying-amazon-workspaces.html).

After you create a directory, you'll perform most directory administration tasks using tools such as the Active Directory Administration Tools. You can perform some directory administration tasks using the WorkSpaces console and other tasks using Group Policy. For more information about managing users and groups, see [Manage users in WorkSpaces Personal](manage-workspaces-users.md) and [Set up Active Directory Administration Tools for WorkSpaces Personal](directory_administration.md).

**Note**  
Shared directories are not currently supported for use with Amazon WorkSpaces.
If you configure your AWS Managed Microsoft AD directory for multi-Region replication, only the directory in the primary Region can be registered for use with Amazon WorkSpaces. Attempts to register the directory in a replicated Region for use with Amazon WorkSpaces will fail. Multi-Region replication with AWS Managed Microsoft AD isn't supported for use with Amazon WorkSpaces within replicated Regions.
Simple AD and AD Connector are made 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.

**Topics**
+ [Register an existing Directory Service directory with WorkSpaces Personal](register-deregister-directory.md)
+ [Select an organizational unit for WorkSpaces Personal](select-ou.md)
+ [Configure automatic public IP addresses for WorkSpaces Personal](automatic-assignment.md)
+ [Control device access for WorkSpaces Personal](control-device-access.md)
+ [Manage local administrator permissions for WorkSpaces Personal](local-admin-setting.md)
+ [Update the AD Connector account (AD Connector) for WorkSpaces Personal](connect-account.md)
+ [Multi-factor authentication (AD Connector) for WorkSpaces Personal](connect-mfa.md)
+ [Create a directory for WorkSpaces Personal](launch-workspaces-tutorials.md)
+ [Update DNS servers for WorkSpaces Personal](update-dns-server.md)
+ [Delete a directory for WorkSpaces Personal](delete-workspaces-directory.md)
+ [Set up Active Directory Administration Tools for WorkSpaces Personal](directory_administration.md)

# Register an existing Directory Service directory with WorkSpaces Personal
<a name="register-deregister-directory"></a>

To allow WorkSpaces to use an existing Directory Service directory, you must register it with WorkSpaces. After you register a directory, you can launch WorkSpaces in the directory.

**Requirements:** To register a directory for use with WorkSpaces, it must meet the following requirement:
+ If you're using AWS Managed Microsoft AD or Simple AD, your directory can be in a dedicated private subnet, as long as the directory has access to the VPC where the WorkSpaces are located.
+ For more information about directory and VPC design, see the [https://d1.awsstatic.com/whitepapers/Best-Practices-for-Deploying-Amazon-WorkSpaces.pdf](https://d1.awsstatic.com/whitepapers/Best-Practices-for-Deploying-Amazon-WorkSpaces.pdf) whitepaper.

**Note**  
Simple AD and AD Connector are made 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 register an existing AWS Directory Service directory**

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. Choose **Create directory**.

1. On the **Create directory** page, for **WorkSpaces type** choose **Personal**. For **WorkSpace device management**, choose **AWS Directory Service**.

1. Select the directory you want to register in the **Directories in Directory Service** table

1. Select two subnets of your VPC that are not from the same Availability Zone. These subnets will be used to launch your WorkSpaces. For more information, see [Availability Zones for WorkSpaces Personal](azs-workspaces.md).
**Note**  
If you do not know which subnets to choose, select **No Preference**.

1. For **Enable Self Service Permissions**, choose **Yes** to enable your users to rebuild their WorkSpaces, change volume size, compute type and running mode. Enabling may impact how much you pay for Amazon WorkSpaces. Choose **No** otherwise.

1. Choose **Register**. Initially the value of **Registered** is `REGISTERING`. After registration is complete, the value is `Yes`.

After you've registered the Directory Service directory, you can create a personal WorkSpace. For more information, see [Create a WorkSpace in WorkSpaces Personal](create-workspaces-personal.md).

When you are finished using the directory with WorkSpaces, you can deregister it. Note that you must deregister a directory before you can delete it. If you want to deregister and delete a directory, you must first find and remove all the applications and services that are registered to the directory. For more information, see [Delete Your Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_delete.html) in the *AWS Directory Service Administration Guide*. 

**To deregister a directory**

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 the directory.

1. Choose **Actions**, **Deregister**.

1. When prompted for confirmation, choose **Confirm**. After deregistration is complete, the directory becomes unregistered and is removed from the list.

# Select an organizational unit for WorkSpaces Personal
<a name="select-ou"></a>

**Note**  
This feature is only available for directories managed through AWS Directory Service, including AD Connector, AWS Managed Microsoft AD, and Simple AD.

WorkSpace machine accounts are placed in the default organizational unit (OU) for the WorkSpaces directory. Initially, the machine accounts are placed in the Computers OU of your directory or the directory that your AD Connector is connected to. You can select a different OU from your directory or connected directory, or specify an OU in a separate target domain. Note that you can select only one OU per directory.

After you select a new OU, the machine accounts for all WorkSpaces that are created or rebuilt are placed in the newly selected OU.

**To select an organizational unit**

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. Choose your directory.

1. Under Target domain and organizational unit, choose **Edit**.

1. To find an OU, under Target and organizational unit, you can start typing all or part of the OU name and choose the OU you want to use.

1. (Optional) Choose an OU distiguished name to overwrite your selected OU with a custom OU.

1. Choose **Save**.

1. (Optional) Rebuild the existing WorkSpaces to update the OU. For more information, see [Rebuild a WorkSpace in WorkSpaces Personal](rebuild-workspace.md).

# Configure automatic public IP addresses for WorkSpaces Personal
<a name="automatic-assignment"></a>

After you enable automatic assignment of public IP addresses, each WorkSpace that you launch is assigned a public IP address from the Amazon-provided pool of public addresses. A WorkSpace in a public subnet can access the internet through the internet gateway if it has a public IP address. WorkSpaces that already exist before you enable automatic assignment do not receive public addresses until you rebuild them.

Note that you do not need to enable automatic assignment of public addresses if your WorkSpaces are in private subnets and you configured a NAT gateway for the virtual private cloud (VPC), or if your WorkSpaces are in public subnets and you assigned them Elastic IP addresses. For more information, see [Configure a VPC for WorkSpaces Personal](amazon-workspaces-vpc.md).

**Warning**  
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](rebuild-workspace.md). If you don't want to rebuild the WorkSpace, you must associate another Elastic IP address that you own to the WorkSpace.

**To configure Elastic IP addresses**

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 the directory for your WorkSpaces.

1. Choose **Actions**, **Update Details**.

1. Expand **Access to Internet** and select **Enable** or **Disable**.

1. Choose **Update**.

# Control device access for WorkSpaces Personal
<a name="control-device-access"></a>

You can specify the types of devices that have access to WorkSpaces based on the device platform. You can use certificates to restrict access to WorkSpaces to trusted devices (also known as managed devices).

**To control device access to WorkSpaces**

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. Choose your directory.

1. Under Access control options, choose **Edit**.

1. Under Trusted devices, specify which device types can access WorkSpaces by selecting either **Allow all**, **Trusted devices**, or **Deny all**. For more information, see [Restrict access to trusted devices for WorkSpaces Personal](trusted-devices.md).

1. Choose **Save**.

# Manage local administrator permissions for WorkSpaces Personal
<a name="local-admin-setting"></a>

**Note**  
This feature is only available for directories managed through AWS Directory Service, including AD Connector, AWS Managed Microsoft AD, and Simple AD.

You can specify whether users are local administrators on their WorkSpaces, which enables them to install application and modify settings on their WorkSpaces. Users are local administrators by default. If you modify this setting, the change applies to all new WorkSpaces that you create and any WorkSpaces that you rebuild.

**To modify local administrator permissions**

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. Choose your directory.

1. Under Local administrator settings, choose **Edit**.

1. To ensure that users are local administrators, choose **Enable local administrator setting**.

1. Choose **Save**.

# Update the AD Connector account (AD Connector) for WorkSpaces Personal
<a name="connect-account"></a>

You can update the AD Connector account that is used to read users and groups and join WorkSpaces machine accounts to your AD Connector directory.

**To update the AD Connector account**

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 then choose **View details**.

1. Under AD connector account, choose **Edit**.

1. Enter the sign-in credentials for the new account.

1. Choose **Save**.

# Multi-factor authentication (AD Connector) for WorkSpaces Personal
<a name="connect-mfa"></a>

You can enable multi-factor authentication (MFA) for your AD Connector directory. For more information about using multi-factor authentication with AWS Directory Service, see [ Enable multi-factor authentication for AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_mfa.html) and [ AD Connector prerequisites](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/prereq_connector.html). 

**Note**  
Your RADIUS server can either be hosted by AWS or it can be on-premises.
The usernames must match between Active Directory and your RADIUS server. 

**To enable multi-factor authentication**

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 then choose **Actions**, **Update Details**.

1. Expand **Multi-Factor Authentication** and then select **Enable Multi-Factor Authentication**.

1. For **RADIUS server IP address(es)**, type the IP addresses of your RADIUS server endpoints separated by commas, or type the IP address of your RADIUS server load balancer.

1. For **Port**, type the port that your RADIUS server is using for communications. Your on-premises network must allow inbound traffic over the default RADIUS server port (UDP:1812) from AD Connector.

1. For **Shared secret code** and **Confirm shared secret code**, type the shared secret code for your RADIUS server.

1. For **Protocol**, choose the protocol for your RADIUS server.

1. For **Server timeout**, type the time, in seconds, to wait for the RADIUS server to respond. This value must be between 1 and 50.

1. For **Max retries**, type the number of times to attempt communication with the RADIUS server. This value must be between 0 and 10.

1. Choose **Update and Exit**.

Multi-factor authentication is available when **RADIUS status** is **Enabled**. While multi-factor authentication is being set up, users cannot log in to their WorkSpaces.

# Create a directory for WorkSpaces Personal
<a name="launch-workspaces-tutorials"></a>

WorkSpaces Personal allows you to use directories managed through Directory Service to store and manage information for your WorkSpaces and users. Use the following options to create a WorkSpaces Personal directory:
+ Create a Simple AD directory.
+ Create an AWS Directory Service for Microsoft Active Directory, also known as AWS Managed Microsoft AD.
+ Connect to an existing Microsoft Active Directory by using Active Directory Connector.
+ Create a trust relationship between your AWS Managed Microsoft AD directory and your on-premises domain.
+ Create a dedicated Microsoft Entra ID WorkSpaces directory.
+ Create a dedicated Custom WorkSpaces directory.

**Note**  
Shared directories are not currently supported for use with Amazon WorkSpaces.
If you configure your AWS Managed Microsoft AD directory for multi-Region replication, only the directory in the primary Region can be registered for use with Amazon WorkSpaces. Attempts to register the directory in a replicated Region for use with Amazon WorkSpaces will fail. Multi-Region replication with AWS Managed Microsoft AD isn't supported for use with Amazon WorkSpaces within replicated Regions.
Simple AD and AD Connector are made 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/).

## Before you create a directory
<a name="prereqs-tutorials"></a>
+ WorkSpaces is not available in every Region. Verify the supported Regions and select a Region for your WorkSpaces. For more information about the supported Regions, see [WorkSpaces Pricing by AWS Region](https://aws.amazon.com/workspaces/pricing/).
+ Create a virtual private cloud with at least two private subnets. For more information, see [Configure a VPC for WorkSpaces Personal](amazon-workspaces-vpc.md). The VPC must be connected to your on-premises network through a virtual private network (VPN) connection or Direct Connect. For more information, see [AD Connector Prerequisites](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/prereq_connector.html) in the *AWS Directory Service Administration Guide*.
+ Provide access to the internet from the WorkSpace. For more information, see [Provide internet access for WorkSpaces Personal](amazon-workspaces-internet-access.md).

For information about how to delete an empty directory, 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.

**Topics**
+ [Before you create a directory](#prereqs-tutorials)
+ [Identify the computer name for your WorkSpaces Personal directory](wsp-directory-identify-computer.md)
+ [Create an AWS Managed Microsoft AD directory for WorkSpaces Personal](launch-workspace-microsoft-ad.md)
+ [Create a Simple AD directory for WorkSpaces Personal](launch-workspace-simple-ad.md)
+ [Create an AD Connector for WorkSpaces Personal](launch-workspace-ad-connector.md)
+ [Create a trust relationship between your AWS Managed Microsoft AD directory and your on-premises domain for WorkSpaces Personal](launch-workspace-trusted-domain.md)
+ [Create a dedicated Microsoft Entra ID directory with WorkSpaces Personal](launch-entra-id.md)
+ [Create a dedicated Custom directory with WorkSpaces Personal](launch-custom.md)

# Identify the computer name for your WorkSpaces Personal directory
<a name="wsp-directory-identify-computer"></a>

The **Computer Name** value shown for a WorkSpace in the Amazon WorkSpaces console varies, depending on which type of WorkSpace you've launched (Amazon Linux, Ubuntu, or Windows). The computer name for a WorkSpace can be in one of these formats: 
+ **Amazon Linux**: A-*xxxxxxxxxxxxx*
+ **Red Hat Enterprise Linux**: R-*xxxxxxxxxxxxx*
+ **Rocky Linux**: R-*xxxxxxxxxxxxx*
+ **Ubuntu**: U-*xxxxxxxxxxxxx*
+ **Windows**: IP-C*xxxxxx* or WSAMZN-*xxxxxxx* or EC2AMAZ-*xxxxxxx*

For Windows WorkSpaces, the computer name format is determined by the bundle type, and in the case of WorkSpaces created from public bundles or from custom bundles based on public images, by when the public images were created.

Starting June 22, 2020, Windows WorkSpaces launched from public bundles have the WSAMZN-*xxxxxxx* format for their computer names instead of the IP-C*xxxxxx* format.

For custom bundles based on a public image, if the public image was created before June 22, 2020, the computer names are in the EC2AMAZ-*xxxxxxx* format. If the public image was created on or after June 22, 2020, the computer names are in the WSAMZN-*xxxxxxx* format. 

For Bring Your Own License (BYOL) bundles, either the DESKTOP-*xxxxxxx* or the EC2AMAZ-*xxxxxxx* format is used for the computer names by default.

If you've specified a custom format for the computer names in your custom or BYOL bundles, your custom format overrides these defaults. To specify a custom format, see [Create a custom WorkSpaces image and bundle for WorkSpaces Personal](create-custom-bundle.md).

**Important**  
After a WorkSpace is created, you can safely change its computer name. For example, you can execute a PowerShell script with the command `Rename-Computer` on your WorkSpace or remotely. The updated computer name value will then be shown for a WorkSpace in the Amazon WorkSpaces console.

# Create an AWS Managed Microsoft AD directory for WorkSpaces Personal
<a name="launch-workspace-microsoft-ad"></a>

In this tutorial, we create an AWS Managed Microsoft AD directory. For tutorials that use the other options, see [Create a directory for WorkSpaces Personal](launch-workspaces-tutorials.md).

First, create an AWS Managed Microsoft AD directory. Directory Service creates two directory servers, one in each of the private subnets of your VPC. Note that there are no users in the directory initially. You will add a user in the next step when you launch the WorkSpace.

**Note**  
Shared directories are not currently supported for use with Amazon WorkSpaces.
If your AWS Managed Microsoft AD directory has been configured for multi-Region replication, only the directory in the primary Region can be registered for use with Amazon WorkSpaces. Attempts to register the directory in a replicated Region for use with Amazon WorkSpaces will fail. Multi-Region replication with AWS Managed Microsoft AD isn't supported for use with Amazon WorkSpaces within replicated Regions.

**To create an AWS Managed Microsoft AD directory**

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. Choose **Create directory**.

1. On the **Create directory** page, for **WorkSpaces type** choose **Personal**. Then, for **WorkSpace device management** choose **AWS Directory Service**.

1. Choose **Create directory**, which opens the **Set up a directory** page on the AWS Directory Service

1. Choose **AWS Managed Microsoft AD**, and then **Next**.

1. Configure the directory as follows:

   1. For **Organization name**, enter a unique organization name for your directory (for example, my-demo-directory). This name must be at least four characters in length, consist of only alphanumeric characters and hyphens (-), and begin or end with a character other than a hyphen.

   1. For **Directory DNS**, enter the fully-qualified name for the directory (for example, workspaces.demo.com).
**Important**  
If you need to update your DNS server after launching your WorkSpaces, follow the procedure in [Update DNS servers for WorkSpaces Personal](update-dns-server.md) to ensure that your WorkSpaces get properly updated.

   1. For **NetBIOS name**, enter a short name for the directory (for example, workspaces).

   1. For **Admin password** and **Confirm password**, enter a password for the directory administrator account. For more information about the password requirements, see [Create Your AWS Managed Microsoft AD Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/create_managed_ad.html) in the *AWS Directory Service Administration Guide*.

   1. (Optional) For **Description**, enter a description for the directory.

   1. For **VPC**, select the VPC that you created.

   1. For **Subnets**, select the two private subnets (with the CIDR blocks `10.0.1.0/24` and `10.0.2.0/24`).

   1. Choose **Next Step**.

1. Choose **Create directory**.

1. You will be brought back to the Create directory page on WorkSpaces console. The initial status of the directory is `Requested` and then `Creating`. When directory creation is complete (this might take a few minutes), the status is `Active`.

After you’ve created an AWS Managed Microsoft AD directory, you can register it with Amazon WorkSpaces. For more information, see [Register an existing Directory Service directory with WorkSpaces Personal](register-deregister-directory.md)

# Create a Simple AD directory for WorkSpaces Personal
<a name="launch-workspace-simple-ad"></a>

In this tutorial, we launch a WorkSpace that uses Simple AD. For tutorials that use the other options, see [Create a directory for WorkSpaces Personal](launch-workspaces-tutorials.md).

**Note**  
Simple AD is not available in every AWS Region. Verify the supported Regions and [ select a Region](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html#select-region) for your Simple AD directory. For more information about the supported Regions for Simple AD, see [ Region Availability for AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/regions.html).
Simple AD is made available to you free of charge to use with WorkSpaces. If there are no WorkSpaces being used with your Simple AD 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/).
[ Simple AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/simple_ad_getting_started.html) currently supports only IPv4 addressing, meaning that when creating a directory, the associated VPC will be configured with an IPv4 CIDR block and does not support IPv6 networks.

When you create a Simple AD directory. Directory Service creates two directory servers, one in each of the private subnets of your VPC. There are no users in the directory initially. Add a user after you create the WorkSpace. For more information, see [Create a WorkSpace in WorkSpaces Personal](create-workspaces-personal.md)

**To create a Simple AD directory**

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. Choose **Create directory**.

1. On the **Create directory** page, for **WorkSpaces type** choose **Personal**. Then, for **WorkSpace device management** choose **AWS Directory Service**.

1. Choose **Create directory**, which opens the **Set up a directory** page on the AWS Directory Service

1. Choose **Simple AD**, and then **Next**.

1. Configure the directory as follows:

   1. For **Organization name**, enter a unique organization name for your directory (for example, my-example-directory). This name must be at least four characters in length, consist of only alphanumeric characters and hyphens (-), and begin or end with a character other than a hyphen.

   1. For **Directory DNS name**, enter the fully-qualified name for the directory (for example, example.com).
**Important**  
If you need to update your DNS server after launching your WorkSpaces, follow the procedure in [Update DNS servers for WorkSpaces Personal](update-dns-server.md) to ensure that your WorkSpaces get properly updated.

   1. For **NetBIOS name**, enter a short name for the directory (for example, example).

   1. For **Admin password** and **Confirm password**, enter a password for the directory administrator account. For more information about the password requirements, see [How to Create a Microsoft AD Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/create_managed_ad.html) in the *AWS Directory Service Administration Guide*.

   1. (Optional) For **Description**, enter a description for the directory.

   1. For **Directory size**, choose **Small**.

   1. For **VPC**, select the VPC that you created.

   1. For **Subnets**, select the two private subnets (with the CIDR blocks `10.0.1.0/24` and `10.0.2.0/24`).

   1. Choose **Next**.

1. Choose **Create directory**.

1. You will be brought back to the Create directory page on WorkSpaces console. The initial status of the directory is `Requested` and then `Creating`. When directory creation is complete (this might take a few minutes), the status is `Active`.

**What happens during directory creation**

WorkSpaces completes the following tasks on your behalf:
+ Creates an IAM role to allow the WorkSpaces service to create elastic network interfaces and list your WorkSpaces directories. This role has the name `workspaces_DefaultRole`.
+ Sets up a Simple AD directory in the VPC that is used to store user and WorkSpace information. The directory has an administrator account with the user name Administrator and the specified password.
+ Creates two security groups, one for directory controllers and another for WorkSpaces in the directory.

After you’ve created an Simple AD directory, you can register it with Amazon WorkSpaces. For more information, see [Register an existing Directory Service directory with WorkSpaces Personal](register-deregister-directory.md)

# Create an AD Connector for WorkSpaces Personal
<a name="launch-workspace-ad-connector"></a>

In this tutorial, we create an AD Connector. For tutorials that use the other options, see [Create a directory for WorkSpaces Personal](launch-workspaces-tutorials.md).

## Create an AD Connector
<a name="create-ad-connector"></a>

**Note**  
AD Connector is made available to you free of charge to use with WorkSpaces. If there are no WorkSpaces being used with your 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 AD Connector directory, you can always create a new one when you want to start using WorkSpaces again.

**To create an AD Connector**

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. Choose **Create directory**.

1. On the **Create directory** page, for **WorkSpaces type** choose **Personal**. Then, for **WorkSpace device management** choose **AWS Directory Service**.

1. Choose **Create directory**, which opens the **Set up a directory** page on the AWS Directory Service

1. Choose **AWS Managed Microsoft AD**, and then **Next**.

1. For **Organization name**, enter a unique organization name for your directory (for example, my-example-directory). This name must be at least four characters in length, consist of only alphanumeric characters and hyphens (-), and begin or end with a character other than a hyphen.

1. For **Connected directory DNS**, enter the fully-qualified name of your on-premises directory (for example, example.com).

1. For **Connected directory NetBIOS name**, enter the short name of your on-premises directory (for example, example).

1. For **Connector account username**, enter the user name of a user in your on-premises directory. The user must have permissions to read users and groups, create computer objects, and join computers to the domain.

1. For **Connector account password** and **Confirm password**, enter the password for the on-premises user.

1. For **DNS address**, enter the IP address of at least one DNS server in your on-premises directory.
**Important**  
If you need to update your DNS server IP address after launching your WorkSpaces, follow the procedure in [Update DNS servers for WorkSpaces Personal](update-dns-server.md) to ensure that your WorkSpaces get properly updated.

1. (Optional) For **Description**, enter a description for the directory.

1. Keep **Size** as **Small**.

1. For **VPC**, select your VPC.

1. For **Subnets**, select your subnets. The DNS servers that you specified must be accessible from each subnet.

1. Choose **Create directory**.

1. You will be brought back to the Create directory page on WorkSpaces console. The initial status of the directory is `Requested` and then `Creating`. When directory creation is complete (this might take a few minutes), the status is `Active`.

# Create a trust relationship between your AWS Managed Microsoft AD directory and your on-premises domain for WorkSpaces Personal
<a name="launch-workspace-trusted-domain"></a>

In this tutorial, we create a trust relationship between your AWS Managed Microsoft AD directory and your on-premises domain. For tutorials that use the other options, see [Create a directory for WorkSpaces Personal](launch-workspaces-tutorials.md).

**Note**  
Launching WorkSpaces with AWS accounts in a separate trusted domain works with AWS Managed Microsoft AD when it is configured with a trust relationship to your on-premises directory. However, WorkSpaces using Simple AD or AD Connector cannot launch WorkSpaces for users from a trusted domain.

**To set up the trust relationship**

1. Set up AWS Managed Microsoft AD in your virtual private cloud (VPC). For more information, see [Create Your AWS Managed Microsoft AD directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/create_managed_ad.html) in the *AWS Directory Service Administration Guide*.
**Note**  
Shared directories are not currently supported for use with Amazon WorkSpaces.
If your AWS Managed Microsoft AD directory has been configured for multi-Region replication, only the directory in the primary Region can be registered for use with Amazon WorkSpaces. Attempts to register the directory in a replicated Region for use with Amazon WorkSpaces will fail. Multi-Region replication with AWS Managed Microsoft AD isn't supported for use with Amazon WorkSpaces within replicated Regions.

1. Create a trust relationship between your AWS Managed Microsoft AD and your on-premises domain. Ensure that the trust is configured as a two-way trust. For more information, see [Tutorial: Create a Trust Relationship Between Your AWS Managed Microsoft AD and Your On-Premises Domain](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/tutorial_setup_trust.html) in the *AWS Directory Service Administration Guide*.

A one-way or two-way trust can be used to manage and authenticate with WorkSpaces, and so that WorkSpaces can be provisioned to on-premises users and groups. For more information, see [Deploy Amazon WorkSpaces using a One-Way Trust Resource Domain with AWS Directory Service](https://aws.amazon.com/getting-started/hands-on/deploy-workspaces-one-way-trust/).

**Note**  
Red Hat Enterprise Linux, Rocky Linux, and Ubuntu WorkSpaces use System Security Services Daemon (SSSD) for Active Directory integration, and SSSD does not support forest trust. Configure external trust instead. Two-way trust is recommended for Amazon Linux, Ubuntu, Rocky Linux, and Red Hat Enterprise Linux WorkSpaces.
You cannot use a web browser (Web Access) to connect to Linux WorkSpaces.

# Create a dedicated Microsoft Entra ID directory with WorkSpaces Personal
<a name="launch-entra-id"></a>

In this tutorial, we create Bring Your Own License (BYOL) Windows 10 and 11 personal WorkSpaces that are Microsoft Entra ID joined and enrolled to Microsoft Intune. Before creating such WorkSpaces, you need to first create a dedicated WorkSpaces Personal directory for Entra ID-joined WorkSpaces.

**Note**  
Microsoft Entra joined personal WorkSpaces are available in all AWS regions where Amazon WorkSpaces is offered except for Africa (Cape Town), Israel (Tel Aviv), and China (Ningxia).

**Contents**
+ [Overview](#entra-overview)
+ [Requirements and limitations](#entra-requirements-limitation)
+ [Step 1: Enable IAM Identity Center and synchronize with Microsoft Entra ID](#entra-step-1)
+ [Step 2: Register a Microsoft Entra ID application to grant permissions for Windows Autopilot](#entra-step-2)
+ [Step 3: Configure Windows Autopilot user-driven mode](#entra-step-3)
+ [Step 4: Create an AWS Secrets Manager secret](#entra-step-4)
+ [Step 5: Create a dedicated Microsoft Entra ID WorkSpaces directory](#entra-step-5)
+ [Configure the IAM Identity Center application for a WorkSpaces directory (optional)](#configure-iam-directory)
+ [Create a cross-Region IAM Identity Center integration (optional)](#create-cross-region-iam-identity-integration)

## Overview
<a name="entra-overview"></a>

A Microsoft Entra ID personal WorkSpaces directory contains all the information needed to launch Microsoft Entra ID-joined WorkSpaces that are assigned to your users managed with Microsoft Entra ID. User information is made available to WorkSpaces through AWS IAM Identity Center, which acts as an identity broker to bring your workforce identity from Entra ID to AWS. Microsoft Windows Autopilot user-driven mode is used to accomplish WorkSpaces Intune enrollment and Entra join. The following diagram illustrates the Autopilot process.

![\[Diagram showing WorkSpaces client, service, and agent interacting with AWS and Azure components for authentication and device management.\]](http://docs.aws.amazon.com/workspaces/latest/adminguide/images/autopilot.jpg)


## Requirements and limitations
<a name="entra-requirements-limitation"></a>
+ Microsoft Entra ID P1 plan or higher.
+ Microsoft Entra ID and Intune is enabled and have role assignments.
+ Intune administrator - Required for managing Autopilot deployment profiles.
+ Global administrator - Required for granting admin consent for the API permissions assigned to the application created in [ step 3](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspaces-tutorials.html#entra-step-3). The application can be created without this permission. However, a Global Administrator would need to provide admin consent on the application permissions.
+ Assign Windows 10/11 VDA E3 or E5 user subscription licenses to your WorkSpaces users.
+ Entra ID directories only support Windows 10 or 11 Bring Your Own License personal WorkSpaces. The following are supported versions.
  + Windows 10 Version 21H2 (December 2021 Update)
  + Windows 10 Version 22H2 (November 2022 Update)
  + Windows 11 Enterprise 23H2 (October 2023 release)
  + Windows 11 Enterprise 22H2 (October 2022 release)
  + Windows 11 Enterprise 24H2 (October 2024 release)
  + Windows 11 Enterprise 25H2 (September 2025 release)
+ Bring Your Own License (BYOL) is enabled for your AWS account and you have a valid Windows 10 or 11 BYOL image imported in your account. For more information, see [Bring Your Own Windows desktop licenses in WorkSpaces](byol-windows-images.md).
+ Microsoft Entra ID directories only support Windows 10 or 11 BYOL personal WorkSpaces.
+ Microsoft Entra ID directories support only DCV protocol.
+ If you are using a firewall for your WorkSpaces, make sure it does not block the outbound traffic to the endpoints for Microsoft Intune and Windows Autopilot. Please review [Network endpoints for Microsoft Intune - Microsoft Intune](https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/intune-endpoints?tabs=north-america) and [Windows Autopilot requirements](https://learn.microsoft.com/en-us/autopilot/requirements?tabs=networking) for details.
+ Microsoft Entra ID directories do not support Microsoft Entra ID tenants in Government Community Cloud High (GCCH) and Department of Defense (DoD) environments.

## Step 1: Enable IAM Identity Center and synchronize with Microsoft Entra ID
<a name="entra-step-1"></a>

To create Microsoft Entra ID-joined personal WorkSpaces and assign them to your Entra ID users, you have to make the user information available to AWS through IAM Identity Center. IAM Identity Center is the recommended AWS service for managing user access to AWS resources. For more information, see [ What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html). This is a one-time setup.

If you don’t have an existing IAM Identity Center instance to integrate with your WorkSpaces, we recommend that you create one in the same Region as your WorkSpaces. If you have an existing AWS Identity Center instance in a different Region, you can set up cross-Region integration. For more information about cross-Region setup, see [Create a cross-Region IAM Identity Center integration (optional)](#create-cross-region-iam-identity-integration). 

**Note**  
Cross-region integration between WorkSpaces and IAM Identity Center is not supported in AWS GovCloud (US) Region.

1. Enable IAM Identity Center with your AWS Organizations, especially if you are using a multi-account environment. You can also create an account instance of IAM Identity Center. To learn more, see [ Enabling AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html). Each WorkSpaces directory can be associated with one IAM Identity Center instance, organization or account. 

   If you are using an organization instance and trying to create a WorkSpaces directory in one of the member accounts, make sure you have the following IAM Identity Center permissions.
   + `"sso:DescribeInstance"`
   + `"sso:CreateApplication"`
   + `"sso:PutApplicationGrant"`
   + `"sso:PutApplicationAuthenticationMethod"`
   + `"sso:DeleteApplication"`
   + `"sso:DescribeApplication"`
   + `"sso:getApplicationGrant"`

   For more information, see [ Overview of managing access permissions to your IAM Identity Center resources](https://docs.aws.amazon.com/singlesignon/latest/userguide/iam-auth-access-overview.html). Also, ensure that no Service Control Policies (SCPs) are blocking these permissions. To learn more about SCPs, see [ Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).

1. Configure IAM Identity Center and Microsoft Entra ID to automatically synchronize selected or all users from your Entra ID tenant to your IAM Identity Center instance. For more information, see [ Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/idp-microsoft-entra.html) and [ Tutorial: Configure AWS IAM Identity Center for automatic user provisioning](https://learn.microsoft.com/en-us/entra/identity/saas-apps/aws-single-sign-on-provisioning-tutorial).

1. Verify that the users you configured on Microsoft Entra ID are synchronized correctly to AWS IAM Identity Center instance. If you see an error message in Microsoft Entra ID, it indicates that the user in Entra ID is configured in a way that IAM Identity Center doesn’t support. The error message will identify this issue. For example, if the user object in Entra ID lacks a first name, a last name, and/or a display name, you’ll receive an error message similar to `"2 validation errors detected: Value at 'name.givenName' failed to satisfy constraint: Member must satisfy regular expression pattern: [\\p{L}\\p{M}\\p{S}\\p{N}\\p{P}\\t\\n\\r ]+; Value at 'name.givenName' failed to satisfy constraint: Member must have length greater than or equal to 1"`. For more information, see [ Specific users fail to synchronize into IAM Identity Center from an external SCIM provider](https://docs.aws.amazon.com/singlesignon/latest/userguide/troubleshooting.html#issue2).

**Note**  
WorkSpaces uses Entra ID UserPrincipalName (UPN) attribute to identify individual users and the following are its limitations:  
UPNs cannot exceed 63 characters in length.
If you change the UPN after assigning a WorkSpace to a user, the user won't be able to connect to their WorkSpace unless you change the UPN back to what it was before.

## Step 2: Register a Microsoft Entra ID application to grant permissions for Windows Autopilot
<a name="entra-step-2"></a>

WorkSpaces Personal uses Microsoft Windows Autopilot user-driven mode to enroll WorkSpaces to Microsoft Intune and join them to Microsoft Entra ID.

To allow Amazon WorkSpaces to register WorkSpaces Personal into Autopilot, you must register a Microsoft Entra ID application that grants necessary Microsoft Graph API permissions. For more information about registering an Entra ID application, see [ Quickstart: Register an application with the Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app?tabs=certificate).

We recommend providing the following API permissions in your Entra ID application.
+ To create a new personal WorkSpace that needs to be joined to Entra ID, following API permission is required.
  + `DeviceManagementServiceConfig.ReadWrite.All`
+ When you terminate a personal WorkSpace or rebuild it, the following permissions are used. 
**Note**  
If you don’t provide these permissions, WorkSpace will be terminated but it will not be removed from your Intune and Entra ID tenants and you will have to remove them separately.
  + `DeviceManagementServiceConfig.ReadWrite.All`
  + `Device.ReadWrite.All`
  + `DeviceManagementManagedDevices.ReadWrite.All`
+ These permissions require admin consent. For more information, see [ Grant tenant-wide admin consent to an application ](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/grant-admin-consent?pivots=portal).

Next, you must add a client secret for the Entra ID application. For more information, see [ Add credentials](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app?tabs=certificate#add-credentials). Make sure you remember the client secret string as you will need it when creating the AWS Secrets Manager secret in Step 4.

## Step 3: Configure Windows Autopilot user-driven mode
<a name="entra-step-3"></a>

Ensure you are familiar with the [ Step by step tutorial for Windows Autopilot user-driven Microsoft Entra join in Intune](https://learn.microsoft.com/en-us/autopilot/tutorial/user-driven/azure-ad-join-workflow).

**To configure your Microsoft Intune for Autopilot**

1. Sign into the Microsoft Intune admin center

1. Create a new Autopilot device group for personal WorkSpaces. For more information, see [Create device groups for Windows Autopilot](https://learn.microsoft.com/en-us/autopilot/enrollment-autopilot).

   1. Choose **Groups**, **New group**

   1. For **Group type**, choose **Security**.

   1. For **Membership type**, choose **Dynamic Device**.

   1. Choose **Edit dynamic query** to create a dynamic membership rule. The rule should be in the following format:

      ```
      (device.devicePhysicalIds -any (_ -eq "[OrderID]:WorkSpacesDirectoryName"))
      ```
**Important**  
`WorkSpacesDirectoryName` should match the directory name of the Entra ID WorkSpaces Personal directory you create in step 5. This is because the directory name string is used as group tag when WorkSpaces registers virtual desktops into Autopilot. Additionally, group tag maps to the `OrderID` attribute on Microsoft Entra devices. 

1. Choose **Devices**, **Windows**, **Enrollment**. For **Enrollment Options**, choose **Automatic Enrollment**. For **MDM user scope** select **All**.

1. Create an Autopilot deployment profile. For more information, see [ Create an Autopilot deployment profile](https://learn.microsoft.com/en-us/autopilot/profiles#create-an-autopilot-deployment-profile).

   1. For **Windows Autopilot**, choose **Deployment profiles**, **Create profile**.

   1. In the **Windows Autopilot deployment profiles** screen, select the **Create Profile** drop down menu and then select **Windows PC**.

   1. In the **Create profile** screen, on **On the Out-of-box experience (OOBE)** page. For **Deployment mode**, select **User-driven**. For **Join to Microsoft Entra ID**, select **Microsoft Entra joined**. You can customize the computer names for your Entra ID-joined personal WorkSpaces by selecting **Yes** for **Apply device name template**, to create a template to use when naming a device during enrollment.

   1. On the **Assignments** page, for **Assign to**, choose **Selected groups**. Choose **Select groups to include**, and select the Autopilot device group you’ve just created in 2.

## Step 4: Create an AWS Secrets Manager secret
<a name="entra-step-4"></a>

You must create a secret in AWS Secrets Manager to securely store the information, including the application ID and client secret, for the Entra ID application you created in [Step 2: Register a Microsoft Entra ID application to grant permissions for Windows Autopilot](#entra-step-2). This is a one-time setup. 

**To create an AWS Secrets Manager secret**

1. Create a customer managed key on [AWS Key Management Service](https://aws.amazon.com/kms/). The key will later be used to encrypt the AWS Secrets Manager secret. Don't use the default key to encrypt your secret as the default key cannot be accessed by the WorkSpaces service. Follow the steps below to create the key.

   1. Open the 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. Choose **Create key**.

   1. On the **Configure key** page, for **Key type** choose **Symmetric**. For **Key usage**, choose **Encrypt and decrypt**.

   1. On the **Review** page, in the Key policy editor, ensure you allow the WorkSpaces service's principal `workspaces.amazonaws.com` access to the key by including following permissions in the key policy.

      ```
      {
          "Effect": "Allow",
          "Principal": {
              "Service": [
                  "workspaces.amazonaws.com"
              ]
          },
          "Action": [
              "kms:Decrypt",
              "kms:DescribeKey"
          ],
          "Resource": "*"
       }
      ```

1. Create the secret on AWS Secrets Manager, using the AWS KMS key created in previous step.

   1. Open the Secrets Manager console at [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/).

   1. Choose **Store a new secret**.

   1. On the **Choose secret type** page, for **Secret type**, select **Other type of secret**.

   1. For **Key/value pairs**, in the key box, enter “application\$1id” into the key box, then copy the Entra ID application ID from [Step 2](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspaces-tutorials.html#entra-step-2) and paste it into the value box.

   1. Choose **Add row**, in the key box, enter “application\$1password”, then copy the Entra ID application client secret from [Step 2](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspaces-tutorials.html#entra-step-2) and paste it into the value box.

   1. Choose the AWS KMS key that you created in the previous step from the **Encryption key** drop-down list.

   1. Choose **Next**.

   1. On the **Configure secret** page, enter a **Secret name** and **Description**.

   1. In the **Resource permissions** section, choose **Edit permissions**.

   1. Make sure you allow the WorkSpaces service's principal `workspaces.amazonaws.com` access to the secret by including following resource policy in the resource permissions.

------
#### [ JSON ]

****  

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement" : [ {
          "Effect" : "Allow",
          "Principal" : {
            "Service" : [ "workspaces.amazonaws.com"]
          },
          "Action" : "secretsmanager:GetSecretValue",
          "Resource" : "*"
        } ]
      }
      ```

------

## Step 5: Create a dedicated Microsoft Entra ID WorkSpaces directory
<a name="entra-step-5"></a>

Create a dedicated WorkSpaces directory that stores information for your Microsoft Entra ID-joined WorkSpaces and Entra ID users.

**To create an Entra ID WorkSpaces directory**

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. On the **Create directory** page, for **WorkSpaces type** choose **Personal**. For **WorkSpace device management**, choose **Microsoft Entra ID**.

1. For **Microsoft Entra tenant ID**, enter your Microsoft Entra ID tenant ID that you want your directory's WorkSpaces to join to. You won't be able to change the tenant ID after the directory is created. 

1. For **Entra ID Application ID and password**, select the AWS Secrets Manager secret that you created in [Step 4](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspaces-tutorials.html#entra-step-4) from the drop down list. You won't be able to change the secret associated with the directory after the directory is created. However, you can always update the content of the secret, including the Entra ID Application ID and its password through the AWS Secrets Manager console at [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/).

1. If your IAM Identity Center instance is in the same AWS Region as your WorkSpaces directory, for **User identity source**, select the IAM Identity Center instance that you configured in [Step 1](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspaces-tutorials.html#entra-step-1) from the dropdown list. You won't be able to change the IAM Identity Center instance associated with the directory after the directory is created.

   If your IAM Identity Center instance is in a different AWS Region than your WorkSpaces directory, choose **Enable Cross-Region** and then select the Region from the dropdown list.
**Note**  
If you have an existing IAM Identity Center instance in a different Region, you must opt-in to set up a cross-Region integration. For more information about cross-Region setup, see [Create a cross-Region IAM Identity Center integration (optional)](#create-cross-region-iam-identity-integration). 

1. For **Directory name**, enter a unique name for the directory (For example, `WorkSpacesDirectoryName`).
**Important**  
The directory name should match the `OrderID` used to construct the dynamic query for the Autopilot device group that you created with Microsoft Intune in [Step 3](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-workspaces-tutorials.html#entra-step-3). The directory name string is used as the group tag when registering personal WorkSpaces into Windows Autopilot. The group tag maps to the `OrderID` attribute on Microsoft Entra devices.

1. (Optional) For **Description**, enter a description for the directory.

1. For **VPC**, select the VPC that you used to launch your WorkSpaces. For more information, see [Configure a VPC for WorkSpaces Personal](amazon-workspaces-vpc.md).

1. For **Subnets**, select two subnets of your VPC that are not from the same Availability Zone. These subnets will be used to launch your personal WorkSpaces. For more information, see [Availability Zones for WorkSpaces Personal](azs-workspaces.md).
**Important**  
Make sure the WorkSpaces launched in the subnets have internet access, which is needed when users login to the Windows desktops. For more information, see [Provide internet access for WorkSpaces Personal](amazon-workspaces-internet-access.md).

1. For **Configuration**, select **Enable dedicated WorkSpace**. You must enable it to create a dedicated WorkSpaces Personal directory to launch Bring Your Own License (BYOL) Windows 10 or 11 personal WorkSpaces. 
**Note**  
If you don't see the **Enable dedicated WorkSpace** option under **Configuration**, your account hasn't been enabled for BYOL. To enable BYOL for your account, see [Bring Your Own Windows desktop licenses in WorkSpaces](byol-windows-images.md).

1. (Optional) For **Tags**, specify the key pair value that you want to use for personal WorkSpaces in the directory.

1. Review the directory summary and choose **Create directory**. It takes several minutes for your directory to be connected. The initial status of the directory is `Creating`. When directory creation is complete, the status is `Active`. 

An IAM Identity Center application is also automatically created on your behalf once the directory is created. To find the application’s ARN go to the directory's summary page.

You can now use the directory to launch Windows 10 or 11 personal WorkSpaces that are enrolled to Microsoft Intune and joined to Microsoft Entra ID. For more information, see [Create a WorkSpace in WorkSpaces Personal](create-workspaces-personal.md). 

After you've created a WorkSpaces Personal directory, you can create a personal WorkSpace. For more information, see [Create a WorkSpace in WorkSpaces Personal](create-workspaces-personal.md)

## Configure the IAM Identity Center application for a WorkSpaces directory (optional)
<a name="configure-iam-directory"></a>

A corresponding IAM Identity Center application is automatically created once a directory is created. You can find the application’s ARN in the Summary section on the directory detail page. By default, all users in the Identity Center instance can access their assigned WorkSpaces without configuring the corresponding Identity Center application. However, you can manage user access to WorkSpaces in a directory by configuring the user assignment for the IAM Identity Center application.

**To configure the user assignment for the IAM Identity Center application**

1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. On the **AWS managed applications** tab, choose the application for the WorkSpaces directory. The application names are in the following format: `WorkSpaces.wsd-xxxxx`, where `wsd-xxxxx` is the WorkSpaces directory ID.

1. Choose **Actions**, **Edit details**.

1. Change the **User and group assignment method** from **Do not require assignments** to **Require assignments**.

1. Choose **Save changes**.

After you make this change, users in the Identity Center instance will lose access their assign WorkSpaces unless they are assigned to the application. To assign your users to the application, use the AWS CLI command `create-application-assignment` to assign users or groups to an application. For more information, see the [AWS CLI Command Reference](https://docs.aws.amazon.com//cli/latest/reference/sso-admin/create-application-assignment.html).

## Create a cross-Region IAM Identity Center integration (optional)
<a name="create-cross-region-iam-identity-integration"></a>

We recommend that your WorkSpaces and the associated IAM Identity Center instance are in the same AWS Region. However, if you already have an IAM Identity Center instance configured in a different Region from your WorkSpaces Region, you can create a cross-Region integration. When you create a cross-Region WorkSpaces and IAM Identity Center integration, you enable WorkSpaces to make cross-Region calls to access and store information from your IAM Identity Center instance, such as user and group attributes.

**Important**  
Amazon WorkSpaces supports cross-Region IAM Identity Center and WorkSpaces integrations only for organization-level instances. WorkSpaces doesn't support cross-Region IAM Identity Center integrations for account-level instances. For more information about IAM Identity Center instance types and their use cases, see, [Understanding types of IAM Identity Center instances](https://docs.aws.amazon.com//amazonq/latest/qbusiness-ug/setting-up.html#idc-instance-types).

If you create a cross-Region integration between a WorkSpaces directory and an IAM Identity Center instance, you may experience higher latency when deploying WorkSpaces and during login because of cross-Region calls. The increase in latency is proportional to the distance between your WorkSpaces Region and the IAM Identity Center Region. We recommend that you perform latency tests for your specific use case.

 You can enable cross-Region IAM Identity Center connections during [Step 5: Create a dedicated Microsoft Entra ID WorkSpaces directory](https://docs.aws.amazon.com/workspaces/latest/adminguide/launch-entra-id.html#entra-step-5). For **User identity source**, choose the IAM Identity Center instance that you configured in [Step 1: Enable IAM Identity Center and synchronize with Microsoft Entra ID](#entra-step-1) from the dropdown menu. 

**Important**  
You can't change the IAM Identity Center instance associated with the directory after you create it.

# Create a dedicated Custom directory with WorkSpaces Personal
<a name="launch-custom"></a>

Before you create Windows 10 and 11 BYOL personal WorkSpaces and assign them to your users, managed with AWS IAM Identity Center Identity Providers (IdPs), you must create a dedicated Custom WorkSpaces directory. Personal WorkSpaces are not joined to any Microsoft Active Directory but can be managed with a Mobile Device Management (MDM) solution of your choice, such as JumpCloud. For more information about JumpCloud, see [this article](https://jumpcloud.com/support/integrate-with-aws-workspaces). For tutorials that use the other options, see [Create a directory for WorkSpaces Personal](launch-workspaces-tutorials.md).

**Note**  
Amazon WorkSpaces can't create or manage user accounts on personal WorkSpaces launched in a Custom directory. As an administrator, you will have to manage them.
Custom WorkSpaces directory is available in all AWS regions where Amazon WorkSpaces is offered except for Africa (Cape Town), Israel (Tel Aviv), and China (Ningxia).
Amazon WorkSpaces can't create or manage user accounts on WorkSpaces using Custom directories. To ensure the MDM agent software you use can create the user profile on the Windows WorkSpaces, contact the MDM solution providers. Creating the user profile allows your users to sign into the Windows desktop from Windows login screen.

**Contents**
+ [Requirements and limitations](#custom-requirements-limitations)
+ [Step 1: Enable IAM Identity Center and connect with your Identity Provider](#custom-step-1)
+ [Step 2: Create a dedicated Custom WorkSpaces directory](#custom-step-2)

## Requirements and limitations
<a name="custom-requirements-limitations"></a>
+ Custom WorkSpaces directories only support Windows 10 or 11 Bring Your Own License personal WorkSpaces.
+ Custom WorkSpaces directories only support DCV protocol.
+ Ensure you enable BYOL for your AWS account and you have your own AWS KMS server that your personal WorkSpaces can access for Windows 10 and 11 activation. For details, see [Bring Your Own Windows desktop licenses in WorkSpaces](byol-windows-images.md).
+ Ensure you pre-install the MDM agent software on the BYOL image that you imported to your AWS account.

## Step 1: Enable IAM Identity Center and connect with your Identity Provider
<a name="custom-step-1"></a>

To assign WorkSpaces to your users managed with your Identity Providers, the user information must be made available to AWS through AWS IAM Identity Center. We recommend using IAM Identity Center to manage your user's access to AWS resources. For more information, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html). This is a one-time setup.

**To make user information available to AWS**

1. Enable IAM Identity Center on AWS. You can enable IAM Identity Center with your AWS organizations, especially if you are using a multi-account environment. You can also create an account instance of IAM Identity Center. For more information, see [ Enabling AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html). Each WorkSpaces directory can associate with one IAM Identity Center organization or account instance. Each IAM Identity Center instance can be associated with one or more WorkSpaces Personal directory.

   If you are using an organization instance and trying to create a WorkSpaces directory in one of the member accounts, ensure you have the following IAM Identity Center permissions. 
   + `"sso:DescribeInstance"`
   + `"sso:CreateApplication"`
   + `"sso:PutApplicationGrant"`
   + `"sso:PutApplicationAuthenticationMethod"`
   + `"sso:DeleteApplication"`
   + `"sso:DescribeApplication"`
   + `"sso:getApplicationGrant"`

   For more information, see [ Overview of managing access permissions to your IAM Identity Center resources](https://docs.aws.amazon.com/singlesignon/latest/userguide/iam-auth-access-overview.html). Ensure that no Service Control Policies (SCPs) are blocking these permissions. To learn more about SCPs, see [ Service control policies (SCPs)](https://docs.aws.amazon.com/userguide/orgs_manage_policies_scps.html).

1. Configure IAM Identity Center and your Identity Provider (IdP) to automatically synchronize users from your IdP to your IAM Identity Center instance. For more information, see [ Getting started tutorials](https://docs.aws.amazon.com/singlesignon/latest/userguide/tutorials.html) and choose the specific tutorial for the IdP that you want to use. For example, [ Using IAM Identity Center to connect with your JumpCloud Directory Platform](https://docs.aws.amazon.com/singlesignon/latest/userguide/jumpcloud-idp.html).

1. Verify that the users you configured on your IdP are synchronized correctly to AWS IAM Identity Center instance. The first synchronization can take up to an hour depending the configuration of your IdP. 

## Step 2: Create a dedicated Custom WorkSpaces directory
<a name="custom-step-2"></a>

Create a dedicated WorkSpaces Personal directory that stores information about your personal WorkSpaces and your users.

**To create a dedicated Custom WorkSpaces directory**

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. Choose **Create directory**.

1. On the **Create directory** page, for **WorkSpaces** type, choose **Personal**. For **WorkSpace device management**, choose **Custom**.

1. For **User identity source**, select the IAM Identity Center instance that you configured in [Step 1](https://docs.aws.amazon.com/) from the dropdown list. You won't be able to change the IAM Identity Center instance associated with the directory once the directory is created.
**Note**  
You have to specify an IAM Identity Center instance for the directory or you won't be able to launch personal WorkSpaces with the directory using the WorkSpaces console. WorkSpaces directories with no associated Identity Center are only compatible with WorkSpaces Core partner solutions.

1. For **Directory name**, enter a unique name for the directory.

1. For **VPC**, select the VPC that you used to launch your WorkSpaces. For more information, see [Configure a VPC for WorkSpaces Personal](amazon-workspaces-vpc.md).

1. For **Subnets**, select two subnets of your VPC that are not from the same Availability Zone. These subnets will be used to launch your personal WorkSpaces. For more information, see [Availability Zones for WorkSpaces Personal](azs-workspaces.md).
**Important**  
Make sure the WorkSpaces launched in the subnets have internet access, which is needed when users login to the Windows desktops. For more information, see [Provide internet access for WorkSpaces Personal](amazon-workspaces-internet-access.md).

1. For **Configuration**, select **Enable dedicated WorkSpace**. You must enable it to create a dedicated WorkSpaces Personal directory to launch Bring Your Own License (BYOL) Windows 10 or 11 personal WorkSpaces. 

1. (Optional) For **Tags**, specify the key pair value that you want to use for personal WorkSpaces in the directory.

1. Review the directory summary and choose **Create directory**. It takes several minutes for your directory to be connected. The initial status of the directory is `Creating`. When directory creation is complete, the status is `Active`. 

An IAM Identity Center application is also automatically created on your behalf once the directory is created. To find the application’s ARN go to the directory's summary page.

You can now use the directory to launch Windows 10 or 11 personal WorkSpaces that are enrolled to Microsoft Intune and joined to Microsoft Entra ID. For more information, see [Create a WorkSpace in WorkSpaces Personal](create-workspaces-personal.md). 

After you've created a WorkSpaces Personal directory, you can create a personal WorkSpace. For more information, see [Create a WorkSpace in WorkSpaces Personal](create-workspaces-personal.md)

# Update DNS servers for WorkSpaces Personal
<a name="update-dns-server"></a>

If you need to update the DNS server IP addresses for your Active Directory after launching your WorkSpaces, you must also update your WorkSpaces with the new DNS server settings.

You can update your WorkSpaces with the new DNS settings in one of the following ways:
+ Update the DNS settings on the WorkSpaces **before** you update the DNS settings for Active Directory.
+ Rebuild the WorkSpaces **after** you update the DNS settings for Active Directory.

We recommend updating the DNS settings on the WorkSpaces before updating the DNS settings in Active Directory (as explained in [Step 1](#update-registry-dns) of the following procedure).

If you want to rebuild the WorkSpaces instead, update one of the DNS server IP addresses in your Active Directory ([Step 2](#update-dns-active-directory)), and then follow the procedure in [Rebuild a WorkSpace in WorkSpaces Personal](rebuild-workspace.md) to rebuild your WorkSpaces. After you've rebuilt your WorkSpaces, follow the procedure in [Step 3](#test-updated-dns-settings) to test your DNS server updates. After completing that step, update the IP address of your second DNS server in Active Directory, and then rebuild your WorkSpaces again. Be sure to follow the procedure in [Step 3](#test-updated-dns-settings) to test your second DNS server update. As noted in the [ Best Practices](#update-dns-best-practices) section, we recommend updating your DNS server IP addresses one at a time. 

## Best practices
<a name="update-dns-best-practices"></a>

When you're updating your DNS server settings, we recommend the following best practices:
+ To avoid disconnections and inaccessibility of domain resources, we strongly recommend performing DNS server updates during off-peak hours or during a planned maintenance period.
+ Don't launch any new WorkSpaces during the 15 minutes before and the 15 minutes after changing your DNS server settings.
+ When updating your DNS server settings, change one DNS server IP address at a time. Verify that the first update is correct before updating the second IP address. We recommend performing the following procedure ([Step 1](#update-registry-dns), [Step 2](#update-dns-active-directory), and [Step 3](#test-updated-dns-settings)) twice to update the IP addresses one at a time.

## Step 1: Update the DNS server settings on your WorkSpaces
<a name="update-registry-dns"></a>

In the following procedure, the current and new DNS server IP address values are referred to as follows:
+ Current DNS IP addresses: `OldIP1`, `OldIP2`
+ New DNS IP addresses: `NewIP1`, `NewIP2`

**Note**  
 If this is the second time you're performing this procedure, replace `OldIP1` with `OldIP2` and `NewIP1` with `NewIP2`.

### Update the DNS server settings for Windows WorkSpaces
<a name="update-registry-dns-windows"></a>

If you have multiple WorkSpaces, you can deploy the following registry update to the WorkSpaces by applying a Group Policy Object (GPO) on the Active Directory OU for your WorkSpaces. For more information about working with GPOs, see [Manage your Windows WorkSpaces in WorkSpaces Personal](group_policy.md).

You can make these updates either by using the Registry Editor or by using Windows PowerShell. Both procedures are described in this section.

**To update the DNS registry settings using the Registry Editor**

1. On your Windows WorkSpace, open the Windows search box, and enter **registry editor** to open the Registry Editor (**regedit.exe**). 

1. When asked "Do you want to allow this app to make changes to your device?", choose **Yes**.

1. In the Registry Editor, navigate to the following registry entry:

   **HKEY\$1LOCAL\$1MACHINE\$1SOFTWARE\$1Amazon\$1SkyLight**

1. Open the **DomainJoinDns** registry key. Update `OldIP1` with `NewIP1`, and then choose **OK**.

1. Close the Registry Editor.

1. Reboot the WorkSpace, or restart the service SkyLightWorkspaceConfigService.
**Note**  
After you restart the service SkyLightWorkspaceConfigService, it can take up to 1 minute for the network adapter to reflect the change.

1. Proceed to [Step 2](#update-dns-active-directory), and update your DNS server settings in Active Directory to replace `OldIP1` with `NewIP1`.

**To update the DNS registry settings using PowerShell**

The following procedure uses PowerShell commands to update your registry and restart the service SkyLightWorkspaceConfigService.

1. On your Windows WorkSpace, open the Windows search box, and enter **powershell**. Choose **Run as Administrator**.

1. When asked "Do you want to allow this app to make changes to your device?", choose **Yes**.

1. In the PowerShell window, run the following command to retrieve the current DNS server IP addresses.

   ```
   Get-ItemProperty -Path HKLM:\SOFTWARE\Amazon\SkyLight -Name DomainJoinDNS
   ```

   You should receive the following output.

   ```
   DomainJoinDns : OldIP1,OldIP2
   PSPath        : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Amazon\SkyLight
   PSParentPath  : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Amazon
   PSChildName   : SkyLight
   PSDrive       : HKLM
   PSProvider    : Microsoft.PowerShell.Core\Registry
   ```

1. In the PowerShell window, run the following command to change `OldIP1` to `NewIP1`. Be sure to leave `OldIP2` as is for now.

   ```
   Set-ItemProperty -Path HKLM:\SOFTWARE\Amazon\SkyLight -Name DomainJoinDNS -Value "NewIP1,OldIP2"
   ```

1. Run the following command to restart the service SkyLightWorkspaceConfigService.

   ```
   restart-service -Name SkyLightWorkspaceConfigService
   ```
**Note**  
After you restart the service SkyLightWorkspaceConfigService, it can take up to 1 minute for the network adapter to reflect the change.

1. Proceed to [Step 2](#update-dns-active-directory), and update your DNS server settings in Active Directory to replace `OldIP1` with `NewIP1`.

### Update the DNS server settings for Amazon Linux 2 WorkSpaces
<a name="update-registry-dns-linux"></a>

If you have more than one Amazon Linux 2 WorkSpace, we recommend that you use a configuration management solution to distribute and enforce policy. For example, you can use [Ansible](https://www.ansible.com/).

**To update the DNS server settings on a Amazon Linux 2 WorkSpace**

1. On your Linux WorkSpace, open a Terminal window.

1. Use the following Linux command to edit the `/etc/dhcp/dhclient.conf` file. You must have root user privileges to edit this file. Either become root by using the `sudo -i` command, or run all commands with `sudo` as shown.

   ```
   sudo vi /etc/dhcp/dhclient.conf
   ```

   In the `/etc/dhcp/dhclient.conf` file, you will see the following `prepend` command, where `OldIP1` and `OldIP2` are the IP addresses of your DNS servers.

   ```
   prepend domain-name-servers OldIP1, OldIP2; # skylight
   ```

1. Replace `OldIP1` with `NewIP1`, and leave `OldIP2` as is for now.

1. Save your changes to `/etc/dhcp/dhclient.conf`.

1. Reboot the WorkSpace.

1. Proceed to [Step 2](#update-dns-active-directory), and update your DNS server settings in Active Directory to replace `OldIP1` with `NewIP1`.

### Update the DNS server settings for Ubuntu WorkSpaces
<a name="update-registry-dns-ubuntu"></a>

If you have more than one Ubuntu WorkSpace, we recommend that you use a configuration management solution to distribute and enforce policy. For example, you can use [Landscape](https://ubuntu.com/landscape).

**To update the DNS server settings on a Ubuntu WorkSpace**

1. On your Ubuntu WorkSpace, open a Terminal window and run the following command. You must have root user privileges to edit this file. Either become root by using the `sudo -i` command, or run all commands with `sudo` as shown.

   ```
   sudo vi /etc/netplan/zz-workspaces-domain.yaml
   ```

1. In the yaml file, you will see the following `nameserver` command.

   ```
   nameservers:
       search:[Your domain FQDN]
       addresses:[OldIP1, OldIP2]
   ```

   Replace the `OldIP1` and `OldIP2` with the `NewIP1` and `NewIP2`.

   If you have multiple DNS servers IP addesses, add them as comma separated values. For example, `[NewDNSIP1, NewDNSIP2, NewDNSIP3]`.

1. Save the yaml file.

1. Run the command `sudo netplan apply` to apply the changes.

1. Run the command `resolvectl status` to verify that the new DNS IP address is being used.

1. Proceed to [Step 2](#update-dns-active-directory), and update your DNS server settings in Active Directory.

### Update the DNS server settings for Red Hat Enterprise Linux WorkSpaces
<a name="update-registry-dns-rhel"></a>

If you have more than one Red Hat Enterprise Linux WorkSpace, we recommend that you use a configuration management solution to distribute and enforce policy. For example, you can use [Ansible](https://www.ansible.com/).

**To update the DNS server settings on a Red Hat Enterprise Linux WorkSpace**

1. On your Red Hat Enterprise Linux WorkSpace, open a Terminal window and run the command below. You must have root user privileges to edit this file. Either become root by using the `sudo -i` command, or run all commands with `sudo` as shown.

   ```
   sudo nmcli conn modify CustomerNIC ipv4.dns 'NewIP1 NewIP2'
   ```

1. Run the following command.

   ```
   sudo systemctl restart NetworkManager
   ```

1. To check the updated DNS and network configuration run the following command.

   ```
   nmcli device show eth1
   ```

1. Proceed to [Step 2](#update-dns-active-directory), and update your DNS server settings in Active Directory.

## Step 2: Update the DNS server settings for Active Directory
<a name="update-dns-active-directory"></a>

In this step, you update your DNS server settings for Active Directory. As noted in the [Best Practices](#update-dns-best-practices) section, we recommend updating your DNS server IP addresses one at a time.

To update your DNS server settings for Active Directory, see the following documentation in the *AWS Directory Service Administration Guide*:
+ **AD Connector**: [ Update the DNS Address for Your AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_update_dns.html)
+ **AWS Managed Microsoft AD**: [ Configure DNS Conditional Forwarders for Your On-premises Domain](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust_prepare_onprem.html#tutorial_setup_trust_onprem_forwarder)
+ **Simple AD**: [ Configure DNS](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/simple_ad_dns.html)

After updating your DNS server settings, proceed to [Step 3](#test-updated-dns-settings).

## Step 3: Test the updated DNS server settings
<a name="test-updated-dns-settings"></a>

After completing [Step 1](#update-registry-dns) and [Step 2](#update-dns-active-directory), use the following procedure to verify that your updated DNS server settings are working as expected.

In the following procedure, the current and new DNS server IP address values are referred to as follows:
+ Current DNS IP addresses: `OldIP1`, `OldIP2`
+ New DNS IP addresses: `NewIP1`, `NewIP2`

**Note**  
If this is the second time you're performing this procedure, replace `OldIP1` with `OldIP2` and `NewIP1` with `NewIP2`.

### Test the updated DNS server settings for Windows WorkSpaces
<a name="test-updated-dns-settings-windows"></a>

1. Shut down the `OldIP1` DNS server.

1. Log in to a Windows WorkSpace.

1. On the Windows **Start** menu, choose **Windows System**, then choose **Command Prompt**.

1. Run the following command, where `AD_Name` is the name of your Active Directory (for example, `corp.example.com`).

   ```
   nslookup AD_Name
   ```

   The `nslookup` command should return the following output. (If this is the second time you're performing this procedure, you should see `NewIP2` in place of `OldIP2`.)

   ```
   Server:  Full_AD_Name
   Address:  NewIP1
   
   Name:    AD_Name
   Addresses:  OldIP2
             NewIP1
   ```

1. If the output is not what you were expecting or if you receive any errors, repeat [Step 1](#update-registry-dns).

1. Wait for an hour and confirm that no user issues have been reported. Verify that `NewIP1` is getting DNS queries and responding with answers.

1. After you've verified that the first DNS server is working properly, repeat [Step 1](#update-registry-dns) to update the second DNS server, this time replacing `OldIP2` with `NewIP2`. Then repeat Step 2 and Step 3. 

### Test the updated DNS server settings for Linux WorkSpaces
<a name="test-updated-dns-settings-linux"></a>

1. Shut down the `OldIP1` DNS server.

1. Log in to a Linux WorkSpace.

1. On your Linux WorkSpace, open a Terminal window.

1. The DNS server IP addresses returned in the DHCP response are written to the local `/etc/resolv.conf` file on the WorkSpace. Run the following command to view the contents of the `/etc/resolv.conf `file.

   ```
   cat /etc/resolv.conf
   ```

   You should see the following output. (If this is the second time you're performing this procedure, you should see `NewIP2` in place of `OldIP2`.)

   ```
   ; This file is generated by Amazon WorkSpaces
   ; Modifying it can make your WorkSpace inaccessible until reboot
   options timeout:2 attempts:5
   ; generated by /usr/sbin/dhclient-script
   search region.compute.internal
   nameserver NewIP1
   nameserver OldIP2
   nameserver WorkSpaceIP
   ```
**Note**  
If you make manual modifications to the `/etc/resolv.conf` file, those changes are lost when the WorkSpace is restarted.

1. If the output is not what you were expecting or if you receive any errors, repeat [Step 1](#update-registry-dns).

1. The actual DNS server IP addresses are stored in the `/etc/dhcp/dhclient.conf` file. To see the contents of this file, run the following command.

   ```
   sudo cat /etc/dhcp/dhclient.conf
   ```

   You should see the following output. (If this is the second time you're performing this procedure, you should see `NewIP2` in place of `OldIP2`.)

   ```
   # This file is generated by Amazon WorkSpaces
   # Modifying it can make your WorkSpace inaccessible until rebuild
   prepend domain-name-servers NewIP1, OldIP2; # skylight
   ```

1. Wait for an hour and confirm that no user issues have been reported. Verify that `NewIP1` is getting DNS queries and responding with answers.

1. After you've verified that the first DNS server is working properly, repeat [Step 1](#update-registry-dns) to update the second DNS server, this time replacing `OldIP2` with `NewIP2`. Then repeat Step 2 and Step 3. 

# Delete a directory for WorkSpaces Personal
<a name="delete-workspaces-directory"></a>

**Note**  
Simple AD and AD Connector are made 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/).  
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.

**What happens when you delete a directory:** When you delete a directory, the following occurs:
+ When a Simple AD or AWS Directory Service for Microsoft Active Directory directory is deleted, all of the directory data and snapshots are deleted and cannot be recovered. After the directory is deleted, any Amazon EC2 instances that are joined to the directory remain intact. You cannot, however, use your directory credentials to log in to these instances. You need to log in to these instances with an AWS account that is local to the instance.
+ When an AD Connector directory is deleted, your on-premises directory remains intact. Any Amazon EC2 instances that are joined to the directory also remain intact and remain joined to your on-premises directory. You can still use your directory credentials to log in to these instances.

## Delete an Entra ID or Custom WorkSpaces directory
<a name="delete-entra-custom"></a>

Entra ID WorkSpaces directory allows you to create Entra ID-joined Windows 10 or 11 BYOL WorkSpaces. For more information, see [Create a dedicated Microsoft Entra ID directory with WorkSpaces Personal](launch-entra-id.md).

Custom WorkSpaces directory allows you to create WorkSpaces that are not Active Directory domain-joined, but use your own device management software and IAM Identity Center. For more information, see [Create a dedicated Custom directory with WorkSpaces Personal](launch-custom.md).

**To delete an Entra ID or Custom WorkSpaces directory**

1. Delete all the WorkSpaces in the directory. For more information, see [Delete a WorkSpace in WorkSpaces Personal](delete-workspaces.md).

1. In the navigation pane, choose **Directories**.

1. Select the directory.

1. Choose **Actions**, **Delete**.

1. When prompted for confirmation, enter **delete**.

## Delete an AWS Directory Service directory
<a name="delete-aws-directory"></a>

You can delete the AWS Directory Service directory for your WorkSpaces if it is no longer in use by other WorkSpaces or other applications, such as WorkDocs, Amazon WorkMail, or Amazon Chime. Note that you must deregister a directory before you can delete it. 

**To deregister a directory**

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 the directory.

1. Choose **Actions**, **Deregister**.

1. When prompted for confirmation, choose **Deregister**. After deregistration is complete, the value of **Registered** is `No`.

**To delete a directory**

1. Delete all WorkSpaces in the directory. For more information, see [Delete a WorkSpace in WorkSpaces Personal](delete-workspaces.md).

1. Find and remove all of the applications and services that are registered to the directory. For more information, see [Delete Your Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_delete.html) in the *AWS Directory Service Administration 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 **Directories**.

1. Select the directory and choose **Actions**, **Deregister**.

1. When prompted for confirmation, choose **Deregister**.

1. Select the directory again and choose **Actions**, **Delete**.

1. When prompted for confirmation, choose **Delete**.
**Note**  
Removing application assignments can sometimes take more time than expected. If you receive the following error message, verify that you've removed all application assignments, and then wait 30 to 60 minutes before trying again to delete the directory:  

   ```
   An Error Has Occurred
   Cannot delete the directory because it still has authorized applications. 
   Additional directory details can be viewed at the Directory Service console.
   ```

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

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

# Set up Active Directory Administration Tools for WorkSpaces Personal
<a name="directory_administration"></a>

You'll perform most administrative tasks for your WorkSpaces directory using directory management tools, such as the Active Directory Administration Tools. However, you'll use the WorkSpaces console to perform some directory-related tasks. For more information, see [Manage directories for WorkSpaces Personal](manage-workspaces-directory.md).

If you create a directory with AWS Managed Microsoft AD or Simple AD that includes five or more WorkSpaces, we recommend that you centralize administration on an Amazon EC2 instance. Although you can install the directory management tools on a WorkSpace, using an Amazon EC2 instance is a more robust solution.

**To set up the Active Directory Administration Tools**

1. Launch an Amazon EC2 Windows instance and join it to your WorkSpaces directory by using one of the following options:
   + If you don't already have an existing Amazon EC2 Windows instance, you can join the instance to your directory domain when you launch the instance. For more information, see [Seamlessly join a Windows EC2 instance](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/launching_instance.html) in the *AWS Directory Service Administration Guide*.
   + If you already have an existing Amazon EC2 Windows instance, you can join it to your directory manually. For more information, see [Manually Add a Windows Instance](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/join_windows_instance.html) in the *AWS Directory Service Administration Guide*.

1. Install the Active Directory Administration Tools on the Amazon EC2 Windows instance. For more information, see [Installing the Active Directory Administration Tools](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/install_ad_tools.html) in the *AWS Directory Service Administration Guide*.
**Note**  
When you're installing the Active Directory Administration Tools, make sure to also select **Group Policy Management** to install the Group Policy Management Editor (**gpmc.msc**) tool.

   When the feature installation is finished, the Active Directory tools are available on the Windows **Start** menu under **Windows Administrative Tools**.

1. Run the tools as a directory administrator as follows:

   1. On the Windows **Start** menu, open **Windows Administrative Tools**.

   1. Hold down the Shift key, right-click the shortcut for the tool you want to use, and choose **Run as different user**.

   1. Enter the sign-in credentials for the administrator. With Simple AD, the username is **Administrator** and with AWS Managed Microsoft AD, the administrator is **Admin**.

You can now perform directory administration tasks using the Active Directory tools that you are familiar with. For example, you can use the Active Directory Users and Computers Tool to add users, remove users, promote a user to directory administrator, or reset a user password. Note that you must be logged into your Windows instance as a user that has permissions to manage users in the directory.

**To promote a user to a directory administrator**
**Note**  
This procedure applies only to directories created with Simple AD, not AWS Managed AD. For directories created with AWS Managed AD, see [ Manage Users and Groups in AWS Managed Microsoft AD](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) in the *AWS Directory Service Administration Guide*.

1. Open the Active Directory Users and Computers tool.

1. Navigate to the **Users** folder under your domain and select the user to promote.

1. Choose **Action**, **Properties**.

1. In the ***username* Properties** dialog box, choose **Member Of**.

1. Add the user to the following groups and choose **OK**.
   + **Administrators**
   + **Domain Admins**
   + **Enterprise Admins**
   + **Group Policy Creator Owners**
   + **Schema Admins**

**To add or remove users**  
You can create new users from the Amazon WorkSpaces console only during the process of launching a WorkSpace, and you cannot delete users through the Amazon WorkSpaces console. Most user management tasks, including managing user groups, must be performed through your directory. 

**Important**  
Before you can remove a user, you must delete the WorkSpace assigned to that user. For more information, see [Delete a WorkSpace in WorkSpaces Personal](delete-workspaces.md).

The process you use for managing users and groups depends on which type of directory you're using.
+ If you're using AWS Managed Microsoft AD, see [ Manage Users and Groups in AWS Managed Microsoft AD](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) in the *AWS Directory Service Administration Guide*.
+ If you're using Simple AD, see [ Manage Users and Groups in Simple AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/simple_ad_manage_users_groups.html) in the *AWS Directory Service Administration Guide*. 
+ If you use Microsoft Active Directory through AD Connector or a trust relationship, you can manage users and groups using the [ Active Directory module](https://docs.microsoft.com/powershell/module/activedirectory/).

**To reset a user password**  
When you reset the password for an existing user, do not set **User must change password at next logon**. Otherwise, the users cannot connect to their WorkSpaces. Instead, assign a secure temporary password to each user and then ask the users to manually change their passwords from within the WorkSpace the next time they log on.

**Note**  
If you're using AD Connector or if your users are in the AWS GovCloud (US-West) Region, 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 .)