© Brian Beach, Steven Armentrout, Rodney Bozo, Emmanuel Tsouris 2019
B. Beach et al.Pro PowerShell for Amazon Web Serviceshttps://doi.org/10.1007/978-1-4842-4850-8_13

13. Amazon WorkSpaces and Amazon AppStream 2.0

Brian Beach1 , Steven Armentrout2, Rodney Bozo3 and Emmanuel Tsouris4
(1)
Raleigh, NC, USA
(2)
Mountlake Terrace, WA, USA
(3)
Sterling, VA, USA
(4)
North Bend, WA, USA
 

An important area in which cloud can add value to your organization is in End-User Computing; this is because you are able to quickly and easily provision virtual desktops, streaming applications, without the need of purchasing expensive hardware and making a long-term financial commitment. There are two specific End-User Computing AWS services which we will focus on, Amazon WorkSpaces and Amazon AppStream 2.0. These services provide users access to their documents, applications, and other resources, from anywhere and anytime, as long as they, users, are on a supported device. These services both provide a pay-as-you-go model and also give you the flexibility to always have the resources running or run them when you need them.

Amazon WorkSpaces is a cloud-based virtual desktop service, which offers both Windows and Linux desktop environments. These virtual desktops can be accessed from any supported client, downloadable from AWS or your favorite mobile app store. Benefits of the service include centralized management, repeatability, and flexibility, as well as the ability to publish or install application packages, with various licensing options.

Amazon AppStream 2.0 is also an End-User Computing service, but unlike Amazon WorkSpaces, there is no need to deploy a desktop environment to grant your users access to your applications. The applications can be imported to AWS and published, made accessible via your favorite HTML5-compatible browser. There are also security benefits for using AppStream 2.0, because data is not stored on the end-user devices.

Amazon WorkSpaces Architecture

We will begin with Amazon WorkSpaces by provisioning virtual desktops via PowerShell. In order to move forward, there are certain things that we need to determine, such as the region and the operating system to use, Windows or Amazon Linux desktops are available. Once we have selected the right region and operating system, we will need to determine the right hardware resource configuration, as this will directly impact the performance of the desktop’s user experience.

Once the user experience configuration options have been identified, the next thing to determine is whether Simple AD, AD Connector, or AWS Managed Microsoft AD will be used for authentication and resource management services. Depending on the directory being used, the configuration and management options may vary.

Figure 13-1 depicts the Amazon WorkSpaces architecture, which outlines the WorkSpaces architecture and network requirements which use AWS Directory Service for authentication. If selecting the Quick Setup, which is one of the deployment options, Simple AD will be deployed. If customization for Managed AD or AD Connector is needed, then an Advanced Setup configuration is required.
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig1_HTML.jpg
Figure 13-1

WorkSpaces architecture using Managed Microsoft AD

Client Requirements

The Amazon WorkSpaces virtual desktop service is accessible via client application that is available for various supported devices.

Client applications are available for the following devices:

  • Windows computers

  • Mac computers

  • Chromebooks

  • iPads

  • Android tables

  • Fire tables

  • Zero client devices

Browser-based access is also available for Windows WorkSpaces, for the following supported browsers:

  • Chrome 53 and later

  • Firefox 49 and later

Managing Amazon WorkSpaces

In order to get started with launching Amazon WorkSpaces, we have to go to the WorkSpaces console to complete this task. Once the WorkSpaces service has been deployed, the management of the resources can be performed via PowerShell.

Basic Setup

The following steps show you how to perform the basic setup:
  1. 1.

    From the Amazon WorkSpaces Console, click the Get Started Now link.

     
  2. 2.

    Once on the Get Started with Amazon WorkSpaces page, there will be an option for selecting either a Quick Setup or an Advanced Setup. See Figure 13-2.

     
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig2_HTML.jpg
Figure 13-2

Basic or Advanced Setup selection window

If the Quick Setup is selected, the following tasks will be completed:
  1. a.

    IAM role, workspaces_DefaultRole, with permissions to create Elastic Network Interfaces and also list WorkSpaces directories.

     
  2. b.

    Creates a VPC.

     
  3. c.

    Sets up and configures Simple AD, which will be used to store user and WorkSpaces resources objects.

     
  4. d.

    A service account will be created to add WorkSpaces to the directory.

     
  5. e.

    Creates WorkSpace desktop environments with a public IP address.

     
  6. f.

    Sends e-mail communications to the designated WorkSpaces users.

    On the other hand, if the Advanced Setup is selected, you will have the flexibility to configure the setup that meets your business needs, including having the ability to determine whether to use an AD Connector, a Simple AD, or a Managed Microsoft AD domain, with or without the use of a Trusted Domain. If the latter option is selected, then you will need to make sure the VPC, subnets, and availability zones, as well as the directory components, are properly configured.

     
  7. 3.
    The next thing in the Quick Setup option is to select a Bundle, as shown in Figure 13-3, which is a package that is optimized for a particular use case, and comes with a set of predetermined resources (e.g., CPU and Memory) and applications (e.g., Microsoft Office).
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig3_HTML.jpg
    Figure 13-3

    Bundle selection window

     
  8. 4.
    Once a bundle is selected, the next step will allow you to create an Amazon WorkSpaces user in the Simple AD directory previously created, as well as notify the user about the availability of their WorkSpaces instance. See Figure 13-4.
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig4_HTML.jpg
    Figure 13-4

    WorkSpaces user assignment form

     
  9. 5.

    The last step is to select the Launch WorkSpaces button to launch the instance.

     

Connecting to Your WorkSpaces

Once an e-mail invitation is sent, the user who received the invitation can connect to their WorkSpace by downloading their preferred client from the link included in the invitation:
  1. 1.

    In the invitation e-mail, there will be instructions included to set up credentials. Follow the instructions to set up your credentials.

     
  2. 2.

    Once the credentials have been set up, you will be prompted to download the client.

     
  3. 3.

    After downloading and installing the WorkSpaces client, start it. At the prompt, enter the registration code included in the e-mail and select Register.

     
  4. 4.

    In the sign-in prompt, enter your username and password, and click Sign In.

     

Advanced Setup

As previously mentioned, the Advanced Setup option offers the flexibility to be explicit on the networking and directory configurations.

