Connection to "Desktop" Failed with Status (Unknown client error 0) - After updating VDA to 7.15 LTSR CU2

[Pratima Bhardwaj1709160004]

Hi,

I am using XenDesktop 7.15 LTSR . I updated my Win 7 VDA to 7.15 LTSR CU2 (7.15.2000). After update process when I launch the VDI, I get an error "

The Connection to “Desktop” Failed with Status (Unknown Client Error 0)"

 

This is an internal connection, users connecting directly to storefront. Receiver version 4.9 (14.9.0.2539). We use MCS for image creation and VDI has a PVD.

 

I don't see any error in Director, event logs (VDI/Controller).

 

Any thoughts on what could be the issue.

 

Thanks.

[Sam Bates]

The last 2 times I have seen this error it has been caused by STA server set on the NetScaler incorrectly.

 

First Instance. 2x STA Servers set on the Storefront side (HA Setup) but only one referenced on the NetScaler.  Once corrected error removed.

 

Second Instance.  NetScaler became unlicensed after a restart and disabled all features.  Once License was reapplied I had to relink the certs, but it had also removed the STA server and users received Unknown client error 0 error.  Adding the STA Server back to the Gateway Virtual Server resolved.

[Pratima Bhardwaj1709160004]

This issue is resolved now. Though all the firewall rules were open to allow ICA traffic, McAfee firewall was checking specific signatures for portica service.

After removing the signatures it started to work. 

 

[Krishna Desai]

Check the launch.ica file from the client and compare the server address/name with your server.  

 

[Pratima Bhardwaj1709160004]

server address is correct.

[Guang Liu]

You need to collect CDF trace on problematic VDA as well as Scout log for further investigation.

[Balaji Muthukrishnan]

See if this is applicable for you....

 

~~~~

 

Posted April 18

we have worked with citrix and identified a possible workaround to eliminate this issue. But am sure this has been observed in the storefront server version 3.12.100.1 post upgrade from 3.0.1 atleast in my environment.

 

the suggestion was to disable session reliability for the Gateway URLs under Manage Netscaler Gateways - edit - Secure Ticket Authority - uncheck Enable session reliability

 

This has worked for me post propagating the changes to all the SF servers. forcing it to listen on 1494 instead of 2598. but still need to find the reason for failing with 2598.

 

~~~~

 

https://discussions.citrix.com/topic/358080-failed-with-status-1110/?page=2

 

Check the last update please...

[Pratima Bhardwaj1709160004]

@mbalajitry...

I have internal connections only...nothing coming from NetScaler.

[Balaji Muthukrishnan]

Are you able to telnet to the VDA @ 1494 / 2598 when initiating ICA connection ? 

 

Please check the firewall inbound rules. Ideally you should see 4 inbound rules allowed for 1494/2598 for TCP/udp. If not compare with working machine and try to create the rules.

[Diego Acuna1709157179]

Hi, were you able to fix this issue?

 

Most of the times I've seen this error it comes down to be a network issue, though it might have other causes too.

 

The following article might help you investigating this issue from a packet capture perspective:

 

https://support.citrix.com/article/CTX227054

 

It is for a connection involving NetScaler, but if you understand the connection flow you can use it to track the launch request thru Storefront. This other article gives a good explanation:

 

https://support.citrix.com/article/CTX128909

 

I am guessing the client machine is actually getting the ica file downloaded correctly, as mentioned previously you can take a look at it and make sure that all the information there is correct.

 

If the problem persists then yes, CDF traces from the client machine and from the VDA + a packet capture would be our best friends here.

[Muhammad Quaseem Noor Siddiqi]

On 9/19/2018 at 2:24 AM, Pratima Bhardwaj1709160004 said:

This issue is resolved now. Though all the firewall rules were open to allow ICA traffic, McAfee firewall was checking specific signatures for portica service.

After removing the signatures it started to work. 

 

 

Thanks Pratima for sharing the resolution. Actually we are also facing similar issue like yours with a similar scenario. I am not well versed with AV so thought to check with you.

So this configuration was on McAfee AV server?

From where we removed the signature? like from McAfee AV server or from the client server?

How we removed the signature?

 

Regards,

Quaseem

 

[Mike1709156907]

I hope this helps someone. I had a similar issue. Internally was getting the same message as stated in this thread. Externally everything was working fine through the Gateway. My issue turned out to be the "Optimal HDX Routing" configuration in StoreFront (under the Configure Store settings). I ended up clearing the check boxes in the gateway line for the controllers and the errors went away.

[Andy Vanderbeken]

On 7/30/2020 at 4:05 PM, Mike1709156907 said:

I hope this helps someone. I had a similar issue. Internally was getting the same message as stated in this thread. Externally everything was working fine through the Gateway. My issue turned out to be the "Optimal HDX Routing" configuration in StoreFront (under the Configure Store settings). I ended up clearing the check boxes in the gateway line for the controllers and the errors went away.

 

OMG been searching for 2 days going over and over again over each little setting until I went crazy and THIS was exactly my issue. So glad I stumbled upon this.  Many thanks, you're a lifesaver ! ;)