Seamlessly map file shares for Amazon FSx for Windows File Server with AWS Auto Scaling

When managing a fleet of Windows instances, you often need a central repository for files that can be accessed from multiple locations. Having an automatically mapped Server Message Block (SMB) file share when your end-users connect to the domain-joined instances automates the repetitive and time-consuming task of mapping file shares manually to hundreds of new instances as they join your domain.

Amazon FSx for Windows File Server provides fully managed, reliable, and scalable file storage built on a Windows server that can be accessed over the industry-standard SMB protocol. It offers a rich set of data management and administrative features, such as user quotas, Active Directory (AD) integration, snapshots, backups, and encryption at rest and in transit. Amazon FSx file storage is accessible from Windows, Linux, and MacOS compute instances and devices running on AWS or on-premises. FSx for Windows File Server combined with AWS Auto Scaling lets you optimize your resources by scaling them based on your needs and simplifies management tasks.

In this post, I show how to configure an AWS Auto Scaling group to seamlessly join Amazon Elastic Compute Cloud (Amazon EC2) instances to a Microsoft AD using AWS Systems Manager. After this you can automatically map your Amazon FSx File Server shares by configuring a Group Policy Object (GPO) in your directory, reducing the manual interaction required.

Solution overview

The following solution architecture diagram presents an overview of the solution:

Figure 1: Solution architecture diagram for seamlessly map FSx for Windows file shares on AutoScaling instances

Auto Scaling launches Amazon EC2 instances using a specific tag. A Systems Manager association detects this new instance based on its tag and runs a Systems Manager Document containing information about your directory. This allows the instance to join automatically at launch. After the instance is part of the domain, a GPO previously configured in your AD applies to each user and makes the FSx for Windows File Server file shares available for your domain users.

Prerequisites

To perform the steps to achieve this, you must already have an AD domain managed in AWS. You can also use your self-managed AD if you prefer. For more information, check out the documentation on creating your AWS Managed Microsoft AD directory or joining an Amazon FSx file system to a self-managed Microsoft Active Directory domain (if you use this option). I am using a Microsoft Managed AD directory in this post.

You must also configure an Amazon Machine Image (AMI) based on an EC2 Windows instance that can be managed by Systems Manager. For more information, review the Systems Manager prerequisites. If you prefer to use a custom AMI, then learn how to create a standardized Amazon Machine Image (AMI) using Sysprep.

Note that this solution is limited to EC2 instances running in an Amazon Virtual Private Cloud (Amazon VPC) with access to public AWS service endpoints. For more information, check VPC endpoint restrictions and limitations.

Implement the solution

To implement the solution, I divided the steps into three parts:

Part A. How to seamlessly join an EC2 instance to your domain using Systems Manager.

1. Create a domain-join Systems Manager Document.
2. Create a new AWS Identity and Access Management (IAM) instance profile.
3. Create a Systems Manager State Manager association.

Part B. Configure AD GPOs to map your FSx for Windows File Server file shares when you log in with a domain user into a domain-joined computer.

1. Create an FSx for Windows File Server file system.
2. Create an AD Group Policy to deploy the share.

Part C. Integrate the solution with your Auto Scaling group.

1. Create a new launch template.
2. Create a new Auto Scaling group from the launch template.

Part A. How to seamlessly join an EC2 instance to your domain using Systems Manager

This part will cover the steps needed to configure AWS SSM to automatically join your instances to your domain. The steps include how to create a domain-join SSM document, how to create a new IAM instance profile and how to create a State Manager association to automate the operation.

 Step 1: Create a domain-join Systems Manager Document

Systems Manager enables you to remotely manage the configuration of your Windows EC2 instances by using Systems Manager Documents. These documents list the commands you want to run on an instance, such us aws:domainJoin, which instructs Systems Manager to join a Windows EC2 instance to a domain.

To create a Systems Manager document that contains your own domain-join configuration including the organizational unit to which you want to add the new server, follow these steps:

1. Go to the AWS Systems Manager Documents console.
2. Choose Create Document > Command or Session.
3. Under name, use “awsconfig_Domain_<directoryId>_<directoryName>” replacing <directoryId> and <directoryName> with your directory information. For example, “awsconfig_Domain_d-1234567890_example.com”.
4. For document type, select Command document.
5. In the content section, you can copy the following sample and replace the domain properties with your domain information.