Creating WorkSpaces with Microsoft AD
As you may have guessed, the instructions provided in Chapter 12, AWS Directory Service, can be used to create a Microsoft AD directory and leveraged with Amazon WorkSpaces:
  1. 1.

    To create a Microsoft AD, follow the instructions provided in Chapter 12.

     
  2. 2.
    Go to the WorkSpaces Console, and click the Directories link (Figure 13-5).
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig5_HTML.jpg
    Figure 13-5

    Directory selection option

     
  3. 3.

    The Directories list should include the list of available directories, including any directory using Microsoft AD, AD Connector, or Simple AD. Select the Microsoft AD directory to be used with WorkSpaces, then click the Actions link, and finally select the Register.

     
  4. 4.
    When prompted, confirm directory registration by selecting Register (Figure 13-6).
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig6_HTML.jpg
    Figure 13-6

    Directory registration option

     
  5. 5.
    The registration will take a few minutes, wait until the registration is complete, as shown in Figure 13-7.
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig7_HTML.jpg
    Figure 13-7

    Directory registration confirmation page

     
  6. 6.

    Once the registration is complete, we will be able to launch WorkSpaces via PowerShell. See the next section for detailed instructions.

     
Creating WorkSpaces with AD Connector
The instructions for connecting WorkSpaces to AD Connector were also included in Chapter 12. However, for completeness, we will also provide the instructions in this section:
  1. 1.

    Follow the instructions provided in Chapter 12 to create an AD Connector.

     
  2. 2.
    Go to the WorkSpaces Console, and click the Directories link (Figure 13-8).
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig8_HTML.jpg
    Figure 13-8

    List of directories available to select

     
  3. 3.

    The Directories list should include the list of available directories, including any directory using Microsoft AD, AD Connector, or Simple AD. Select the AD Connector to be used with WorkSpaces, then click the Actions link, and finally select the Register.

     
  4. 4.
    When prompted, confirm directory registration by selecting Register (Figure 13-9).
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig9_HTML.jpg
    Figure 13-9

    Register directory page

     
  5. 5.
    The registration will take a few minutes, wait until the registration is complete. See Figure 13-10.
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig10_HTML.jpg
    Figure 13-10

    Directory registration confirmation page

     
  6. 6.

    Once the registration is complete, we will be able to launch WorkSpaces via PowerShell. See the next section for detailed instructions.

     
Launching New WorkSpace

In order to launch a new WorkSpace, we will store required parameters for deploying a virtual desktop into variables.

The first variable we will store is for the directory object for the active Microsoft AD directory associated with WorkSpaces.
$WKSManagedAD = Get-WKSWorkspaceDirectory | where-object {($_.DirectoryType -like 'MicrosoftAD')}

Note

If there are multiple Microsoft AD directories, it would be recommended to filter for a directory ID, instead of filtering by a directory type. See the following example.

$WKSManagedAD_Id = Get-WKSWorkspaceDirectory | where-object {($_.DirectoryId -eq 'd-XXXXXXX')}

The next parameter we will need to store as a variable, in order to deploy WorkSpaces, is of the WorkSpaces Bundle. As previously mentioned, a Bundle is a predetermined set of packages that include software and virtual hardware resources (e.g., Windows 7 and 8GB of Memory).
$WKSBundle = Get-WKSWorkspaceBundle -Owner Amazon | where-object {($_.Name -eq 'Value with Windows 7')}
Once we have those objects stored in variables, we will use the following command to create a WorkSpace assigned for the CORPBob user, which is a domain user in the Microsoft AD directory we previously created.
$WorkSpace = New-WKSWorkspace -Workspace @{"BundleID" = $WKSBundle.BundleId; "DirectoryId" = $WKSManagedAD.DirectoryId; "UserName" = "admin"}

Note

Since multiple components need to be created and configured to launch a WorkSpace (e.g., ENI, security groups, etc.), the creation process may take some time.

If deploying the WorkSpace against AD Connector, the directory information can be stored with the following command:
$WKSADConnector = Get-WKSWorkspaceDirectory | where-object {($_.DirectoryType -like 'AD_Connector')}
Managing WorkSpace

Once the WorkSpace is fully launched, we can begin managing it.

As an administrator, there are often times when you need uninterrupted access to a system, making sure that other users don’t make reboot, start, stop, or rebuild the system. In these cases, the WorkSpace can be put into an ADMIN_MAINTENANCE mode, which prevents the execution of API calls that will run the operations listed previously. See Figure 13-11.
Edit-WKSWorkspaceState -WorkspaceId $Workspace.WorkspaceId -WorkspaceState ADMIN_MAINTENANCE
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig11_HTML.jpg
Figure 13-11

Viewing the Status change triggered by the previous command

Once the dedicated access to the virtual desktop is no longer required, then with a simple command, as shown as follows, this can be changed.
Edit-WKSWorkspaceState -WorkspaceId $Workspace.WorkspaceId -WorkspaceState AVAILABLE

Another example of modifying a workstation is changing the resources associated with the bundle that was selected during deployment. In this example, the command provided as follows can be used to change the compute type from its current value to something that better meets a customer’s business needs.

Note

WorkSpace’s properties can’t be changed within 6 hours of creation (i.e., 21,600 seconds).

Modify Compute Type
The bundle associated with a WorkSpace can be edited by changing the property associated with that setting. The following example will change the compute type from Value, which was specified when created, to Standard:
Edit-WKSWorkspaceProperty -WorkspaceId $Workspace.WorkspaceId -WorkspaceProperties_ComputeTypeName STANDARD
Additional values for the compute type property are the following (Figure 13-12):

  • Graphics – Includes 8 vCPUs, 15GiB of Memory, 1 vGPU, 4GiB of Video Memory, and 100GB of SSD Root Volume and also User Storage

  • Performance – Includes 2 vCPUs, 7.5GiB of Memory, and 175GB of SSD Root Volume and 100GB of User Storage

  • Power – Includes 4 vCPUs, 16GiB of Memory, and 80GB of SSD Root Volume and 100GB of User Storage

  • Standard – Includes 2 vCPUs, 4GiB of Memory, and 80GB of SSD Root Volume and 75GB of User Storage

  • Value – Includes 1 vCPU, 2GiB of Memory, and 80GB of SSD Root Volume and 10GB of User Storage

../images/319650_2_En_13_Chapter/319650_2_En_13_Fig12_HTML.jpg
Figure 13-12

Amazon WorkSpaces Bundles options

In addition to being able to edit the compute type attribute, the following attributes can also be modified:

  • WorkspaceProperties_RootVolumeSizeGib – Specifies the size of the root volume, in Gib

  • WorkspaceProperties_RunningMode – Sets the attribute between ALWAYS_ON and AUTO_STOP

  • WorkspaceProperties_RunningModeAutoStopTimeoutInMinute – Provides the ability to set the auto stop time, in 60 minutes increments

  • WorkspaceProperties_UserVolumeSizeGib – Sets the attribute for the user volume, in GiB

