AppStream: Your session is taking longer than expected to prepare - fails

Do you have app settings persistence enabled for the stack? Try disabling that. If that works, it's the downloading of that VHD that is causing the issue. Do you have a S3 VPC Endpoint Gateway and configured Route Table entries for your AS2 subnets? Did you check the resource policy assigned to the endpoint? What is the bucket policy?

Hi Paul,

we had this multiple times as well in different setups. To eliminate possible trouble sources, it would be great to tell us more about the setup.

• Is it a domain-joined fleet? Any GPOs attached to the OU and/or user?
• Does it work with always on enabled?
• Did you apply any workarounds like extending the size of the VHD file?

If not - what did the AWS support say? Unfortunately the instance pool is managed by AWS so we've only limited view to the most components...

Kind regards, Till

I have worked on this issue for several weeks with Amazon Support.
It is very challenging to duplicate the problem in any consistent way.

Amazon Support helped me understand the nature of the issue but we have not yet resolved the issue completely. There are many different tools available to understand the problem more fully and we have exercised some of these. Rather the beating our heads against the wall for a complete solution, we have developed a problem avoidance strategy I plan to use for the moment.

I am just getting started with supplying my application to my users via AppStream. I am using On-demand fleets. Following mostly fleet configuration defaults, I had set minimum capacity to 1. This is problematic in the situation we are dealing with here. I set it to 2 instead at a cost of $19/month for the extra capacity. While there is no guarantee the second instance of the stack will not have the same problem, at least it is an attempt to avoid the issue.

There are many other fleet configuration parameters such as Scale Out and Scale In Policies available and tools such as CLI to work further. I have looked at these a bit under the guidance of Amazon Support, but am not currently planning to use anything other than setting minimum capacity to 2.

Along the way I learned...

• Logging out from a session moves the session from InUse to Pending, not to Available as you my expect.
• Transition from Pending to Available is about 20 min. These facts were key in identifying the workaround proposed.

Using minimum 2 enables my message to users to be:

On some occasions when you attempt to login, the startup sequences appears to hang. When this happens, you will see the amazon AppStream 2.0 normal startup screen with no additional information supplied and no user interaction requested.

Workaround 1: Totally quit the browser being used. Then restart the browser and execute the normal AppStream login process. Note that opening a new tab/window in current browser session will not resolve the issue. You must totally quit the browser which will result in killing all current browser sessions.

Workaround 2: Start AppStream in a different browser (e.g. if hung in Chrome, access from Firefox instead).

Here is more detailed info from Amazon Support...

To summarize the suggested work arounds, we mentioned the following: 1.Increasing the minimum number of instances based on sage.

2.Using a scheduled scaling policy.

3.Using the Insufficient Capacity Error policy and launching instances based on alarm.

4.Clearing the browser for cache and allowing enough time for instances to move from the pending to a running state before connecting to a session.

5.Switching over to the old console and adding the auto-scaling rules again.

6.Run commands using he AWS CLI to clear the user session.

Hope others find this info helpful.

Paul