{
  "schemaVersion": "1.0",
  "description": "Sample document for automatic Domain Join operation",
  "runtimeConfig": {
    "aws:domainJoin": {
      "properties": {
        "directoryId": "d-1234567890",
        "directoryName": "example.com",
        "directoryOU": "OU=test,OU=example,DC=example,DC=com",
        "dnsIpAddresses": [
          "198.51.100.1",
          "198.51.100.2"
        ]
      }
    }
  }
}

In this configuration document:

• directoryId is the ID of a directory (or AD Connector) that you created in AWS Directory Service.
• directoryName is the name of the domain (for example, example.com).
• directoryOU is the organizational unit (OU) for the domain.
• dnsIpAddresses includes the IP addresses for the DNS servers you specified when you created your directory (or AD Connector) in Directory Service.

6. Choose Create Document at the bottom of the page.

If you used the seamlessly domain-join feature before, then a document with the same name but without including the OU information already exists.

You can verify if the document exists using the Systems Manager Documents console under the tab Owned by me and filtering by “Document name prefix: Equals:” and the name of your document.

If the document exists, then you can safely delete the document and create a new one to include the OU information. This has no impact over instances already running.

Step 2: Create a new IAM instance profile

Create an instance profile role that Systems Manager can use to interact with AWS Directory Services and join your EC2 Windows instances to your AD domain.

Skip Step 2A by using the Amazon provided policies AmazonSSMManagedInstanceCore and AmazonSSMDirectoryServiceAccess. Note that these policies include additional permissions to enable all Systems Manager service core functionalities.

Step 2A: Create a custom IAM policy

Go to the IAM console and go to Policies in the left pane under the Access Management section.

Create the following policy named “SeamlessDomainJoinPolicy” based on the principle of least privilege that will be added to the instance profile role created in the next step. For more information on how to create the IAM policy, follow the steps outlined in creating policies on the JSON tab.

The example policy contains the minimum required permissions to join your instances to a single domain, using a specific Systems Manager document.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ds:DescribeDirectories",
                "ssm:CreateAssociation",
                "ssm:DescribeAssociation",
                "ssm:ListAssociations",
                "ssm:DescribeDocument",
                "ssm:UpdateAssociationStatus",
                "ssm:UpdateInstanceAssociationStatus",
                "ssm:UpdateInstanceInformation"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2messages:AcknowledgeMessage",
                "ec2messages:DeleteMessage",
                "ec2messages:FailMessage",
                "ec2messages:GetEndpoint",
                "ec2messages:GetMessages",
                "ec2messages:SendReply"
            ],
            "Resource": "*"
        },

        {
            "Effect": "Allow",
            "Action": "ssm:GetDocument",
            "Resource": "arn:aws:ssm:<region>::document/awsconfig_Domain_d-1234567890_example.com"
        },
       {
            "Effect": "Allow",
            "Action": "ds:CreateComputer",
            "Resource": "arn:aws:ds:<region>:111122223333:directory/d-1234567890"
        }

    ]
}

The first statement block in this policy allows Systems Manager to list and create the resources required to perform the domain join operation, including Directory Services permission to list the existing directories.

The second statement block allows Systems Manager to send and receive commands.

The third and fourth statement blocks include the required permissions for Systems Manager to use a specific Systems Manager document and for Directory Services to create AD computer objects in your directory exclusively.

Step 2b: Create a new IAM Role

The next step is to create an IAM role that uses the permissions set in our policy.

Go to Roles in the left pane of the IAM console and choose Create Role.

Create the IAM role using AWS Service EC2 as the trusted entity and select the policy created in the previous step under permissions.

Figure 2: Select type of trusted entity example in Create role menu

Name your new role “AutoScaling_SeamlessDomainJoin”, for example. For more information, review creating a role for an AWS Service (console).

Step 3: Create a Systems Manager State Manager association

After creating the IAM role and the Systems Manager Document, use State Manager to create an association. An association is a binding of the intent to a target specified by either a list of instance IDs, a Resource Group, or a tag query. The tag query is used in this example.

Whenever you launch a new instance preconfigured to use Systems Manager, the Systems Manager Agent looks for State Manager associations that apply to the managed instance. In this example, this check is based on a Amazon EC2 tag that is common to all new instances launched by our Auto Scaling group, for example key:SeamlessDomainJoin,Value:yes.