As an additional example, we will change the default running mode of the virtual desktop we created and change the WorkSpace to auto stop.
Edit-WKSWorkspaceProperty -WorkspaceId $Workspace.WorkspaceId -WorkspaceProperties_RunningMode AUTO_STOP
To view the current properties of the existing WorkSpaces, the following command can be fun:
get-wksworkspace | format-list
In most cases, organizations will have more than one WorkSpace; therefore, it is important to only focus on getting details of the WorkSpaces we care about. In this case, we will filter on the username property, but we can use any WorkSpace property as a filter.
Get-WKSWorkspace | where-object {($_.UserName -eq 'Bob')} | format-list
Tagging a WorkSpace
Tagging a WorkSpace is something useful and in some cases required for managing resources effectively. To tag WorkSpaces, we can run the following command to both create the object with the tag and set the properties to the correct values. Once the object has the right data, we can run the New-WKSTag cmdlet to set tag(s) for a WorkSpace.
$WKSTag = New-Object Amazon.WorkSpaces.Model.Tag
$WKSTag.Key = "Name"
$WKSTag.Value = "Development"
New-WKSTag -WorkspaceId $Workspace.WorkspaceId -Tag $WKSTag

Typical administrator and end-user tasks are starting, stopping, or restarting a WorkSpace.

Starting a WorkSpace
To start a WorkSpace, use the following command:
Start-WKSWorkspace -WorkspaceId $Workspace.WorkspaceId
Stopping a WorkSpace
On the other hand, if a WorkSpace needs to get stopped, the following command can be used:
Stop-WKSWorkspace -WorkspaceId $Workspace.WorkspaceId
Restarting a WorkSpace
A WorkSpace virtual desktop can also be restarted in a similar fashion. Of course, if an instance is stopped, it can’t be restarted, so it must be in an available status to be restarted. When a rebuild is executed, the latest available image of the original bundle will be used. The user data drive will be restored from a snapshot, which could be as old as 12 hours. This is because currently the automatic snapshot process takes place every 12 hours.
Restart-WKSWorkspace -WorkspaceId $Workspace.WorkspaceId
Rebuilding a WorkSpace
Another important administration task, especially addressing issues with software or operating system, is of rebuilding a WorkSpace. This can be accomplished by running the following command:
Reset-WKSWorkspace -WorkspaceId $Workspace.WorkspaceId
Deleting a WorkSpace
When a WorkSpace is no longer needed, the following command can be run to completely eliminate the virtual desktop and the associated user’s data:
Remove-WKSWorkspace -WorkspaceId $Workspace.WorkspaceId

Note

When a WorkSpace is deleted, all of the user data is destroyed. If data persistence is required, a backup of the user data must be performed to an external destination, such as S3.

Amazon AppStream 2.0

Imagine having the ability to run your enterprise applications, without needing to download or install any application files to your workstation. With Amazon AppStream 2.0, you have the ability to do just that. The service is a HTML5 compatible and can stream applications from AWS to any client globally, in a pay-as-you-go model. As typical with AWS managed services, it can easily scale to offer expected performance while at the same time eliminating the need to store any user or application files locally, thus increasing the security posture of your application.

Amazon AppStream 2.0 Architecture

