# Enable and Administer Persistent Storage for Your WorkSpaces Applications Users Amazon WorkSpaces Applications supports the following persistent storage options for users in your organization: + Home folders + Google Drive for Google Workspace + OneDrive for Business + Custom shared folders (Server Message Block (SMB) network drives) You can enable one or more options for your organization. As an WorkSpaces Applications administrator, you must understand how to perform the following tasks to enable and administer persistent storage for your users. **Topics** + [Enable and Administer Home Folders for Your WorkSpaces Applications Users](home-folders.md) + [Enable and Administer Google Drive for Your WorkSpaces Applications Users](google-drive.md) + [Enable and Administer OneDrive for Business for Your WorkSpaces Applications Users](onedrive.md) + [Enable and Administer Custom Shared Folders (Server Message Block (SMB) Network Drives) for Your WorkSpaces Applications Users](enable-smb-network-drives.md) For troubleshooting information, see [Troubleshooting Persistent Storage Issues](troubleshooting-persistent-storage.md). # Enable and Administer Home Folders for Your WorkSpaces Applications Users WorkSpaces Applications supports the following persistent storage options for users in your organization: + Home folders + Google Drive for Google Workspace + OneDrive for Business + Custom shared folders (Server Message Block (SMB) network drives) You can enable one or more options for your organization. When you enable home folders for an WorkSpaces Applications stack, users of the stack can access a persistent storage folder during their application streaming sessions. No further configuration is required for your users to access their home folder. Data stored by users in their home folder is automatically backed up to an Amazon Simple Storage Service bucket in your Amazon Web Services account and is made available to those users in subsequent sessions. Files and folders are encrypted in transit using Amazon S3's SSL endpoints. Files and folders are encrypted at rest using Amazon S3-managed encryption keys. Home folders are stored on fleet instances in the following default locations: + For single-session, non-domain-joined Windows instances: C:\$1Users\$1PhotonUser\$1My Files\$1Home Folder + For multi-session, non-domain-joined Windows instances: C:\$1Users\$1as2-xxxxxxxx\$1My Files\$1Home Folder , where as2-xxxxxxxxx is a random user name assigned to each user session. You can determine your local user name through env variable \$1USERNAME. + Domain-joined Windows instances: C:\$1Users\$1%username%\$1My Files\$1Home Folder + Linux instances: \$1/MyFiles/HomeFolder As an administrator, use the applicable path if you configure your applications to save to the home folder. In some cases, your users may not be able to find their home folder because some applications do not recognize the redirect that displays the home folder as a top-level folder in File Explorer. If this is the case, your users can access their home folder by browsing to the same directory in File Explorer. **Topics** + [Files and Directories Associated with Compute-Intensive Applications](storage-solutions-files-directories-associated-with-compute-intensive-applications.md) + [Enable Home Folders for Your WorkSpaces Applications Users](enable-home-folders.md) + [Administer Your Home Folders](home-folders-admin.md) # Files and Directories Associated with Compute-Intensive Applications During WorkSpaces Applications streaming sessions, saving large files and directories associated with compute-intensive applications to persistent storage can take longer than saving files and directories required for basic productivity applications. For example, it might take longer for applications to save a large amount of data or frequently modify the same files than it would to save files created by applications that perform a single write action. It might also take longer to save many small files. If your users save files and directories associated with compute-intensive applications and WorkSpaces Applications persistent storage options aren't performing as expected, we recommend that you use a Server Message Block (SMB) solution such as Amazon FSx for Windows File Server or an AWS Storage Gateway file gateway. Following are examples of files and directories associated with compute-intensive applications that are more suitable for use with these SMB solutions: + Workspace folders for integrated development environments (IDEs) + Local database files + Scratch space folders created by graphics simulation applications For more information, see: + [https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) + [Using Amazon FSx with Amazon WorkSpaces Applications ](https://aws.amazon.com/blogs/desktop-and-application-streaming/using-amazon-fsx-with-amazon-appstream-2-0/) + [File gateways](https://docs.aws.amazon.com/storagegateway/latest/userguide/StorageGatewayConcepts.html#file-gateway-concepts) in the *AWS Storage Gateway User Guide* # Enable Home Folders for Your WorkSpaces Applications Users Before enabling home folders, you must do the following: + Check that you have the correct AWS Identity and Access Management (IAM) permissions for Amazon S3 actions. For more information, see [Using IAM Policies to Manage Administrator Access to the Amazon S3 Bucket for Home Folders and Application Settings Persistence](s3-iam-policy.md). + Use an image that was created from an AWS base image released on or after May 18, 2017. For a current list of released AWS images, see [WorkSpaces Applications Base Image and Managed Image Update Release Notes](base-image-version-history.md). + Enable network connectivity to Amazon S3 from your virtual private cloud (VPC) by configuring internet access or a VPC endpoint for Amazon S3. For more information, see [Networking and Access for Amazon WorkSpaces Applications](managing-network.md) and [Using Amazon S3 VPC Endpoints for WorkSpaces Applications Features](managing-network-vpce-iam-policy.md). You can enable or disable home folders while creating a stack (see [Create a Stack in Amazon WorkSpaces Applications](set-up-stacks-fleets-install.md)), or after the stack is created by using the AWS Management Console for WorkSpaces Applications, AWS SDK, or AWS CLI. For each AWS Region, home folders are backed up by an Amazon S3 bucket. The first time you enable home folders for an WorkSpaces Applications stack in an AWS Region, the service creates an Amazon S3 bucket in your account in that same Region. The same bucket is used to store the content of home folders for all users and all stacks in that Region. For more information, see [Amazon S3 Bucket Storage](home-folders-s3.md). **Note** For guidance that you can provide your users to help them get started with using home folders during WorkSpaces Applications streaming sessions, see [Use Home Folders](home-folders-end-user.md). **To enable home folders while creating a stack** + Follow the steps in [Create a Stack in Amazon WorkSpaces Applications](set-up-stacks-fleets-install.md), and make sure that **Enable Home Folders** is selected. **To enable home folders for an existing stack** 1. Open the WorkSpaces Applications console at [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2). 1. In the left navigation pane, choose **Stacks**, and select the stack for which to enable home folders. 1. Below the stacks list, choose **Storage** and select **Enable Home Folders**. 1. In the **Enable Home Folders** dialog box, choose **Enable**. # Administer Your Home Folders Review the following topics to learn how to administer your home folders. **Topics** + [Disable Home Folders](home-folders-admin-disabling.md) + [Amazon S3 Bucket Storage](home-folders-s3.md) + [Home Folder Content Synchronization](home-folders-content-synchronization.md) + [Home Folder Formats](home-folders-admin-folders.md) + [Using the AWS Command Line Interface or AWS SDKs](home-folders-admin-cli.md) + [Additional Resources](home-folders-admin-additional.md) # Disable Home Folders You can disable home folders for a stack without losing user content already stored in home folders. Disabling home folders for a stack has the following effects: + Users who are connected to active streaming sessions for the stack receive an error message. They are informed that they can no longer store content in their home folder. + Home folders do not appear for any new sessions that use the stack with home folders disabled. + Disabling home folders for one stack does not disable it for other stacks. + Even if home folders are disabled for all stacks, WorkSpaces Applications does not delete the user content. To restore access to home folders for the stack, enable home folders again by following the steps described earlier in this topic. **To disable home folders while creating a stack** + Follow the steps in [Create a Stack in Amazon WorkSpaces Applications](set-up-stacks-fleets-install.md) and make sure that the **Enable Home Folders** option is cleared. **To disable home folders for an existing stack** 1. Open the WorkSpaces Applications console at [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2). 1. In the left navigation pane, choose **Stacks**, and select the stack. 1. Below the stacks list, choose **Storage** and clear **Enable Home Folders**. 1. In the **Disable Home Folders** dialog box, type `CONFIRM` (case-sensitive) to confirm your choice, then choose **Disable**. # Amazon S3 Bucket Storage WorkSpaces Applications manages user content stored in home folders by using Amazon S3 buckets created in your account. For every AWS Region, WorkSpaces Applications creates a bucket in your account. All user content generated from streaming sessions of stacks in that Region is stored in that bucket. The buckets are fully managed by the service without any input or configuration from an administrator. The new enhanced buckets are named in a specific format (Version 2) as follows: ``` appstream2-36fb080bb8-region-code-account-id-without-hyphens-random-identifier ``` Where `region-code` is the AWS Region code in which the stack is created and `account-id-without-hyphens` is your Amazon Web Services account ID. The first part of the bucket name, `appstream2-36fb080bb8-`, does not change across accounts or Regions. For example, if you enable home folders for stacks in the US West (Oregon) Region (us-west-2) on account number 123456789012, the service creates an Amazon S3 bucket in that Region with the name shown. Only an administrator with sufficient permissions can delete this bucket. ``` appstream2-36fb080bb8-us-west-2-123456789012-abcdefg ``` The old version buckets are named as follows. Accounts created before WorkSpaces Applications introduced the new enhanced bucket naming (Version 2) will follow the old naming format. ``` appstream2-36fb080bb8-region-code-account-id-without-hyphens ``` Where `region-code` is the AWS Region code in which the stack is created and `account-id-without-hyphens` is your Amazon Web Services account ID. The first part of the bucket name, `appstream2-36fb080bb8-`, does not change across accounts or Regions. For example, if you enable home folders for stacks in the US West (Oregon) Region (us-west-2) on account number 123456789012, the service creates an Amazon S3 bucket in that Region with the name shown. Only an administrator with sufficient permissions can delete this bucket. ``` appstream2-36fb080bb8-us-west-2-123456789012 ``` As mentioned earlier, disabling home folders for stacks does not delete any user content stored in the Amazon S3 bucket. To permanently delete user content, an administrator with adequate access must do so from the Amazon S3 console. WorkSpaces Applications adds a bucket policy that prevents accidental deletion of the bucket. For more information, see [Using IAM Policies to Manage Administrator Access to the Amazon S3 Bucket for Home Folders and Application Settings Persistence](s3-iam-policy.md). # Home Folder Content Synchronization When home folders are enabled, WorkSpaces Applications creates a unique folder for each user in which to store their content. The folder is created as a unique Amazon S3 prefix that uses a hash of the user name within an S3 bucket for your Amazon Web Services account and Region. After WorkSpaces Applications creates the home folder in Amazon S3, it copies the accessed content in that folder from the S3 bucket to the fleet instance. This enables the user to access their home folder content quickly, from the fleet instance, during their streaming session. Changes that you make to a user’s home folder content in an S3 bucket and that the user makes to their home folder content on a fleet instance are synchronized between Amazon S3 and WorkSpaces Applications as follows. 1. At the beginning of a user’s WorkSpaces Applications streaming session, WorkSpaces Applications catalogs the home folder files that are stored for that user in the Amazon S3 bucket for your Amazon Web Services account and Region. 1. A user’s home folder content is also stored on the WorkSpaces Applications fleet instance from which they stream. When a user accesses their home folder on the WorkSpaces Applications fleet instance, the list of cataloged files is displayed. 1. WorkSpaces Applications downloads a file from the S3 bucket to the fleet instance only after the user uses a streaming application to open the file during their streaming session. 1. After WorkSpaces Applications downloads the file to the fleet instance, synchronization occurs after the file is accessed 1. If the user changes the file during their streaming session, WorkSpaces Applications uploads the new version of the file from the fleet instance to the S3 bucket periodically or at the end of the streaming session. However, the file is not downloaded from the S3 bucket again during the streaming session. The following sections describe synchronization behavior when you add, replace, or remove a user's home folder file in Amazon S3. **Topics** + [Synchronization of files that you add to a user’s home folder in Amazon S3](#home-folders-content-synchronization-content-added-to-user-home-folder-in-S3) + [Synchronization of files that you replace in a user’s home folder in Amazon S3](#home-folders-content-synchronization-content-replaced-in-user-home-folder-S3) + [Synchronization of files that you remove from a user’s home folder in Amazon S3](#home-folders-content-synchronization-content-removed-from-user-home-folder-S3) ## Synchronization of files that you add to a user’s home folder in Amazon S3 If you add a new file to a user’s home folder in an S3 bucket, WorkSpaces Applications catalogs the file and displays it in the list of files in the user’s home folder within a few minutes. However, the file isn’t downloaded from the S3 bucket to the fleet instance until the user opens the file with an application during their streaming session. ## Synchronization of files that you replace in a user’s home folder in Amazon S3 If a user opens a file in their home folder on the fleet instance during their streaming session, and you replace the same file in their home folder in an S3 bucket with a new version during that user’s active streaming session, the new version of the file is not immediately downloaded to the fleet instance. The new version is downloaded from the S3 bucket to the fleet instance only after the user starts a new streaming session and opens the file again. ## Synchronization of files that you remove from a user’s home folder in Amazon S3 If a user opens a file in their home folder on the fleet instance during their streaming session, and you remove the file from their home folder in an S3 bucket during that user’s active streaming session, the file is removed from the fleet instance after the user does either of the following: + Opens the home folder again + Refreshes the home folder # Home Folder Formats The hierarchy of a user folder depends on how a user launches a streaming session, as described in the following sections. ## AWS SDKs and AWS CLI For sessions launched using `CreateStreamingURL` or `create-streaming-url` the user folder structure is as follows: ``` bucket-name/user/custom/user-id-SHA-256-hash/ ``` Where `bucket-name` is in the format shown in [Amazon S3 Bucket Storage](home-folders-s3.md) and `user-id-SHA-256-hash` is the user-specific folder name created using a lowercase SHA-256 hash hexadecimal string generated from the `UserId` value passed to the CreateStreamingURL API operation or `create-streaming-url` command. For more information, see [CreateStreamingURL](https://docs.aws.amazon.com/appstream2/latest/APIReference/API_CreateStreamingURL.html) in the *Amazon WorkSpaces Applications API Reference* and [create-streaming-url](https://docs.aws.amazon.com/cli/latest/reference/appstream/create-streaming-url.html) in the *AWS CLI Command Reference*. The following example folder structure applies to session access using the API or AWS CLI with a `UserId` testuser@mydomain.com, account id 123456789012 in the US West (Oregon) Region (us-west-2): ``` appstream2-36fb080bb8-us-west-2-123456789012/user/custom/a0bcb1da11f480d9b5b3e90f91243143eac04cfccfbdc777e740fab628a1cd13/ ``` You can identify the folder for a user by generating the lowercase SHA-256 hash value of the `UserId` using websites or open source coding libraries available online. ## SAML 2.0 For sessions created using SAML federation, the user folder structure is as follows: ``` bucket-name/user/federated/user-id-SHA-256-hash/ ``` In this case, `user-id-SHA-256-hash` is the folder name created using a lowercase SHA-256 hash hexadecimal string generated from the `NameID` SAML attribute value passed in the SAML federation request. To differentiate users who have the same name but belong to two different domains, send the SAML request with `NameID` in the format `domainname\username`. For more information, see [Amazon WorkSpaces Applications Integration with SAML 2.0](external-identity-providers.md). The following example folder structure applies to session access using SAML federation with `NameID` SAMPLEDOMAIN\$1testuser, account ID 123456789012 in the US West (Oregon) Region: ``` appstream2-36fb080bb8-us-west-2-123456789012/user/federated/8dd9a642f511609454d344d53cb861a71190e44fed2B8aF9fde0C507012a9901 ``` When part or all of the NameID string is capitalized (as the domain name *SAMPLEDOMAIN* is in the example), WorkSpaces Applications generates the hash value based on the capitalization used in the string. Using this example, the hash value for SAMPLEDOMAIN\$1testuser is 8DD9A642F511609454D344D53CB861A71190E44FED2B8AF9FDE0C507012A9901. In the folder for that user, this value is displayed in lowercase, as follows: 8dd9a642f511609454d344d53cb861a71190e44fed2B8aF9fde0C507012a9901. You can identify the folder for a user by generating the SHA-256 hash value of the `NameID` using websites or open source coding libraries available online. # Using the AWS Command Line Interface or AWS SDKs You can enable and disable home folders for a stack by using the AWS CLI or AWS SDKs. Use the following [create-stack](https://docs.aws.amazon.com/cli/latest/reference/appstream/create-stack.html) command to enable home folders while creating a new stack: ``` aws appstream create-stack --name ExampleStack --storage-connectors ConnectorType=HOMEFOLDERS ``` Use the following [update-stack](https://docs.aws.amazon.com/cli/latest/reference/appstream/update-stack.html) command to enable home folders for an existing stack: ``` aws appstream update-stack --name ExistingStack --storage-connectors ConnectorType=HOMEFOLDERS ``` Use the following command to disable home folders for an existing stack. This command does not delete any user data. ``` aws appstream update-stack --name ExistingStack --delete-storage-connectors ``` # Additional Resources For more information about managing Amazon S3 buckets and best practices, see the following topics in the *Amazon Simple Storage Service User Guide*: + You can provide offline access to user data for your users with Amazon S3 policies. For more information, see [Amazon S3: Allows IAM Users Access to Their S3 Home Directory, Programmatically and In the Console](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_s3_home-directory-console.html) in the *IAM User Guide*. + You can enable file versioning for content stored in Amazon S3 buckets used by WorkSpaces Applications. For more information, see [Using Versioning](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html). # Enable and Administer Google Drive for Your WorkSpaces Applications Users **Note** Amazon WorkSpaces Applications's use and transfer to any other app of information received from Google APIs will adhere to [Google API Services User Data Policy](https://developers.google.com/terms/api-services-user-data-policy), including the Limited Use requirements. Amazon WorkSpaces Applications supports the following persistent storage options for users in your organization: + Google Drive for Google Workspace + OneDrive for Business + Home folders You can enable one or more options for your organization. When you enable Google Drive for Google Workspace for an WorkSpaces Applications stack, users of the stack can link their Google Drive for Google Workspace account to WorkSpaces Applications. Then they can sign into their Google Drive for Google Workspace account and access their Google Drive folder during application streaming sessions. Any changes that they make to files or folders in Google Drive during those sessions are automatically backed up and synchronized, so that they are available to users outside of their streaming sessions. **Important** You can enable Google Drive for Google Workspace for accounts in your Google Workspace domains only, but not for personal Gmail accounts. **Note** You can enable Google Drive for Windows stacks, but not for Linux stacks or stacks associated with multi-session fleets. **Topics** + [Enable Google Drive for Your WorkSpaces Applications Users](enable-google-drive.md) + [Disable Google Drive for Your WorkSpaces Applications Users](disable-google-drive.md) # Enable Google Drive for Your WorkSpaces Applications Users Before enabling Google Drive, you must do the following: + Have an active Google Workspace account with a valid organizational domain and users in the domain to use with WorkSpaces Applications. + Configure an WorkSpaces Applications stack with an associated fleet. The fleet must use an image that uses a version of the WorkSpaces Applications agent released on or after May 31, 2018. For more information, see [WorkSpaces Applications Agent Release Notes](agent-software-versions.md). The fleet must also have access to the internet. + Add Amazon WorkSpaces Applications as a trusted app in one or more domains associated with your Google Workspace account. You can enable Google Drive for up to 10 domains. + Have a Windows-based stack. (Linux-based stacks are not supported). Follow these steps to add Amazon WorkSpaces Applications as a trusted app in your Google Workspace domains. **To add Amazon WorkSpaces Applications as a trusted app in your Google Workspace domains** 1. Sign in to the Google Workspace Admin console at [https://admin.google.com/](https://admin.google.com/). 1. In the left navigation sidebar, choose **Security**, **Access and data control**, **API controls**. 1. At the top of the page, in the **App access control** section, choose **MANAGE THIRD-PARTY APP ACCESS**. 1. Choose **Add app**, and then choose **OAuth App Name Or Client ID**. 1. Enter the Amazon WorkSpaces Applications OAuth client ID for your AWS Region, and then choose **SEARCH**. For a list of client IDs, see the table that follows this procedure. 1. In the search results, choose Amazon WorkSpaces Applications, and then choose **Select**. 1. In the **Client ID** page, under **OAuth Client ID**, verify that the correct ID appears in the list, and then select the check box to the left of the ID. 1. On the lower right of the page, choose **SELECT**. 1. Configure which organizational units in your Google Workspace organization should gain access. 1. Under **Access to Google Data**, choose **Trusted: Can access all Google services**, and then choose **CONTINUE**. 1. Review that the selections made are correct, then when you are satisfied, choose **FINISH**. 1. Verify that the Amazon WorkSpaces Applications app, with the correct OAuth ID, appears in the list of connected apps. **Amazon WorkSpaces Applications OAuth2 client IDs** | Region | Amazon WorkSpaces Applications OAuth client ID | | --- | --- | | US East (N. Virginia) | 266080779488-15n5q5nkiclp6m524qibnmhmbsg0hk92.apps.googleusercontent.com | | US East (Ohio) | 723951369598-6tvdlf52g2qh0qa141o4k1avasvnj51i.apps.googleusercontent.com | | US West (Oregon) | 1026466167591-i4jmemrggsjomp9tnkkcs5tniggfiujb.apps.googleusercontent.com | | Asia Pacific (Mumbai) | 325827353178-coqs1c374mf388ctllrlls374dc1bmb2.apps.googleusercontent.com | | Asia Pacific (Seoul) | 562383781419-am1i2dnvt050tmdltsvr36i8l2js40dj.apps.googleusercontent.com | | Asia Pacific (Singapore) | 856871139998-4eia2n1db5j6gtv4c1rdte1fh1gec8vs.apps.googleusercontent.com | | Asia Pacific (Sydney) | 151535156524-b889372osskprm4dt1clpm53mo3m9omp.apps.googleusercontent.com | | Asia Pacific (Tokyo) | 922579247628-qpl9kpihg3hu5dul2lphbjs4qbg6mjm2.apps.googleusercontent.com | | Canada (Central) | 872792838542-t39aqh72jv895c89thtk6v83sl6jugm2.apps.googleusercontent.com | | Europe (Frankfurt) | 643727794574-1se5360a77i84je9j3ap12obov1ib76q.apps.googleusercontent.com | | Europe (Ireland) | 599492309098-098muc7ofjfo9vua5rm5u9q2k3mlok3j.apps.googleusercontent.com | | Europe (London) | 682555519925-usbn2sk1ffgo8odgf23nj66ri71na0k5.apps.googleusercontent.com | | AWS GovCloud (US-East) | `20306576244-gqqkappmhhv9fj06sdk7as60he89e7ce.apps.googleusercontent.com` For more information about using WorkSpaces Applications in the AWS GovCloud (US) Regions, see [Amazon WorkSpaces Applications](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-appstream2.html) in the *AWS GovCloud (US) User Guide*. | | AWS GovCloud (US-West) | `996065833880-litfkb2vfd7c65nt7s24r7t8le5bc9bl.apps.googleusercontent.com` For more information about using WorkSpaces Applications in the AWS GovCloud (US) Regions, see [Amazon WorkSpaces Applications](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-appstream2.html) in the *AWS GovCloud (US) User Guide*. | | South America (São Paulo) | 891888628791-1ltbtedva29esqvqadiatlj4htcgcjfo.apps.googleusercontent.com | | Asia Pacific (Malaysia) | 526025990430-7u0f5r0rg4caj0impcs3atvatjtmdeld.apps.googleusercontent.com | | Israel (Tel Aviv) | 1089892007469-bkqfmc1sm3ahqrssjjp4ees1mmiuium0.apps.googleusercontent.com | | Europe (Milan) | 357829681601-84bcnr1ve68rthka1st5dboj0jgsrki7.apps.googleusercontent.com | | Europe (Spain) | 258457153543-0qbtkg4a99stlj12pi8sdqaetfb96b1s.apps.googleusercontent.com | | Europe (Paris) | 1018958878172-sgg1u1hlqiq8v53gdpq9aiu6ta48q1de.apps.googleusercontent.com | Follow these steps to enable Google Drive for your WorkSpaces Applications users. **To enable Google Drive while creating a stack** + Follow the steps in [Create a Stack in Amazon WorkSpaces Applications](set-up-stacks-fleets-install.md), make sure that **Enable Google Drive** is selected, and that you have specified at least one organizational domain associated with your Google Workspace account. **To enable Google Drive for an existing stack** 1. Open the WorkSpaces Applications console at [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2). 1. In the left navigation pane, choose **Stacks**, and select the stack for which to enable Google Drive. 1. Below the stacks list, choose **Storage** and select **Enable Google Drive for Google Workspace**. 1. In the **Enable Google Drive for Google Workspace** dialog box, in **Google Workspace domain name**, type the name of at least one organizational domain that is associated with your Google Workspace account. To specify another domain, choose **Add another domain**, and type the name of the domain. 1. After you add domain names, choose **Enable**. **Note** For guidance that you can provide your users to help them get started with using Google Drive during WorkSpaces Applications streaming sessions, see [Use Google Drive](google-drive-end-user.md). # Disable Google Drive for Your WorkSpaces Applications Users You can disable Google Drive for a stack without losing user content that is already stored on Google Drive. Disabling Google Drive for a stack has the following effects: + Users who are connected to active streaming sessions for the stack receive an error message. They are informed that they do not have permissions to access their Google Drive. + Any new sessions that use the stack with Google Drive disabled do not display Google Drive. + Only the specific stack for which Google Drive is disabled is affected. + Even if Google Drive is disabled for all stacks, WorkSpaces Applications does not delete the user content stored in their Google Drive. Follow these steps to disable Google Drive for an existing stack. **To disable Google Drive for an existing stack** 1. Open the WorkSpaces Applications console at [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2). 1. In the left navigation pane, choose **Stacks**, and select the stack for which to disable Google Drive. 1. Below the stacks list, choose **Storage**, and clear the **Enable Google Drive for Google Workspace** option. 1. In the **Disable Google Drive for Google Workspace** dialog box, type `CONFIRM` (case-sensitive) to confirm your choice, then choose **Disable**. When users of the stack start their next WorkSpaces Applications streaming session, they can no longer access their Google Drive folder from within that session and future sessions. # Enable and Administer OneDrive for Business for Your WorkSpaces Applications Users WorkSpaces Applications supports the following persistent storage options for users in your organization. + OneDrive for Business + Google Drive for Google Workspace + Home folders You can enable one or more options for your organization. When you enable OneDrive for Business for an WorkSpaces Applications stack, users of the stack can link their OneDrive for Business account to WorkSpaces Applications. Then they can sign into their OneDrive for Business account and access their OneDrive folder during application streaming sessions. Any changes that they make to files or folders in OneDrive during those sessions are automatically backed up and synchronized, so that they are available to users outside of their streaming sessions. **Important** You can enable OneDrive for Business for accounts in your OneDrive domains only, but not for personal accounts. WorkSpaces Applications requires that you configure your Microsoft Azure Active Directory environment to allow end-user consent to applications. For more information, see [Configure how end-users consent to applications](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-user-consent) in the Azure Active Directory [Application management](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/) documentation. The admin consent workflow lets administrators grant access to applications that require administrator approval. If the admin consent workflow is configured in your Azure Active Directory environment, follow the step given in [Enable OneDrive for Your WorkSpaces Applications Users](enable-onedrive.md) to specify the domains that require admin consent. **Note** You can enable OneDrive for Business for Windows stacks, but not for Linux stacks or stacks associated with multi-session fleets. **Topics** + [Enable OneDrive for Your WorkSpaces Applications Users](enable-onedrive.md) + [Disable OneDrive for Your WorkSpaces Applications Users](disable-onedrive.md) # Enable OneDrive for Your WorkSpaces Applications Users Before enabling OneDrive, you must do the following: + Have an active Microsoft Office 365 or OneDrive for Business account with a valid organizational domain and users in the domain to use with WorkSpaces Applications. + Configure an WorkSpaces Applications stack with an associated fleet. The fleet must use an image that uses a version of the WorkSpaces Applications agent released on or after July 26, 2018. For more information, see [WorkSpaces Applications Agent Release Notes](agent-software-versions.md). The fleet must also have access to the internet. + Have a Windows-based stack. (Linux-based stacks are not supported). Follow these steps to enable OneDrive for your WorkSpaces Applications users. **To enable OneDrive while creating a stack** + Follow the steps in [Create a Stack in Amazon WorkSpaces Applications](set-up-stacks-fleets-install.md), make sure that **Enable OneDrive** is selected, and that you have specified at least one organizational domain that is associated with your OneDrive for Business account. **To enable OneDrive for an existing stack** 1. Open the WorkSpaces Applications console at [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2). 1. In the left navigation pane, choose **Stacks**, and select the stack for which to enable OneDrive. 1. Below the stacks list, choose **Storage**, and select **Enable OneDrive for Business**. 1. In the **Enable OneDrive for Business** dialog box, in **OneDrive domain name**, type the name of at least one organizational domain that is associated with your OneDrive account. To specify another domain, choose **Add another domain**, and type the name of the domain. 1. For each domain, you can specify whether users need to get admin consent before linking their OneDrive for Business account to WorkSpaces Applications. **Require OneDrive for Business admin consent** is disabled by default. When you check the box, users are prompted to get the admin consent before linking their OneDrive for Business account. 1. After you add OneDrive domain names, choose **Enable**. Before your users can use OneDrive with WorkSpaces Applications, you must provide them with permissions to link their OneDrive account with third-party web applications. To do so, follow the steps in the next section. **Important** You must configure your Microsoft Azure Active Directory environment to allow end-user consent to applications. For more information, see [Configure how end-users consent to applications](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-user-consent) in the Azure Active Directory [Application management](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/) documentation. **Provide Your Users with Permissions to Link OneDrive with WorkSpaces Applications** You must enable Integrated Apps in your Office 365 or OneDrive for Business admin console before users can link their OneDrive for Business account to WorkSpaces Applications. 1. Sign in to Office 365 or the OneDrive for Business admin console. 1. In the left navigation pane of the console, choose **Settings**, **Services & add-ins**. 1. From the list of services and add-ins, choose **Integrated Apps**. 1. On the **Integrated apps** page, turn on the option to allow users in your organization to let third party web apps access their Office 365 information. **Note** For guidance that you can provide your users to help them get started with using OneDrive during WorkSpaces Applications streaming sessions, see [Use OneDrive for Business](onedrive-end-user.md). # Disable OneDrive for Your WorkSpaces Applications Users You can disable OneDrive for a stack without losing user content that is already stored on OneDrive. Disabling OneDrive for a stack has the following effects: + Users who are connected to active streaming sessions for the stack receive an error message. They are informed that they do not have permissions to access their OneDrive. + Any new sessions that use the stack with OneDrive disabled do not display OneDrive. + Only the specific stack for which OneDrive is disabled is affected. + Even if OneDrive is disabled for all stacks, WorkSpaces Applications does not delete the user content stored in their OneDrive. Follow these steps to disable OneDrive for an existing stack. **To disable OneDrive for an existing stack** 1. Open the WorkSpaces Applications console at [https://console.aws.amazon.com/appstream2](https://console.aws.amazon.com/appstream2). 1. In the left navigation pane, choose **Stacks**, and select the stack for which to disable OneDrive. 1. Below the stacks list, choose **Storage**, and clear **Enable OneDrive for Business** option. 1. In the **Disable OneDrive for Business** dialog box, type `CONFIRM` (case-sensitive) to confirm your choice, then choose **Disable**. When users of the stack start their next WorkSpaces Applications streaming session, they can no longer access their OneDrive folder from within that session and future sessions. # Enable and Administer Custom Shared Folders (Server Message Block (SMB) Network Drives) for Your WorkSpaces Applications Users You can enable one or more options for your organization. When you enable and map the Server Message Block (SMB) network drives, multiple users can access the same data from Windows WorkSpaces Applications sessions. Any changes that users make to SMB network drives during those sessions are automatically backed up and synchronized. **Note** Server Message Block (SMB) network drives mapping are supported only on domain-joined fleets To use this feature, you must use an WorkSpaces Applications image that uses the WorkSpaces Applications agent released after September 18, 2024. For more information, see [Manage WorkSpaces Applications Agent Versions](base-images-agent.md) and [WorkSpaces Applications Base Image and Managed Image Update Release Notes](base-image-version-history.md). Before you map Server Message Block (SMB) network drives, ensure that for inbound rules, the security group that your users use to connect to fleets exposes TCP port 445 (SMB protocol) to the domain controller and the security group. **Topics** + [Map Server Message Block (SMB) Network Drives](map-smb-network-drives.md) # Map Server Message Block (SMB) Network Drives You can use any machine that is under the targeted network of the SMBs. If you prefer to configure the setup through session scripts, you need to first create a script that gets invoked when user is logged on, as session script is configured per image. To map Server Message Block (SMB) network drives, do the following steps. ## Step 1: Ensure services are running From the Start Menu, open **services.msc** and make sure the following services are all running: + DNS Client + Function Discovery Resource Publication + SSDP Discovery + UPnP Device Host ## Step 2: Create a SMB folder You can create an SMB with File Explorer. **To use File Explorer to configure your SMB shared folders** 1. Right-click the SMB folder and choose **Properties**, **Sharing**. 1. Choose **Advanced Sharing**. 1. For **Advanced Sharing**, check **Share this folder**, and then choose **Permissions**. 1. If you want to provide permissions for all your users, leave it as the default setting. If you want to add specific users, under **Share Permissions**, choose **Everyone**, **Remove**. Then choose **Add** and enter the users or groups you want to access the file share. For each user or group you add, choose **Allow** to assign **Full Control**, **Change**, or **Read permissions**. 1. Choose **Apply**, **OK**, **OK**, **Close**. ## Step 3: Verify that the SMB is accessible in the domain Open the file explorer from another server that uses the same security group and joins to the same domain. Access the network share through the provided network path by navigating to the network path folder. Choose **Properties**, **Sharing**, **Network Path**. ## Step 4: Enable users to create symbolic links from local/domain Group Policy Enable creating symbolic links from local/domain Group Policy for your users to ensure the session script or logon script defined in group policy. This allows you to create a script in Step 5 with user permissions. **To enable users to create symbolic links from local/domain Group Policy** 1. In the GPO, which will be used to define this policy, choose **Computer Configuration**, **Windows Settings**, **Security Settings**, **User Rights Assignment**, **Policy**, **Create symbolic links**. Then, update the permission for users to include. For more information about creating symbolic links, see [ Create symbolic links](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/create-symbolic-links). 1. By default, remote-to-remote (for example, a symlink mapping to a network share within another similar symlink) and remote-to-local (for example, a symlink mapping to a local share within a symlink mapping to a network share) accesses are disabled. If symlink mapping is needed, run the commands below: + For enabling remote-to-remote access - `fsutil behavior set SymlinkEvaluation R2R:1` + For enabling remote-to-local access - `fsutil behavior set SymlinkEvaluation R2L:1 ` ## Step 5: Create a script that gets invoked when user is logged on Create a script that gets invoked when user is logged on by either using an WorkSpaces Applications session script or GPO logon script. If you choose to use the WorkSpaces Applications session script, the session script will only get applied to that specific WorkSpaces Applications image. If you use the GPO logon script, the GPOs will be applied to the domain / OU, which can be configured to your fleets. That way you don’t need configure scripts for every image that you own. ### Option 1: Use a session script to mount the SMB shared folder under My Files (using Powershell) **To use a session script to mount the SMB shared folder under My Files (using Powershell)** 1. After you’ve successfully defined user permissions, configure the following example script using user context or system context. The following is the example config.json script that uses user context. ``` "SessionStart": { "executables": [ { "context": "system", "filename": "", "arguments": "", "s3LogEnabled": true }, { "context": "user", "filename": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe", "arguments": "-File \"C:\\AppStream\\SessionScripts\\userStart.ps1\"", "s3LogEnabled": true } ], "waitingTime": 30 ``` The following is the example script that uses system context. ``` "SessionStart": { "executables": [ { "context": "system", "filename": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe", "arguments": "-File \"C:\\AppStream\\SessionScripts\\systemStart.ps1\"", "s3LogEnabled": true }, { "context": "user", "filename": "", "arguments": "", "s3LogEnabled": true } ], "waitingTime": 30 ``` 1. If you're using multi-session fleets, you can use the system environment variable `$env:AppStream_Session_UserName` to navigate to the your user's My Files folder. This allows mapping to `Admin` instead of the user name when using the system context `$env:USERNAME`. ``` # Define the target application path $targetPathes = "" # Define the shortcut location $symlinkLocation = "C:\Users\$Env:AppStream_Session_UserName\My Files\Custom Folder" # Create the junction for Custom Home Folder under MyFiles New-Item -ItemType SymbolicLink -Path $symlinkLocation -Target $targetPaths ``` ### Option 2: Use GPO Logon Script to mount SMB shared folders to be under My Files 1. Mount SMB shared folders by creating a symbolic fink to a file or folder. For more information, see [ Example 7: Create a symbolic link to a file or folder](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell. management/new-item?view=powershell-7.4#example-7-create-a-symbolic-link-to-a-file-or-folder) 1. [Assign user logon scripts.](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server- 2012-r2-and-2012/dn789196(v=ws.11)#how-to-assign-user-logon-scripts) 1. Add the following script to create a junction for Custom Home Folders, under My Files. ``` # Define the target application path $targetPathes = "" # Define the shortcut location $symlinkLocation = "C:\Users\$env:Username\My Files\Custom Folder" # Create the junction for Custom Home Folder under MyFiles New-Item -ItemType SymbolicLink -Path $symlinkLocation -Target $targetPaths ``` If you are using Windows Server 2022 images, you might experience an issue where your My Files folder doesn't get created until the Logon Script is completed successfully. This might can cause a timeout when your SMB mounting operation is done through Logon Script. To resolve this issue, while also mounting your SMB, trigger an independent process (`Start-Process`) using your Logon Script by doing the following: 1. Create a Logon Script. ``` # Define the log file path $logFilePath = "" # Function to write log messages function Write-Log { param ( [string]$message ) $timestamp = get-date -format "yyyy-MM-dd HH:mm:ss" $logMessage = "$timestamp - $message" $logMessage | Out-File -FilePath $logFilePath -Append -Encoding UTF8 } try { Write-Log "Setting execution policy..." Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force Write-Log "Unblocking logon script file..." $filePath = "" Unblock-File -Path $filePath Write-Log "Running actual logon script..." Start-Process -FilePath 'Powershell.exe' -ArgumentList "-File `"$filePath`"" } catch { Write-Log "An error occurred: $_" "ERROR" } ``` 1. Update this Logon Script delay configuration using Group Policy, if needed. For more information, see [ Configure Logon Script Delay](https://admx.help/?Category=Windows_8.1_2012R2&Policy=Microsoft.Policies.GroupPolicy::LogonScriptDelay). Logon Script delay will be the amount for time it will delay before triggering your async Logon Script. The default delay is 5 minutes. 1. Restart your fleet to apply the Logon Script delay.