Systems Manager runs the association triggering the domain-join operation on the instances that use this specific key-value tag combination.

To create the State Manager association, follow these steps:

1. Go to the Systems Manager State Manager console and choose Create association.
2. Select the document you created in the Part A – Step 1 of this post.
3. Under the Targets section, select Specify instance tags.
4. Provide a key-value combination for the Amazon EC2 tag that you will use. For example, key:SeamlessDomainJoin,Value:yes.

Figure 3: Example of association targets selection in Create Association section in SSM console

5. There is no need to configure any of the other sections. However, you can configure the schedule or the rate control.
6. Choose Create Association.

For more information, learn the complete steps to create a Systems Manager association in create an association (console).

Part B. Configure AD GPOs to map your FSx for Windows File Server file shares when you log in with a domain user into a domain-joined computer

This part is divided in two steps: the creation of an FSx for Windows File Server file system and how to configure our AD GPO to map them automatically to the domain user profile.

Step 1: Create an FSx for Windows File Server file system

Your solution seamlessly joins your Windows EC2 instances to your domain at launch. Now you can continue to the second part of this solution.

Launch an FSx for Windows File Server. Step 1 on the Getting Started with Amazon FSx documentation provides you with information on how to create your file system. Under File System details, you can select the Deployment type (Multi-Availability Zone (AZ) or Single-AZ) and Storage type (SSD or HDD) based on your needs. The options you select in this section have no effect on the solution’s functionality.

Under Network & Security, you must make sure that you select the VPC and subnet where you want to launch your FSx for Windows File Server file system. Under Windows authentication, provide the Managed AD or self-managed AD information that you will use for this purpose.

Figure 4: Example of FSx Network & Security section of FSx console

Every FSx for Windows File Server file system comes with a default file share called “share” that can be accessed using the address \\<fsx-file-system-dns-name>\share. You can use the default file share or create additional file shares. For more information, see our File Shares documentation.

For this example, I created a folder within the default share called SeamlessMount.

To find the DNS name, go to the FSx for Windows File Server console, Windows File Server > Network & Security section.

Figure 5: DNS Name information location in the Amazon FSx console

Step 2: Create an Active Directory Group Policy to deploy the share

To make the shared folder automatically available for your users after logging into any domain-joined computer, modify or create a GPO and link it to your domain’s OU applied.

If you are using an AWS Managed AD, then the Default Domain Policy can’t be modified. Instead, an OU and an administrative account with delegated administrative rights for the OU is assigned to you.

You can create user accounts, groups, and policies within the OU by using standard Remote Server Administration Tools (RSAT). For more information see installing the Active Directory Administration Tools, or run the following PowerShell command to install the RSAT and Group Policy Management console in an EC2 instance: Install-WindowsFeature RSAT-ADDS,RSAT-DNS-Server,GPMC

Follow these steps to create and configure the GPO that applies in your domain:

1. In the GPMC go to Group Policy Objects and create a GPO. For this example, I named the GPO SeamlessFSxMount. You can do right click > Edit in the GPO and then go to User Configuration > Preferences > Windows Settings > Folders.
2. Create a new folder, SeamlessMount in my example, and assign the path as %APPDATA%\Microsoft\Windows\Network Shortcuts\yourfoldername. Select OK to commit the change.

Figure 6: Example of folder creation in GPMC

Within the Group Policy, select User Configuration>Preferences>Windows Settings>Ini Files

1. Create the first of two .ini file updates. The first update has the following settings:

a. Action set to Update.

b. File path: %APPDATA%\Microsoft\Windows\Network Shortcuts\yourfoldername\desktop.ini. In my example, this would be %APPDATA%\Microsoft\Windows\Network Shortcuts\SeamlessMount\desktop.ini.

c. Section Name: .ShellClassInfo (don’t forget the leading dot)

d. Property Name: CLSID2

e. Property Value: {0AFACED1-E828-11D1-9187-B532F1E9575D}

f. Select OK.

Figure 7: Example of CLSID2 .ini creation in GPMC

The second update is configured as:

a. Action: Update.

b. File path: %APPDATA%\Microsoft\Windows\Network Shortcuts\yourfoldername\desktop.ini.

c. Section Name: .ShellClassInfo (still remembering the dot).

d. Property Name: Flags.