We must understand the following concepts in order to design, deploy, and manage AppStream 2.0 for your organization. The options that affect the settings of the components discussed in this section will determine the behavior of AppStream for users, so it is important to ensure you have a good handle of these concepts.

  • Image – In a similar vein to the way Amazon Machine Images (AMIs) work, AppStream images contain applications that users can stream. Customers can choose to use custom images or base images provided by AWS. Images are region specific, but can be copied across regions. Also, images can’t be changed once they are created. If changes are required, a new image needs to be created. To familiarize yourself with the images available, it is recommended you review the AppStream 2.0 Base Image Version History documentation page ( https://docs.aws.amazon.com/appstream2/latest/developerguide/base-image-version-history.html ).

  • Image Builder – The images described earlier can be created with an Image Builder, which is a virtual machine used to install and test your applications.

  • Fleet – The instances streaming your application make up a Fleet, which can either be static or elastic in nature. There is a requirement to have one user per instance.

  • Stack – The streaming application makes up the stack, which is comprised of a fleet, access policies, and storage configurations.

  • User Pool – A User Pool is used to manage users and associates Stacks (i.e., streaming applications) to users.

Requirements

Amazon AppStream 2.0 has requirements for publishing applications and for accessing applications that have been published. In this section, we will discuss both sets of requirements.

Publishing Requirements

The first set of requirements for publishing applications are networking requirements, as the streaming instances and Image Builders need to be accessible, and should also be able to access network resources (e.g., databases, network shares, etc.) and the Internet. When deploying fleet instances in a VPC, it is recommended that these instances are deployed in multiple availability zones for high availability and redundancy reasons. One thing to keep in mind is that every instance in your fleet will require an Elastic Network Interface (ENI), so it is important that service limits are reviewed prior to making your application available to your users.

If the streaming application requires domain authentication or resources in a domain, the standard domain port connectivity access is required. The streaming instances must also be able to communicate with the EC2 metadata service, via http://169.254.169.254.

Note

The AppStream service uses two network interfaces, one for local VPC resource access and the Internet and the second one for management (port 8443) and streaming to client devices (port 8300). The management interface uses the IP range of 192.19.0.0/16, so it is critical to prevent conflicts with this network range.

Client Requirements

In order for client devices to connect to the AppStream 2.0 service, port 443 and port 53 are required from the client connectivity. Additionally, in order for both Session Gateway and CloudFront can be accessed correctly, domains *.amazonappstream.com and *.cloudfront.net must be whitelisted, respectively.

Getting Started with AppStream 2.0

In order to get started, we will first go to the AppStream 2.0 Console; once in the console, we will explore the two options for publishing applications. If you’re a new customer and need to get familiar with the service, a user-friendly way of starting is by using the Quick Links screen and deploying a stack with sample applications. The second deployment option and the one recommended for production environments is a deployment of a custom stack.

Deploying a Sample Applications Stack

As mentioned before, an easy way to get familiar with AppStream 2.0 is by deploying a stack with sample applications. To do this we will go to the Amazon AppStream 2.0 Console:
  1. 1.

    Go to the AppStream 2.0 Console.

     
  2. 2.
    Click the Get started button (Figure 13-13).
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig13_HTML.jpg
    Figure 13-13

    Amazon AppStream 2.0 Get Started page

     
  3. 3.

    Click the Agree and Continue button.

     
  4. 4.
    At this point, you should be on the Quick Links screen (Figure 13-14).
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig14_HTML.jpg
    Figure 13-14

    Quick Links page

     
Launching Sample Applications
In order to get familiar with the architecture and the service, we will deploy a sample application. To do this, we will use one of the Quick Links options from the previous section:
  1. 1.

    To get started with sample apps, we will click the Setup with sample apps button.

     
  2. 2.
    Enter Name, Display Name, Description, and optional Redirect and Feedback URLs. Click Next once all the fields have been populated. See Figure 13-15.
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig15_HTML.jpg
    Figure 13-15

    Stack details form

     
  3. 3.

    On the next screen, scroll down and select the Amazon-AppStream2-Sample-Image-06-20-2017 image. Click Next.

     
  4. 4.
    From the Configure fleet page, select the following settings:

    • Instance type: General purpose – stream.standard.medium, 2 vCPUs, 4 Memory (GiB)

    • Fleet type: On-Demand

    • User session details:

      • Maximum session duration: 15 minutes

      • Disconnect timeout: 15 minutes

    • Fleet capacity:

      • Minimum capacity: 1

      • Maximum capacity: 2

    • Scaling details: Leave default

     
  5. 5.

    On the Configure network page, select the default settings and click Next.

     
  6. 6.

    From the Enable Storage page, leave the default settings and click Next.

     
  7. 7.

    Click Review, to leave the defaults, on the User Settings page.

     
  8. 8.

    On the Review page, click Create.

     
  9. 9.
    When prompted, click the check box to acknowledge the charges, and click Create. See Figure 13-16.
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig16_HTML.jpg
    Figure 13-16

    AppStream 2.0 Stack pricing user acknowledgment form

     
  10. 10.

    From the Stacks page, select the ExampleStack stack and click Actions, then click Create streaming URL.

     
  11. 11.

    For the User ID, enter a user ID, and then select an expiration to set the duration of the generated URL.

     
  12. 12.
    When prompted, click the Copy Link button. See Figure 13-17.
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig17_HTML.jpg
    Figure 13-17

    Unique streaming URL

     
  13. 13.
    Go to your favorite HTML5-compatible browser and paste and go to the URL. The URL should render a page with the sample applications published with the package. See Figure 13-18.
    ../images/319650_2_En_13_Chapter/319650_2_En_13_Fig18_HTML.jpg
    Figure 13-18

    Sample Stack application selection page

     

Deploying Custom Applications Stack

When deploying a custom application stack, the first thing to identify is whether the applications being streamed will reside in a new or existing VPC. If the applications will interact with some existing network resources, then it will likely reside in an existing VPC.

If a new VPC is required, one can be created with the instructions provided in the VPC chapter of this book. In order to have high availability and redundancy, it is recommended that streaming instances are placed in at least two availability zones, which means that these will also need to be created in the newly created VPC. The subnets associated with the availability zones must be public, as AppStream 2.0 requires Internet access via an Internet gateway.

If you want to leverage advanced networking configuration, you can also configure the AppStream 2.0 resources to reside in a private subnet, behind a NAT gateway.

The AppStream 2.0 and Active Directory authenticated and SAML 2.0 Single Sign-On Federated implementations have so many layers, that each would require a separate chapter on their own, if covered in depth. For brevity, we will cover a some of the Active Directory integration options, mainly because Active Directory should be used for production implementations of the AppStream 2.0 service.

Creating Directory Configuration

When domain resources are required for the AppStream 2.0 applications, one of the required settings is to create a directory configuration, which will associate a service account with the service. The following commands will create an AppStream directory configuration. If you don’t have an Active Directory domain available, one can be created following the instructions provided in Chapter 12.

Once an Active Directory domain is available, the following command can be used to set up an AppStream 2.0 Directory Configuration:
$DirectoryConfiguration = New-APSDirectoryConfig -DirectoryName corp.example.com -ServiceAccountCredentials_AccountName corpadmin -ServiceAccountCredentials_AccountPassword 'password' -OrganizationalUnitDistinguishedName OU=Computers,OU=corp,DC=corp,DC=example,DC=com
To verify if the Directory Configuration was created as expected, you can log in to the AWS Console and look at the settings. An example is depicted in Figure 13-19.
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig19_HTML.jpg
Figure 13-19

Directory Configuration verification page

If the streaming applications will leverage Active Directory domain-based resources, it is important to ensure the connectivity between steaming instances and image builders is available and open to the directory services. This means that networking between the subnets that have both AppStream 2.0 resources and Active Directory is configured and security groups are configured to allow port connectivity.

The following port connectivity is required between the AppStream 2.0 VPC and your domain controllers:

  • TCP/UDP 53 – DNS

  • TCP/UDP 88 – Kerberos authentication

  • UDP 123 – NTP

  • TCP 135 – RPC

  • UDP 137–138 – Netlogon

  • TCP 139 – Netlogon

  • TCP/UDP 389 – LDAP

  • TCP/UDP 445 – SMB

  • TCP 1024–65535 – Dynamic ports for RPC

Note

The service account used in the Directory Configuration must have the following minimum permissions to the Organizational Unit (OU) within Active Directory: Create Computer Object, Change Password, Reset Password, and Write Description.

Getting Directory Config List

If you are unsure about the Directory Configurations that have been made, you can run the Get-APSDirectoryConfigList cmdlet to get the list of available configurations.

To get a complete list of configuration, as shown in the code that follows and in Figure 13-20
Get-APSDirectoryConfigList
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig20_HTML.jpg
Figure 13-20

Directory Configuration list

Launching an Image Builder

The first step to publishing and AppStream 2.0 application is to create an application builder, which will be used to customize an image for the custom application.

In order to avoid issues with running the New-APSImageBuilder command, we will create a variable for the Organizational Unit which will store the computer objects for the AppStream instances.
$ImageBuilderOU = OU=Computers,OU=corp,DC=corp,DC=example,DC=com
$ImageBuilder = New-APSImageBuilder -ImageName Base-Image-Builder-06-12-2018 -AppstreamAgentVersion LATEST -Description custom-image-builder -DomainJoinInfo_DirectoryName corp.example.com -DisplayName Custom-Image-Builder -EnableDefaultInternetAccess $true -InstanceType stream.standard.medium -Name Example -DomainJoinInfo_OrganizationalUnitDistinguishedName $ImageBuilderOU -VpcConfig_SecurityGroupId sg-00XXXXXXXXXX -VpcConfig_SubnetId subnet-00XXXXXXXXXX

While the image builder is being created, the Status will be set to pending until the image builder is ready.

Optionally, variables for all the New-APSImageBuilder settings can also be created as shown as follows:
$ImageBuilderDomain = corp.example.com
$ImageBuilderBaseImage = Base-Image-Builder-06-12-2018
$ImageBuilderDisplayName = Custom-Image-Builder
$ImageBuilderDescription = Custom-Image-Builder
$ImageBuilderName = Custom-ImageBuilder
$ImageBuilderSGiD = sg-0XXXXXXXXXXXX
$ImageBuilderSubnetId = subnet-00XXXXXXXXXX
If you don’t need domain resources, the Image Builder can be deployed with as simply as running an appropriate non-domain-based Image Builder launch. See example as follows:
$NonDomainImageBuilder = New-APSImageBuilder -ImageName Base-Image-Builder-06-12-2018 -AppstreamAgentVersion LATEST -Description NonDomain-image-builder -DisplayName NonDomain-image-builder -InstanceType stream.standard.medium -Name NonDomain-Image-Builder -EnableDefaultInternetAccess $true -VpcConfig_SecurityGroupId sg-0XXXXXXXXXXXX -VpcConfig_SubnetId subnet-00XXXXXXXXXX

Once the $NonDomainImageBuilder is deployed, it should come online with a status set to running. Other status states include pending, snapshotting, stopping, starting, and deleting.

Starting Image Builder
Once the image builder is ready, it can be started with the following command:
Start-APSImageBuilder -Name $NonDomainImageBuilder.Name

  • Start-APSImageBuilder is for starting the image builder.

  • Name specifies the name of the image builder to start.

  • AppstreamAgentVersion is for specifying the AppStream agent version; using LATEST is recommended (optional).

  • Force overrides confirmation prompts to continue operation (optional).

Stopping Image Builder
To avoid unintended usage charges, an Image Builder can be stopped at any time by running the following command:
Stop-APSImageBuilder -Name $NonDomainImageBuilder.Name -Force

  • Stop-APSImageBuilder is for stopping the image builder.

  • Name specifies the name of the image builder to stop.

  • Force overrides confirmation prompts to continue operation (optional).

The following sets of parameters can also be used across all the operations (e.g., New-APSImageBuilder, Start-APSImageBuilder, and Stop-APSImageBuilder) to specify region or common credentials:

  • AccessKey is for the AWS access key for the user account.

  • Credential AWSCredentials object instance containing access and secret key details.

  • ProfileLocation specifies the name and location of the ini-format credential file.

  • ProfileName is the user-defined name (optional).

  • NetworkCredential is the profile name of the SAML role profile.

  • SecretKey AWS secret key for the user account.

  • SessionToken is for the session token if the access and secret keys are used for temporary session-based credentials.

  • Region is for the AWS region.

  • EndpointURL specifies the endpoint.

Connecting to the Image Builder
Once an Image Builder is deployed, we will go to the AppStream 2.0 Console and make sure it is in a running state. The next step is to connect to the Image Builder to continue the configuration. To do so, we will go to the App Stream Console, click the Images on the left navigation pane, select the Image Builder, then select the radial button for the Image Builder to connect. Once selected, click the Connect button, as shown in Figure 13-21.
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig21_HTML.jpg
Figure 13-21

List of Images

Once connected to the Image Builder, we will select Administrator to install applications using Image Assistant. See Figure 13-22. All applications can be downloaded and installed at this point. The AWS Schema Conversion Tool will be used for demonstration purposes. Once the AWS Schema Conversion Tool is installed, we will use the Image Assistant to AppStream 2.0 Application Catalog.
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig22_HTML.jpg
Figure 13-22

AppStream 2.0 user selection page

Creating an AppStream 2.0 Application Catalog

To begin, click the Image Assistant icon on the desktop.

Then, we will click Add App and locate and map the executable, as well as the rest of the App Launch Settings (Figure 13-23). Once the settings are selected, we will click the Save button (Figure 13-24).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig23_HTML.jpg
Figure 13-23

AppStream 2.0 image installation page

../images/319650_2_En_13_Chapter/319650_2_En_13_Fig24_HTML.jpg
Figure 13-24

App Launch Settings page

The next step is to click the Next button (Figure 13-25).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig25_HTML.jpg
Figure 13-25

Application installation confirmation

In the next step, we will follow the instructions to create the default app and Windows settings for your users (Figure 13-26).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig26_HTML.jpg
Figure 13-26

Application Configuration tab

Once the settings are selected for the Template User, we will switch back to the Administrator user, and click Save settings (Figure 13-27).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig27_HTML.jpg
Figure 13-27

Application Configuration being saved

Then, click the Next button (Figure 13-28).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig28_HTML.jpg
Figure 13-28

Application image creation

In the next window, we will be able to optimize the application by clicking the Launch button (Figure 13-29).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig29_HTML.jpg
Figure 13-29

Optional image optimization

Click Continue when prompted (Figure 13-30).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig30_HTML.jpg
Figure 13-30

Image optimization

In the CONFIGURE IMAGE tab, label the Name, Display name, and Description. Click Next when prompted, as shown in Figure 13-31.
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig31_HTML.jpg
Figure 13-31

Image publishing details

Image Builder must be used to recreate a new Image .

Note

Launch performance can be optimized by specifying the files that need to be included Pre-warm configuration file. To do this, run the following command: dir -path "C:PathFolderFileToOptimize" -Recurse -ErrorAction SilentlyContinue | %{$_.FullName} | Out-File "C:ProgramDataAmazonPhotonPrewarmPrewarmManifest.txt" -encoding UTF8 -append

On the REVIEW tab, click the Disconnect and Create Image button (Figure 13-32).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig32_HTML.jpg
Figure 13-32

Image Creation finalization

Once disconnected, the state of the Image Builder will change to Snapshotting (Figure 13-33).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig33_HTML.jpg
Figure 13-33

Image Builder confirmation

Creating Images

Once the previous process is completed, the Images created using the preceding process will be listed in the Image Registry as shown in Figure 13-34. Once an image is created, the settings and configuration are permanent. If a change needs to be made, the Image Builder must be used to recreate a new Image.

Note

If an Image Builder has been deleted, a new Image Builder can be deployed using the Image that was created using the deleted Image Builder.

../images/319650_2_En_13_Chapter/319650_2_En_13_Fig34_HTML.jpg
Figure 13-34

Image Registry page

Images in the Image Registry can be categorized as either Private, as when once is built and published using the Image Builder; other categories include Public or Shared, with the later shared from another AWS account.

AppStream 2.0 Agent is the software running on the stream instances and is used to stream published applications. There are various versions of this software that can be installed. Ideally, the latest version should be installed; however, you can also customize the version that will be used by redeploying the Image Builder with the appropriate agent version.

Getting Image Builder List
The following command can be used to get the details of an Image Builder; it can also be used to get the complete list by running the command without any options (Figure 13-35):

  • Get-APSImageBuilderList specifies the list of a single or more Image Builders.

  • Name is the string name of the Image Builders to describe.

  • MaxResult is the max integer size of each page results.

  • NextToken provides string pagination options.

Get-APSImageBuilderList -Name $ImageBuilder.Name
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig35_HTML.jpg
Figure 13-35

Image Builder list

Tagging Image Builder List
An Image Builder can be tagged by using the following command:

  • Add-APSResourceTag is used to add or replace one or many tags.

  • Tag is the hashable key pair combination for a tag.

  • ResourceArn is to specify the Image Builder ARN.

  • PassThru returns passed value (optional).

  • Force overrides confirmation prompts to continue operation.

The following command creates the key value pair for the tag:
$ImageBuilderTag = @{}
$ImageBuilderTag.Add('Name', 'Schema Conversion Tool')
The following command adds a tag to a resource:
Add-APSResourceTag -Tag $ImageBuilderTag -ResourceArn
Getting Images List
The following command can be used to list one or more Images in the Images catalog:

  • Get-APSImageList specifies the list of a single or more Images.

  • Name is the string name of the Image Builders to describe.

  • Arn is for the ARNs of the images to describe.

  • Type is the type of image to describe (e.g., private, public, or shared).

  • MaxResult is the max integer size of each page results.

  • NextToken provides string pagination options.

The following command creates a variable with the list of all images.
$Images = Get-APSImageList
The following command creates a variable for the working Image we have been working with in this chapter:
$SCTImage =  Get-APSImageList | Where-Object {$_.Name -eq 'SchemaConversionTool'}
Filters an Image to display the image that was created in this chapter.
Get-APSImageList | Where-Object {$_.Name -eq SchemaConversionTool}
Copying Images
Images can be copied within region or across regions within the same AWS account using the following command:

  • Copy-APSImage is for copying an image.

  • DestinationImageDescription is for specifying a description of the new image.

  • DestinationImageName is for specifying the name of the new image.

  • DestinationRegion specifies a region for the new image.

  • SourceImageName is for specifying the source image.

  • Force overrides confirmation prompts to continue operation.

$SCTImageCopy = Copy-APSImage -DestinationImageDescription SchemaConversionToolCopy -DestinationImageName SchemaConversionToolCopy -DestinationRegion us-east-1 -SourceImageName S
chemaConversionTool

Note

An Image can be shared with other AWS accounts by using the AppStream 2.0 Console, selecting the image to share, and going to the Permissions tab.

Removing Images
In order to remove existing Images created in the previous steps, the following command can be run:

  • Remove-APSImage deletes a specified image.

  • Name is for the image name.

  • Force overrides confirmation prompts to continue operation.

$SCTImageCopy =  Get-APSImageList | Where-Object {$_.Name -eq 'SchemaConversionTool'}
Remove-APSImage -Name $SCTImageCopy -Force
Creating Fleets
When creating Fleets, which are comprised of streaming instances, we first have to determine the type of Fleet to have. There are two options that determine how you pay for the instances and when these instances run:

  • Always On – Instances run all the time and allow users to access their applications immediately.

  • On-Demand – Instances run when applications are being streamed, when idle they go to a stopped state. If stopped, there is an estimated 1–2-minute hydration time for the instances to become available.

When selecting a Fleet, it is also important to understand the Instance Families available, because the selection made will directly impact the performance of your application; the same is true for the image selected at launch. The following list summarizes the Instance Families available for selection; the selection should match the use case of your application, as well as an appropriate application image.

Instance Family and Use Case

  • General Purpose – Basic use cases for common business applications

  • Memory Optimized – Suitable for memory intensive applications

  • Compute Optimized – Intended for use with compute intensive applications

  • Graphics Design – AMD FirePro S7150x2 GPU-optimized instances for use with DirectX, OpenGL, or OpenCL

  • Graphics Desktop – NVIDIA GRID K520 GPU-optimized instances for use with DirectX, OpenGL, or OpenCL

  • Graphics Pro – NVIDIA Tesla M60 GPU optimized for graphic applications that use DirectX, OpenGL, or OpenCL

Once you have identified fleet type to use and instance family, we will then use the following commands to create the fleet:

  • New-APSFleet creates a fleet of streaming instances that run on a specific image.

  • Name sets the fleet name.

  • Description sets a description for the fleet.

  • ComputeCapacity_DesiredInstance sets the number of instances for the fleet.

  • DomainJoinInfo_DirectoryName is for the fully qualified domain name of the directory (e.g., example.com)(optional).

  • DisconnectTimeoutInSecond sets the amount of time for a session to be considered to have ended. If a user reconnects within the timeout period, then they will reconnect to the previous session. Value can be between 60 to 57,600 seconds.

  • DisplayName is for the display name for a fleet.

  • EnableDefaultInternetAccess enables or disables Internet access for a fleet.

  • FleetType sets the fleet as either ALWAYS_ON or ON_DEMAND.

  • ImageArn is for the ARN for the image to use.

  • ImageName is for the name of the image used to create the fleet.

  • InstanceType sets the instance to one of the available instance types (e.g., stream.standard.medium).

  • MaxUserDurationInSecond sets the max time a session can last.

  • DomainJoinInfo_OrganizationalUnitDistinguishedName sets the distinguished name of the Organizational Unit for the computer objects (optional).

  • VpcConfig_SecurityGroupId is for setting security group for a fleet.

  • VpcConfig_SubnetId is for the subnet where the network interfaces will be placed.

  • Force overrides confirmation prompts to continue operation.

$Fleet = New-APSFleet -Name NonDomain-Fleet -Description NonDomain-Fleet -ComputeCapacity_DesiredInstance 2 -DisconnectTimeoutInSecond 60 -DisplayName NonDomain-Fleet -EnableDefaultInternetAccess $true -FleetType ON_DEMAND -ImageName SchemaConversionTool -InstanceType stream.standard.medium -MaxUserDurationInSecond 1800 -VpcConfig_SecurityGroupId sg-00XXXXXXXXXX -VpcConfig_SubnetId subnet-00XXXXXXXXXX
Getting Fleet List

There are cases in which you will need to get a list of one or many Fleets. In order to get the list, you can run the Get-APSFleetList cmdlet or apply a filter to only get the details for one Fleet.

To get details of the NonDomain-Fleet, apply the following filter and feed the results to the $Fleet variable:
$Fleet = Get-APSFleetList | Where-Object {$_.Name -eq 'NonDomain-Fleet'}
Starting a Fleet
Once Fleet has been created, it can be started using the following commands:

  • Start-APSFleet starts a Fleet.

  • Name specifies the name of the Fleet to start.

  • PassThru returns the value passed to the Name parameter.

  • Force overrides confirmation prompts to continue operation.

To start a Fleet that is stopped, run the following command, referencing the $Fleet variable previously created:
Start-APSFleet -Name $Fleet.Name
Stopping a Fleet
If a Fleet is running, then it can be stopped using the following commands:

  • Stop-APSFleet starts a Fleet.

  • Name specifies the name of the Fleet to start.

  • PassThru returns the value passed to the Name parameter.

  • Force overrides confirmation prompts to continue operation.

To stop a running Fleet, you can run the following command using the $Fleet variable:
Stop-APSFleet -Name $Fleet.Name
Creating Stacks
Once a Fleet has been created, the next step is to create a stack to control access to your fleet:

  • New-APSStack creates a stack to associate fleet, user access policies, and storage configurations.

  • Name sets the name of the stack.

  • Description sets the description of the stack.

  • DisplayName sets the display name for the stack.

  • ApplicationSettings_Enabled sets the path prefix for the S3 bucket to use for persistency of application settings.

  • FeedbackURL is for providing a URL where feedback can be provided (optional).

  • RedirectURL is for the redirect to send a user after a session ends (optional).

  • ApplicationSettings_SettingsGroup is for enabling or disabling persistent application settings.

  • StorageConnector identifies the storage connectors to enable. Connectors include Home Folders which stores persistent user data in S3, Google Drive for G suite that stores data in Google Drive, and OneDrive for Business which saves all users data in OneDrive.

  • UserSetting sets the actions that are enabled or disabled during streaming sessions, enabled by default. These settings include enabling a clipboard, ability to perform file transfers, and printing to a local device.

  • Force overrides confirmation prompts to continue operation.

The following command creates an object to specify the storage connector setting. The setting can be enabled and disabled from the console.
$StackConnectorType = New-Object Amazon.AppStream.Model.StorageConnector
The following command will create a stack associated with the non-domain Fleet:
$NonDomainStack = New-APSStack -Name NonDomain-Stack -Description NonDomain-Stack -DisplayName NonDomain-Stack -StorageConnector $StorageConnectorType
Getting Stack List

If you need to get a list of Stacks configured in your account, the Get-APSStackList cmdlet can be used to get a list of all Stacks or a filter can be used to only retrieve a single Stack.

To get details of the NonDomain-Stack, apply the following filter and feed the results to the $Stack variable:
$Stack = Get-APSStackList | Where-Object {$_.Name -eq 'NonDomain-Stack'}
Configuring Persistent Storage

One important setting to identify, which will significantly impact user experience, is whether to have persistent storage (e.g., Home Folders) for your users. There are three options for this setting, which include Google Drive for G Suite, OneDrive for Business, and Home Folders, which is an AWS native solution.

If the latter option is selected, the data stored in the fleet’s Home Folders (i.e., C:UsersPhotonUserMy FilesHome Folder for non-domain instances or C:Users\%username%My FilesHome Folder for domain joined instances), then all files stored in this location will be automatically backed up to an S3 bucket that gets created the first time a Stack is created; bucket is in the same region as the stack. The data in transit and at rest will be encrypted, using Amazon S3-managed keys.

By detail the AppStream service creates and attaches a secure S3 bucket policy to the bucket on which persistent files will be saved. For support or security hardening purposes, bucket polices can be further customized to ensure users other than the primary user and the admins can access the files in the S3 bucket. Useful details on how to perform these actions can be found in the “Controlling Access to AppStream 2.0 with IAM Policies and Service Roles” documentation page ( https://docs.aws.amazon.com/appstream2/latest/developerguide/controlling-access.html#s3-iam-policy ).

If S3 access is required, the following policy can be attached to the VPC endpoint to grant access to the service. Going with this approach, as opposed to accessing S3 via the Internet, may result in unexpected network usage charges.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow-AppStream-to-access-home-folder-and-application-settings",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:sts::account-id-without-hyphens:assumed-role/AmazonAppStreamServiceAccess/AppStream2.0"
      },
      "Action": [
        "s3:ListBucket",
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:GetObjectVersion",
        "s3:DeleteObjectVersion"
      ],
      "Resource": [
        "arn:aws:s3:::appstream2-36fb080bb8-*",
        "arn:aws:s3:::appstream-app-settings-*"
      ]
    }
  ]
}
Registering Fleet with Stack
Once we have a Stack and a Fleet created, the next step is to associate the Fleet with a Stack. To do this, we will use the Register-APSFleet command:

  • Register-APSFleet associates a fleet with a specified stack.

  • StackName is to set the Stack name.

  • FleetName is to set the Fleet name.

  • PassThru returns the value passed to the StackName parameter.

  • Force overrides confirmation prompts to continue operation.

