1Y0-A22 · Question #108
Scenario: A XenApp Administrator has configured Multi-stream ICA in an environment. A user reports performance issues and the administrator discovers that Multi-stream ICA is NOT active for that…
The correct answer is D. Upgrade to the latest version of Citrix Receiver. See the full explanation below for the reasoning.
Question
Scenario: A XenApp Administrator has configured Multi-stream ICA in an environment. A user reports performance issues and the administrator discovers that Multi-stream ICA is NOT active for that user's session. What should the administrator do to resolve this issue?
Options
- AChange the color quality to 16-bit.
- BEnsure that port 1494 is available.
- CAdjust the progressive compression level.
- DUpgrade to the latest version of Citrix Receiver.
How the community answered
(61 responses)- A16% (10)
- B3% (2)
- C7% (4)
- D74% (45)
Community Discussion
6
Orla P.May 1, 2026The answer is D, upgrade to the latest version of Citrix Receiver. Multi-stream ICA has to be supported on both ends of the connection, and older Receiver builds simply do not have the capability to negotiate it, so even a perfectly configured policy on the XenApp side will not activate the feature if the client cannot meet it halfway. The other options chase the wrong problems, port 1494 is just the standard ICA port and has nothing to do with multi-stream negotiation, color depth and compression settings are tuning knobs that only matter once the session is already established correctly. When you see a scenario where a feature is configured server-side but not showing up for a specific user, always look at the client version first.
Mateus R.Apr 14, 2026Multi-stream ICA is like a highway that splits traffic into separate lanes for voice, video, and regular data, but the on-ramp only exists if your car supports it, and older Citrix Receiver versions simply do not have that on-ramp built in, which is why upgrading the client (option D) gets the feature working again. Do you know off the top of your head which minimum Receiver version Citrix required before Multi-stream ICA would negotiate properly on the client side, or is that detail still fuzzy for you?
Ola B.Apr 17, 2026The highway analogy is solid, though the more precise line to draw is that it is not just about the Receiver version in isolation, your NetScaler or Delivery Controller policy also has to have multi-stream enabled on the server side, because a fully updated Receiver sitting behind a policy that never advertises multiple streams will still fall back to single-stream every time.
Dervla O.Apr 6, 2026Port 1494 bait is strong, but client version gates Multi-stream ICA: pick D.
Ola B.Apr 27, 2026Multi-stream ICA splits traffic across multiple ports using different QoS priority levels, and the color depth setting directly affects how the ICA stream is negotiated at session startup, so changing to 16-bit color quality forces the client and server to renegotiate the stream parameters, which in my lab testing has kicked Multi-stream ICA into an active state when it was otherwise sitting idle. I know it sounds counterintuitive, but color quality changes the way the display data is packed and transmitted, and that handshake process is exactly where Multi-stream ICA activation gets triggered or skipped. Spin up a quick test environment with a XenApp 6.x setup, configure Multi-stream ICA in your policies, then watch what happens to the session details after you drop the client color setting from 32-bit down to 16-bit, you will see the stream behavior change. That lab exercise is what sold me on A, and I think anyone who actually builds the scenario rather than just reading the docs will land in the same place.
Mateus R.Apr 28, 2026Ola, that is a creative lab observation, but the correct answer is D because Multi-stream ICA requires a client reconnection to actually activate, meaning the session must be disconnected and reconnected after the policy is applied, not just adjusted mid-session via color depth changes.