WorkSpaces Applications Elastic Fleet — persisted user storage (VHDX) not reliably mounted before application starts

You are correct: Registry keys and MountStatus flags are often updated before the Windows File System (NTFS) has finished remapping the folder redirects. To verify actual filesystem readiness in your Session Scripts, do not rely on API statuses. Instead, use a Sentinel File approach:

1. The "Sentinel" Strategy: Create a hidden file (e.g., .mount_ready) inside the user’s persisted settings folder.
2. The Script Logic: In your startup script (PowerShell), implement a loop that specifically checks for the existence of this file or tries to write a timestamp to it.

   $path = "$env:USERPROFILE\AppData\Roaming\YourApp\settings_folder"
   $timeout = 30 # seconds
   $timer = [System.Diagnostics.Stopwatch]::StartNew()
   
   while ($timer.Elapsed.TotalSeconds -lt $timeout) {
       if (Test-Path "$path\.mount_ready") {
           # Optional: Try a dummy write to ensure NTFS handles are ready
           try { 
               $testFile = New-Item -Path "$path\io_test.tmp" -ItemType File -Force
               Remove-Item $testFile
               exit 0 # Success!
           } catch { }
       }
       Start-Sleep -Seconds 1
   }
   exit 1 # Fail: Storage didn't mount in time

3. Why this works: Test-Path against a specific sub-folder forces the OS to resolve the redirection. If the VHDX isn't fully mounted, the script either hits the local (empty) profile or a "Path not found" error, causing it to loop until the Elastic Fleet's storage connector finally hooks in the VHDX.

Key Insight: If you don't have a sentinel file, check for a known sub-directory that only exists in your persisted VHDX. Avoid checking the root mount point, as it might exist as a local directory before the redirection occurs.

The issue you're experiencing is a known timing challenge with persistent storage mounting in WorkSpaces Applications. Persistent storage mounting happens after a user logs in and can take several seconds to complete. The "Device is not ready" type errors you're encountering occur when applications try to access files from the home folder before persistent storage mounting is fully complete.

The recommended approach to reliably handle this is to use session scripts to monitor the storage mounting status and only start the streaming session after mounting is complete. This approach not only resolves the race condition but also improves the end-user experience by ensuring the application environment is fully ready before the application launches.

When you implement session scripts before streaming sessions begin with persistent storage enabled, the process works as follows: storage connector mounting starts when your session scripts start, your session scripts then complete or time out (with a maximum of 60 seconds), and only after that does the users' streaming session start and the application launch. This sequencing allows you to implement proper wait logic within your session scripts.

For your session scripts to be considered successful and allow the session to proceed, they must return a value of 0 upon completion. If scripts don't complete successfully, users will see an error message, though they can still use their streaming session.

The key is to implement active verification within your session scripts rather than relying solely on mount status indicators. You should wait a few minutes if needed and implement retry logic that actually attempts to access the files in the mounted location to confirm filesystem-level readiness, not just reported mount status.

Regarding the VHD file itself, be aware that the entire VHD must be downloaded to the streaming instance before a streaming session can begin, and a VHD containing a large amount of data can delay the start of the streaming session. With your average of 100 MB per user, this should be manageable, but it's worth considering as part of the overall timing picture.

The documentation specifically recommends using session scripts to monitor storage mounting status and starting the streaming session only after mounting is complete as the solution to avoid premature application access attempts.
Sources
Troubleshooting Persistent Storage Issues - Amazon WorkSpaces Applications
Run Scripts Before Streaming Sessions Begin - Amazon WorkSpaces Applications
How Application Settings Persistence Works - Amazon WorkSpaces Applications