To associate a Stack with a Fleet, we will run the following command and using the $Stack and $Fleet variables we created in previous sections:
Register-APSFleet -StackName $Stack.Name -FleetName $Fleet.Name
Granting Users Access

Once all the previous steps have been completed, including creating a Stack, users can be granted to the AppStream 2.0 service. Ways in which users can access the service include using a User Pool, Single Sign-On via SAML 2.0 federation, and the AppStream 2.0 API.

Note

AppStream 2.0 User Pool users can’t be assigned to Stacks with Fleets that are joined to Active Directory.

Adding AppStream 2.0 User Pool Users
In this section, we will create AppStream 2.0 User Pool users, which can be assigned to the previously created stacks. In order to do this, we will get familiar with the following command:

  • New-APSUser creates a new user in the user pool.

  • AuthenticationType is to set the authentication type, which can be API, SAML, or USERPOOL.

  • FirstName is for the user’s first name.

  • LastName is for the user’s last name.

  • MessageAction specifies whether the welcome e-mail will be sent, resent, or suppressed. If sent, welcome e-mail has a temporary password valid for 7 days.

  • UserName sets the username.

  • Force overrides confirmation prompts to continue operation.

In this example, we will create a user for Bob in the AppStream 2.0 User Pool.

The first step to do this is to create an authentication type object and specify the user pool.
$AppStreamUserPool =  New-Object Amazon.AppStream.AuthenticationType('USERPOOL')
The next step is to create the actual user for Bob. To do this, we will execute the following command:
$Bob = New-APSUser -AuthenticationType $AppStreamUserPool -FirstName Bob -LastName Smith -UserName [email protected]
Once the user is created, the AppStream 2.0 Console can be used to verify if the user was created as expected (Figure 13-36).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig36_HTML.jpg
Figure 13-36

