Unable to launch desktop via Gateway in invoked mode. ICA launch works (downloading the file, non invoked mode and clicking on it works)
In the non-working response for ICA file download, we see Riverbed headers ( highlighted ) and the "Connection: close" header being stripped 


 

Exclude bi-directional communication between ADC SNIP and StoreFront IP addresses from Riverbed HTTP Optimization
ICA communication is recommended to be whitelisted from filtering/optimization in general.

---

Problem Cause

The first step before app/desktop launch is ICA File download and that decision process actually starts when the User sees the Detect Receiver message.

•    If “Detect Receiver” is clicked, and Client detection is successful, the ICA file request comes over the SOCKS connection using the FileFetchURL.  
•    If the user clicks 'Already Installed'  and cancels the ‘Detect Receiver’ prompt, the ICA request comes through the Browser (over HTTP).  

If we go via the first method ( which we were when the issue was faced ), and after successfully detecting the Client then the ICA file download is split into two parts.
Firstly the browser makes a request called getLaunchStatus to fileFetchUrl, ticket and STA ticket.
It then passes this information via protocol handler to theWorkspace.
Workspace (WebHelper.exe) downloads the ICA file by making a SOCKS connection.

Here, we found that there was a Riverbed Device performing HTTP optimization between ADC and Storefront  and with that in place, the backend connection remains active after ica is downloaded as the "Connection: close" header from StoreFront is stripped by the Riverbed device, hence the backend connection between ADC and StoreFront took more than 100 seconds to close ( 100 seconds is the lifetime of STA ticket ), due to this delay once Workspace invokes the ICA file, it is invalidated by STA servers 
This is only visible when we select the workspace during the Client detection phase to Always Open ICA files.