e. Property Value is 2.

f. Choose OK.

Figure 8: Example of Flags .ini creation in GPMC

4. To complete, we must create a Group Policy Preferences Shortcut. Within the Group Policy, select User Configuration>Preferences>Windows Settings>Shortcuts.
5. Add a new Group policy shortcut with the following parameters:

a. Name: %APPDATA%\Microsoft\Windows\Network Shortcuts\yourfoldername\target (i.e., the full path to your folder, with a shortcut named target).

b. Target type: File System Object.

c. Target Path: your full FSx for Windows File Server folder name created earlier in Part 2 – Step 1. In my example, this would be \\amznfsxaa11bb22.example.com\share\SeamlessMount.

Figure 9: Example of shortcut creation in GPMC

6. Go back to the Group Policy Management console.
7. The final step is to link the GPO to the OU. Right-click in your OU > Link an existing GPO and select the one created from the list. Make sure that you apply GPO to the correct OU containing your User Objects.

Part C. Integrate the solution with your Auto Scaling group

Now that your instances can be joined to your domain at launch and your FSx for Windows File Server shares are mounted automatically when a domain user starts a session in any domain computer, proceed to integrating this with Auto Scaling.

Step 1: Create a new launch template

A launch template contains the parameters required that an Auto Scaling group uses to launch EC2 instances.

To complete this step, go to the Amazon EC2 console and go to Launch Templates in the left pane under the Instances section.

Follow the steps in our documentation under creating a launch template for an Auto Scaling group.

In the Advanced details section of the wizard, make sure you select the IAM role you created in Part A – Step 2 of this post containing the permissions to allow the operation to succeed.

Step 2: Create a new Auto Scaling group from the launch template

To finalize with the implementation, create an Auto Scaling group with these steps:

1. Go to Auto Scaling groups in the left pane of your Amazon EC2 console and choose Create Auto Scaling group.
2. Provide a unique name for your Auto Scaling group.
3. Select the launch template you created in the previous step.

Your configuration depends on your environment needs. I am using a default configuration that focuses on the relevant steps.

You can configure the Auto Scaling group based on your needs by selecting the network configuration, scaling policies, and notifications in the case that Auto Scaling adds or terminates an instance. For further details, see creating an Auto Scaling group using a launch template.

4. In Step 6, (Add tags), you must add the same Amazon EC2 tag that you used in the Systems Manager association creation step on this post. In my example, key:SeamlessDomainJoin,Value:yes. This tag can be added to new instances.

Figure 10: Example of Configure tags step in AutoScaling group creation console

After completing this step, Auto Scaling launches and terminates instances based on the scaling policy configured.

Your instances automatically join to your domain. When a user initiates a session, the group policies apply…

… and the users see the share folder mounted in any computer in the domain!

Figure 11: Group Policy Shortcuts policy applying at login

Figure 12: FSx Shared folder result

Cleaning up (optional): Schedule automatic clean-up of stale domain objects in your directory

As an Auto Scaling group scales out, instances are created and joined to your domain. As the Auto Scaling group scales in, instances are terminated, and the instances’ corresponding computer objects are not removed from your directory. Therefore, terminated instances result in stale entries.

An AD can hold a large number of computer objects, and it is good practice to schedule a script to remove stale entries from your directory. Alternatively, you can set up a script to unjoin a computer from your domain, and have that script run before instance shutdown. The underlying assumption of the second approach is that instances in an Auto Scaling group are only shut down (and terminated) when they are no longer needed.

Conclusion

In this post, I covered configuring your environment to seamlessly mount your Amazon FSx for Windows File Server file shares to the instances launched by your Auto Scaling group. I started by discussing configuring AWS Systems Manager to automatically join your new instances to your domain based on an Amazon EC2 tag using a Systems Manager association and how to create the required IAM instance profile role. In addition, I walked through launching an FSx for Windows File Server and how to configure a GPO within your AD to mount your shares when a user starts a session in a domain-joined computer. Finally, I went through using an Auto Scaling group to launch new instances that automatically join to your domain, apply the GPO, and show your shares already mounted.

This way I automated the repetitive and time-consuming task of mapping file shares manually to hundreds of new instances as they join a domain, reducing the manual interaction required and freeing up time for more important tasks.

Thanks for reading this post. We look forward to your feedback and questions in the comments section.