AppStream User Pool account created

The person with the newly created user will receive an e-mail with details on how to access the AppStream 2.0 service (Figure 13-37).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig37_HTML.jpg
Figure 13-37

AppStream 2.0 automated e-mail

When the user clicks the login page link, they will be prompted to log in with their e-mail address and the temporary password that is provided (Figure 13-38). The temporary password is valid for 7 days from the time issued.
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig38_HTML.jpg
Figure 13-38

AppStream 2.0 login page

The user must change their password after successfully authenticating to the service (Figure 13-39).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig39_HTML.jpg
Figure 13-39

Password change page

Disabling AppStream 2.0 User Pool Users
In order to disable AppStream 2.0 User Pool users, we will need to make sure we have an object that specifies the authentication type pointing to the user pool as the location of the user:

  • Disable-APSUser disables a user.

  • AuthenticationType is to set the authentication type, which can be API, SAML, or USERPOOL.

  • UserName specifies the user to disable.

  • Force overrides confirmation prompts to continue operation.

As a refresher, to create an authentication type object, we will run the following command:
$AppStreamUserPool =  New-Object Amazon.AppStream.AuthenticationType('USERPOOL')
The following command will disable the user for username [email protected]:
Disable-APSUser -AuthenticationType $AppStreamUserPool -UserName [email protected]
Enabling AppStream 2.0 User Pool Users
Enabling AppStream 2.0 User Pool users is very similar to disabling the users, except that we perform an action in reverse. We will still need to make sure we have an object that specifies the authentication type pointing to the user pool as the location of the user:

  • Enable-APSUser disables a user.

  • AuthenticationType is to set the authentication type, which can be API, SAML, or USERPOOL.

  • UserName specifies the user to disable.

  • Force overrides confirmation prompts to continue operation.

