By using AWS re:Post, you agree to the Terms of Use

Custom Appstream 2.0 Elastic application won't mount VHD and start


I have a custom Windows application I'm trying to deploy an Elastic Fleet to. I've created the VHDX file, verified that I can mount it with the Powershell script (using a F: drive letter). I have the VHDX image, my script and the icon file in a dedicated S3 bucket and the JSON permissions all set up. When I launch the app, I can see the icon perfectly fine - so that tells me the permissions on the bucket are set correctly. I saw the other question regarding the script policy override, so that is in place as well. It takes at least 2-3 minutes for the streaming to start, and when it does, the screen is all black. I'm actually able to Fn the Ctrl-Alt-Delete to bring up task manager. From there I can launch a command prompt, and I do not see the F drive mapped. In fact, I don't see the C:\AppStream folder at all. According to the AppStream documentation, I should see log files in an S3 bucket, but I do not see a folder for the fleet in any of my S3 buckets. I should also mention that I have an On-Demand Fleet running and this works perfectly fine, but I would like to get this to work on Elastic since that is a better fit for my use case. I've tried deleting the fleet, stack, app block, app, and recreating all of it with the same results. Any ideas what I'm doing wrong here?

asked 8 months ago97 views
1 Answer
Accepted Answer

It takes at least 2-3 minutes for the streaming to start, and when it does, the screen is all black.

Are you using Application View on the fleet? For the sake of troubleshooting, Desktop View might help - you'll be able to launch Windows Explorer directly to navigate the C: drive

In fact, I don't see the C:\AppStream folder at all

The "2-3 minutes for streaming to start" coupled with "I don't see the C:\AppStream folder" implies the VHD wasn't able to download within the timeout. How large is your VHD file? The smaller the better. We've even seen some usage where the VHDX is stored within the S3 bucket zipped, then the setup script unzips it before it gets mounted. Depending on your application, you can get significant space savings leading to the application launching faster.

Another thing to test is using the S3 console to create a presigned URL, and try downloading the files within AppStream 2.0, just to validate the S3 route works from the streaming instance.

answered 8 months ago
  • Thanks, really good advice and here's what I found so far. My VHD file was about 320 megs, and I took some unnecessary files for startup out of it and rebuilt, to get it down to just about 100 megs. That did not seem to change anything, and it's taking the same amount of time before coming up with a black screen (quite a bit of time with "Reserving Session" and "Connecting". I also tried your suggestion of launching in Desktop View, and still don't see the C:\AppStream folder. Seems like I need to be missing some major since I also still don't see any logs in any S3 buckets. Just kind of flying blind with no errors to troubleshoot. I'll see if I can try the presigned URL.

  • Just wanted to loop back and say that it is now resolved. The issue must have been in the VPC, subnet or security group settings because once I did a new fleet with just the defaults, it started working right away. It's sending logs to my S3 bucket, creating an C:\AppStream folder and working great. Thanks again for the help and suggestions to point me in the right direction!

  • Thanks for the follow up! I'll pass it along to the service team so the documentation can be clarified/updated. Did you figure out what was going on with the non-default VPC to identify the issue? Maybe no NAT gateway route to the internet or S3 endpoint?

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions