Desktop close to the user, app close to the data

Picture a global organization with:

• Centralized applications: engineering, finance or line-of-business apps hosted in one primary datacenter, close to their databases and file stores.
• Users distributed globally across several regions.
• Local datacenter presence in each major region.

The design question is how to keep users close to their desktops for a responsive experience, while each application still runs in its own defined location, close to its data. The App Farm also has to stay unreachable from anywhere except the virtual desktop.

If you publish apps directly to every user from the central site, distant users get high latency. If you replicate the apps into every region, you get data-latency problems, licensing overhead and operational sprawl.

The architecture: double hop

Layer	Purpose	Location	Access URL
Desktop Farm	User's daily virtual desktop	Regional datacenter, near the user	desktop.<company>.cloud.com
App Farm	Centrally hosted published apps	Defined app location, near the data	apps.<company>.cloud.com (dedicated)

The flow:

1. The user opens the desktop Workspace URL from any endpoint and launches the desktop from the nearest Desktop Farm.
2. Inside the desktop, the user opens the dedicated app Workspace URL and signs in with SSO.
3. The application launches from the App Farm as a second hop, over the private datacenter-to-datacenter network.
4. If the user opens the app URL directly from a laptop or an external network, no apps are shown.

Figure 1: The double-hop path, and the direct path that is blocked

Restricting the App Farm to the Desktop Farm

I first tried filtering only on the Workspace URL with SmartAccess conditions. Broker simulation looked right, but live enumeration didn't behave consistently. Adding network-location-based Adaptive Access to the same rule gave a reliable result: the app URL and the Desktop Farm's network location must both match.

Step 1: Enable Adaptive Access in Citrix Cloud.

Step 2: Create a Network Location for the Desktop Farm's public egress IP range. Give it a meaningful tag such as DESKTOPFARM and set the connectivity type to Internal, so the launch bypasses the gateway.

Figure 2: Network location for the Desktop Farm egress IP, tagged DESKTOPFARM and set to Internal

Step 3: Configure the access policy on the App Farm delivery group. Select Match all and add both criteria:

• Filter Citrix.Workspace.UsingDomain, with the app Workspace URL as the value.
• Filter Workspace, with the location tag as the value: LOCATION_TAG_DESKTOPFARM.
• Disable or remove any default rule that allows connections without these criteria. Otherwise the restriction can be bypassed.

Figure 3: App Farm access policy, with the URL and location tag combined under Match all

Part of the location tag appears in mixed case in Figure 3. Citrix documents the value in upper case, so use upper case in your own policy. With Adaptive Access on, Citrix treats Workspace requests as Gateway connections, so these criteria belong on the Citrix Gateway connections rule. Also manage users for these delivery groups through Studio policies, which Citrix requires when enumeration depends on network location.

Step 4: Publish each farm to its own URL: the App Farm only to the dedicated app Workspace URL, and the Desktop Farm only to the desktop URL.

Before you widen the scope, validate the rules and check the tags on a live session:

Get-BrokerAccessPolicyRule -DesktopGroupName "<App Farm>"
Get-BrokerSession -DesktopGroupName "<App Farm>" | Select-Object UserName, SmartAccessTags

Validation results

#	Scenario	Path	Result	Network latency	ICA RTT
1	Endpoint → desktop URL → desktop	Endpoint → Gateway Service → Desktop Farm VDA	Allowed	~247 ms*	~290 ms*
2	Inside desktop → app URL → app (SSO)	Desktop VDA → App Farm VDA, same private network	Allowed	~1 ms**	~2 ms**
3	Endpoint → app URL → app	Outside the defined network location	Not enumerated	–	–
4	Endpoint → desktop URL → App Farm apps	Wrong Workspace URL	Not visible	–	–

*The PoC endpoint connected to a distant test resource location. Of the 247 ms, 30 ms was client to Gateway POP and 217 ms was Gateway POP to VDA. With the Desktop Farm in the user's region, the larger segment should drop.

**Both VDAs were on the same private network in this PoC. Treat this as a best case: across regions, hop 2 will rise to the latency between those datacenters.

Figure 4: Hop 1, desktop launched through Gateway Service from the Desktop Farm

Figure 5: Hop 2, app launched from inside the desktop, with the Desktop VDA shown as the endpoint

In monitoring, the published app ran from inside the user's desktop session, which confirms the double-hop launch works. The session topology showed the Desktop VDA as the endpoint connecting directly to the App VDA, with no extra gateway traversal.

Benefits

• Better user experience. The desktop is near the user and the app is near its data.
• Network-restricted app tier. Apps can't be enumerated from outside the defined network location or from other URLs.
• Clean separation. Desktop images and app images can be patched, scaled and lifecycle-managed independently.
• Dedicated app URL. The app tier gets its own front door, policies and authentication controls.
• Regional desktops. Users work from a desktop in their own region, while each app stays in its defined home location.

Wrapping up

Network location gave this design its boundary: the desktop can be used from anywhere, while the App Farm answers only when the request comes from the Desktop Farm through the right URL. The trade-off is a second hop to test and operate.

Have you solved this with double hop, regional app replication or something else? I'd like to hear what worked in your environment.

References

• Adaptive access based on the user's network location
• Resource filtering in Citrix Workspace
• Connectivity to DaaS resources
• Double hop in Citrix DaaS