The following command will enable the user for username [email protected]:
Enable-APSUser -AuthenticationType $AppStreamUserPool -UserName [email protected]
Assigning AppStream 2.0 User Pool Users to Stacks
One of the ways in which users are granted access to Stacks is by assigning users to specific Stacks. As you can imagine, these assignments can be done either by API, CLI, AWS Console, or PowerShell. To perform the actions in PowerShell, we will leverage the following cmdlet to make this association:

  • Register-APSUserStackBatch associates a user to a specified Stack.

  • UserStackAssociation lists the user stack association.

  • Force overrides confirmation prompts to continue operation.

In order to assign User Pool Users to a Stack, we first have to create a UserStackAssociation object and specify all the parameters required for the association. For example, we will associate user [email protected] with the NonDomain-Stack.
$APSUserStack = New-Object Amazon.AppStream.Model.UserStackAssociation
$APSUserStack.AuthenticationType = $AppStreamUserPool
$APSUserStack.SendEmailNotification = $true
$APSUserStack.UserName = '[email protected]'
$APSUserStack.StackName = 'NonDomain-Stack'
Once we have all the parameters configured as expected, we will run the Register-APSUserStackBatch command.
$NonDomainUserStack = Register-APSUserStackBatch -UserStackAssociation $APSUserStack
Once the association is completed, the user associated with a Stack will receive an e-mail to access the login page, as shown in Figure 13-40.
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig40_HTML.jpg
Figure 13-40

