AppStream Troubleshooting QuickHits

This post isn’t a necessarily a troubleshooting deep dive, but I just want to share some of the more common issues I’ve seen while working with AppStream.

  1. Image Preparation – application settings are not saved from the template to the test user.

When creating an AppStream image, its standard procedure to use a Template user to set default application settings and then login as a test user to make sure those settings hold. If you follow the procedures presented within the Image Assistant, you shouldn’t have any problem. However, there are times when we can all fall back into old habits of image building, or simply be in a hurry or distracted, and thus bypass steps necessary for AppStream.

I made the following error in the last week to be open and honest but after installing applications and then modifying them as the Template user, the changes I made were not enforced when I tested the applications as the Test User. Remember, when you login as the Template user, you MUST launch the applications you wish to modify using the Image Assistant AND before testing the application as the Test user, you must click Save Settings.

If you notice your application settings do not persist to the test user, make sure you launch the applications, as the Template user, from Image Assistant AND make sure you save the settings before logging in as the Test User.

2. AppStream Stacks – S3-based Home Folders/Files do not persist between user sessions

When deploying your AppStream Stack, you have the option to enable home folders using S3, Google Drive for G Suite, or OneDrive for Business. If you choose S3, you may have some users say, “I’m saving files but the next time I login, I get an error stating that the system cannot find my file.”

When using S3 for home folders, make sure end users are saving their files to the Home Folder directory (or a subdirectory of it). Folders and files stored within this directory will persist between AppStream sessions.

3. Okta/SSO Integration – No Applications Available

I’m not sure how prevalent this error may be but I thought I’d mention it nonetheless. This may be more common for those who are testing AppStream with small fleets, testing AppStream/Okta integration without the use of an Active Directory domain, or maybe some are using Active Directory but are not using AD Groups to assign access to Okta applications. Whatever the situation may be, if you see “No Applications Available”, do a check of the users permissions/group memberships. If this is happening to multiple users of a single AppStream fleet, verify that the fleet is running.

In the case of the screenshot below, the user had permissions to the Okta application (not through group membership) but was not assigned access to the AppStream stack.

4. Launching an AppStream Stack Through Okta opens the AWS Management Console?

When launching an AppStream stack through Okta (or ADFS), you may be surprised to see the AWS Management Console open instead:

What the heck happened here? When I have encountered this, the issue has been that the Default Relay State variable (shown in Okta below), is not set correctly. Check it to make sure you have matched the appropriate AppStack name and AWS account number.

Wrap Up…

Shown above are just a few AppStream issues I’ve seen while working with the service. Here is a link to the Troubleshooting section of the Amazon AppStream Administration Guide for help with many other issues not covered here. If you’ve had to troubleshoot something not seen here or in the admin guide, please share…we’d love to hear your AppStream stories and triumphs!

Leave a Reply

Your email address will not be published.