1Y0-401 · Question #197
How should the architect configure the virtual servers on the appliance?
The correct answer is A. Create one virtual server and bind it to a session policy that is configured in ICA Proxy mode using the. The architect should configure a single virtual server and bind it to a session policy set in ICA Proxy mode, using the specific configurations for that mode.
Question
Options
- ACreate one virtual server and bind it to a session policy that is configured in ICA Proxy mode using the
- CCreate three virtual servers configured with the subnets of the three sites and bind them to redirection
- DCreate six virtual servers in high-availability pairs configured with the subnets of the three sites and bind
How the community answered
(30 responses)- A83% (25)
- C7% (2)
- D10% (3)
Why each option
The architect should configure a single virtual server and bind it to a session policy set in ICA Proxy mode, using the specific configurations for that mode.
For remote access to Citrix Virtual Apps and Desktops, a common and efficient design involves a single virtual server configured with an ICA Proxy session policy. ICA Proxy mode specifically handles the secure proxying of ICA traffic, simplifying external access while enforcing security policies.
Creating three virtual servers configured with subnets of three sites and redirection policies is generally unnecessary for basic ICA Proxy functionality, which often centralizes access through a single external entry point. Redirection policies are more for web content routing than ICA session proxying.
Six virtual servers in high-availability pairs configured with site subnets is excessive and overly complex for enabling ICA Proxy access, which typically leverages a single virtual server for external connectivity. This approach adds unnecessary overhead and management complexity.
Concept tested: Citrix ADC ICA Proxy configuration
Source: https://docs.netscaler.com/en-us/citrix-gateway/current-release/configure-connections-to-private-network/configure-ica-proxy-for-users-to-access-xenapp-and-xendesktop-resources.html
Topics
Community Discussion
4The answer is A. The Citrix Gateway documentation for this architecture calls for a single virtual server bound to a session policy configured in ICA Proxy mode, because ICA Proxy is the mechanism that allows the gateway to broker and proxy ICA connections to back-end XenDesktop or XenApp farms without requiring a full VPN tunnel on the client. Citrix design guidance does not require you to multiply virtual servers by site or subnet count, because the session policy, not the virtual server, is what controls the proxy behavior and the StoreFront or Web Interface target. Options C and D introduce unnecessary complexity by tying virtual server count to site subnets or high-availability pairs, which contradicts how NetScaler Gateway is actually documented to handle multi-site Citrix deployments. One virtual server, one session policy in ICA Proxy mode is exactly what Citrix says to do, and that is what the exam expects you to know.
Saw this exact scenario on my 1Y0-401 sitting and my first instinct was C because the multi-site setup screamed "separate virtual servers per subnet," but then I remembered you do not need that complexity when ICA Proxy handles the session brokering cleanly through a single VS bound to the session policy. A is correct, full stop, and anyone who overthinks the site count and reaches for C or D is falling for the distractor.
Option C is really tempting because you see "three sites" and your brain just wants to map one virtual server per site, but that is a red herring because the question is about ICA Proxy mode, not about geographic routing. You want one virtual server bound to a session policy in ICA Proxy mode, so A is the right call here.
I kept second-guessing myself on this one because option C sounded reasonable with the three-site subnet breakdown, but once I thought about how ICA Proxy mode works with a single unified access point for all the remote users, it clicked that A is the right call. The subnet-based split in C just adds unnecessary complexity when one virtual server bound to the session policy handles what the question is actually asking. Anyone else get tripped up by C, or did D pull you in with the HA pair logic?