AppStream 2.0 assignment notification

Once you log in to the AppStream 2.0 service using the login page in the e-mail, you will be able to access the Schema Conversion Tool published in earlier parts of this section (Figure 13-41).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig41_HTML.jpg
Figure 13-41

AWS Schema Conversion Tool page

If we click the application link, we will be able to launch the application which may take several minutes. See Figure 13-42. The application streaming experience can be heavily optimized, but it is outside of the scope of this chapter. If you need additional guidance on optimizing your application, review the Customize an AppStream 2.0 Fleet to Optimize Your Users’ Application Streaming Experience documentation page ( https://docs.aws.amazon.com/appstream2/latest/developerguide/customize-fleets.html ).
../images/319650_2_En_13_Chapter/319650_2_En_13_Fig42_HTML.jpg
Figure 13-42

Launching AppStream 2.0 image

Exercise 13.1: Launch Custom Stack, Fleet, and Image

In this exercise, we will create an Image, launch a Fleet, create a Stack, and associate a non-domain user with an application.

Open the AWS Tools for PowerShell and run the following command:
$NonDomainImageBuilder = New-APSImageBuilder -ImageName Base-Image-Builder-06-12-2018 -AppstreamAgentVersion LATEST -Description 'Description' -DisplayName 'DisplayName' -InstanceType stream.standard.medium -Name 'Name' -EnableDefaultInternetAccess $true -VpcConfig_SecurityGroupId sg-0XXXXXXXXXXXX -VpcConfig_SubnetId subnet-00XXXXXXXXXX
Once completed, we will start the Image Builder.
Start-APSImageBuilder -Name $NonDomainImageBuilder.Name

Go to the AppStream 2.0 Console connect to the Image Builder and follow the instructions provided in this section to publish a streaming application and Image.

Once an Image has been created and is available in the Image Registry, create a Fleet using the commands as follows:
$Fleet = New-APSFleet -Name NonDomain-Fleet -Description 'Description' -ComputeCapacity_DesiredInstance X -DisconnectTimeoutInSecond 60 -DisplayName 'DisplayName' -EnableDefaultInternetAccess $true -FleetType ON_DEMAND -ImageName 'ImageName' -InstanceType stream.standard.medium -MaxUserDurationInSecond 1800 -VpcConfig_SecurityGroupId sg-00XXXXXXXXXX -VpcConfig_SubnetId subnet-00XXXXXXXXXX
Once a Fleet is created, use the following commands to create a Stack:
$StackConnectorType = New-Object Amazon.AppStream.Model.StorageConnector
$Stack = New-APSStack -Name 'Name' -Description 'Description' -DisplayName 'DisplayName' -StorageConnector $StorageConnectorType
Once the Stack has been created, associate a Stack with a Fleet.
Register-APSFleet -StackName $Stack.Name -FleetName $Fleet.Name
Then, we will create a user in the AppStream 2.0 User Pool.
$AppStreamUserPool =  New-Object Amazon.AppStream.AuthenticationType('USERPOOL')
$User = New-APSUser -AuthenticationType $AppStreamUserPool -FirstName 'FirstName' -LastName 'LastName' -UserName '[email protected]'
Once a user has been created, we will assign a Stack to a User by running the following commands:
$APSUserStack = New-Object Amazon.AppStream.Model.UserStackAssociation
$APSUserStack.AuthenticationType = $AppStreamUserPool
$APSUserStack.SendEmailNotification = $true
$APSUserStack.UserName = [email protected]'
$APSUserStack.StackName = 'StackName'
Once the parameters are configured, the following cmdlet can be run:
$UserStack = Register-APSUserStackBatch -UserStackAssociation $APSUserStack

Summary

In this chapter, we saw the Amazon Desktop and Application Streaming services, which provide organizations the ability to deliver their workforce secure, centrally managed desktops and applications, at a global scale. Although we spent a lot of time learning about the AppStream Service 2.0 functionality without domain authentication, we also learned how to leverage AWS Directory Services to provide access control to these services, which can help you increase the security posture of your portfolio, by leveraging existing user credentials.

Each section also included a step-by-step walkthrough to help you get started with setting up both Amazon WorkSpaces and Amazon AppStream 2.0. The goal of the step through is to give you a jump start to begin delivering these services to customers within your organization.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset