Forum Discussion
daboochmeister
Cirrus
CirrusCitrix Desktop via APM - APM fails accessing XenApp on :2598, doesn't try :1494 ...?
Config: firmware 11.5.2, Big-IP 4200v, accessing XenApp server on Win2012, running Xenapp version... 7.1, i think
We have an APM webtop configged to replace the Citrix Storefront, by virtue of a remote desktop resource. That's all working correctly, the broker is being accessed cleanly, and the apps permitted the user are being displayed.
But we discovered we have one Citrix server that isn't listening on port 2598 (the CGPAddress from the ICA file). When we run a desktop allocated to that server via the Citrix Storefront, a capture shows that the Receiver app first tries server:2598, but gets a RST back - and moves on to use :1494, and everything works fine.
When we access the same desktop over APM, a tcpdump shows that the F5 attempts server:2598 ... then stops, after receiving an RST back.
Other Xenapp desktops and apps launched via APM run fine - because the XenApp server they're running on are all correctly listening on :2598 (I've verified numerous of them via tcpdump, and the APM is always using :2598).
Of course we can get the one server fixed, so it IS listening on its CGPAddress:port ... but why isn't APM going on to try :1494 if unsuccessful on :2598? Is there any configuration option to make it do so?
Thx!
Michael_Koyfma1Port 2598 is Session Reliability, and its use is governed via XenApp policy, which applies to the entire farm. I don't believe there is a way to configure APM to ignore the policy settings and try regular ICA channel if it gets RST from the XenApp server. I would suggest trying to fix the lone XenApp server if it is indeed part of the same XenApp farm and subject to the same policy.
- daboochmeister
Thank you, Michael. Could you clarify, though - is it by design that APM doesn't try ICA if the CGP port isn't responding? That's clearly Citrix' model (fallback to ICA), as the last couple of Receiver versions have done so (no?). Would it be a defect correction or a new feature if I were to put in a support request for the capability in APM?
In the meantime, is there a way to specify that the APM should always use ICA? (given the network stability on our LAN, I don't think SR gives us much benefit in this situation - but we don't want to turn it off, because we have lots of internal users accessing not via the F5). I'm not even sure this is possible - since the client is going to first attempt SR, I'm not sure what the exchange would look like if APM simply dropped the SR request and wanted to the client to move on to attempt ICA.
- Michael_Koyfma1Couple of thoughts here: 1. There's a big difference between going directly to the XenApp server and going via Gateway(such as Netscaler or F5). Going directly the client connects via certain ports - for direct connections, it can be 2598 or 1494. For ICA proxy connections, all client connections come out on port 443, and then unwrapped and proxied to port 2598 or 1494. I don't know how the behavior is when Netscaler Gateway is in place - but it seems to me that it might be better to control whether SR is getting used or not via SmartAccess filters and/or combination of Citrix policies.
- daboochmeister
Oh, I also wondered what would happen if we rewrote the ICA file on the way out, to specify no SR ("CGPAddress="). That way, it would only affect launches via the F5, and the client would immediately attempt ICA, not even try SR (i think). Thoughts?
- Michael_Koyfma1
You'd have to put another virtual in front of the APM virtual server to rewrite that ICA file - it's possible to try - but I think it's a lot easier to just fix the server than try to disable SR on the fly.