Hub-and-Spoke Networking With FSLogix on Azure Files
Fabrikam Manufacturing runs a hub VNet in West Europe connected to on-premises by ExpressRoute, plus two peered spokes: spoke-prod in West Europe hosting 300 multi-session VDAs managed by Citrix DaaS, and spoke-dr in North Europe. Two Cloud Connectors sit in the hub. FSLogix profile containers live on a premium Azure Files share in a storage account that still permits public network access; the share is AD DS authorised and each VDA mounts it over the public endpoint. After a recent NSG tightening, roughly one in ten users sees a 60-second black screen followed by an FSLogix error, three VDAs dropped out of the domain, and the network team now refuses to route spoke-to-spoke SMB through the hub firewall. Peak profile load on the share reaches 9,000 IOPS with 300 users; the share is provisioned at 2 TiB.
1. Explain the most probable cause of the intermittent FSLogix failures and give the corrected storage and network design.
Read the worked answer
Most probable cause. The VDAs resolve the storage account to its public endpoint and open SMB 445 outbound to the internet. The recent NSG change broke that path for whichever VDAs landed on the tightened subnet or rule, which explains why the failure rate is partial rather than total, and why the symptom is a long stall before the profile error rather than an immediate failure. VDAs losing domain trust fits the same story: the machines lost outbound access to the DCs at the same time.
Corrected design
- Create a private endpoint for the file subresource in spoke-prod, and one in spoke-dr, so the profile data path never leaves the VNet peering.
- Link the
privatelink.file.core.windows.netprivate DNS zone to both spokes and to the hub. VNet peering is not transitive for DNS resolution, so linking only the hub will leave the spokes resolving the public name. - Disable public network access on the storage account once the private endpoints are validated, and re-check the flow logs.
- Keep AD DS (Kerberos) authentication: it requires line-of-sight to a domain controller for both the machine account and the user ticket, so confirm DC reachability over the hub or from a DC in Azure, and that the storage account's computer account exists in AD.
- Confirm SMB 445 outbound is allowed to the private endpoint IP only, not to a 0.0.0.0/0 rule that the next NSG review will remove.
Capacity check: 9,000 IOPS against a 2 TiB premium share is close to its provisioned ceiling. Verify the current premium sizing table; if headroom is under 30 percent, grow the provisioned size or split shares per delivery group.
2. Where should the Cloud Connectors live given the spoke-to-spoke routing restriction, and what exactly must they reach?
Read the worked answer
What connectors need
- Outbound TCP 443 to Citrix Cloud. No inbound ports and no public IP are required; the connection is initiated from the connector.
- LDAP and Kerberos to domain controllers, plus DNS resolution of the AD domain and of Citrix Cloud endpoints.
- Time synchronisation, because Kerberos tolerates only a few minutes of skew.
Placement decision. The hub currently hosts the connectors, and that is acceptable only if the hub has a supported, permitted path to the DCs and is not dependent on spoke-to-spoke routing. With the new restriction, the risk is that a connector in the hub reaches a DC through the firewall for some flows and not others, producing intermittent registration loss that looks like a Citrix fault but is a routing fault.
Recommendation
- Deploy two connectors per region, in a dedicated subnet inside the spoke that hosts the VDAs, or in a small dedicated services VNet peered directly to each spoke. This removes any dependence on spoke-to-spoke traffic and keeps connector-to-AD traffic inside the region.
- Keep them out of forced tunnelling. If the default route sends 443 to an on-premises proxy, either add a UDR for the Citrix Cloud endpoints or exclude the connector subnet. This is the single most common cause of 'connector went offline' tickets.
- Do not place connectors on the VDA subnet if the VDA subnet has restrictive NSGs that change often; the connector becomes collateral damage in every security review.
- Size for failure: two connectors per region minimum, on separate hosts, and monitor their heartbeat rather than waiting for users to report registration errors.
3. West Europe is the production region and North Europe is DR. What has to be true in North Europe before it can serve users, and what part of this design is most likely to be untested?
Read the worked answer
Minimum viable DR in North Europe
- A separate host connection to the North Europe subscription, with a catalog pre-provisioned to at least the floor capacity, and machines registered so brokering has somewhere to send users. Provisioning during a regional outage is not a recovery strategy.
- A private endpoint for Azure Files in spoke-dr with the private DNS zone linked to spoke-dr, plus a tested authentication path to a DC that survives the loss of the West Europe DCs.
- Profile data must actually exist in North Europe. Azure Files zone-redundant storage protects against a zone failure inside one region, not against regional loss. Either use a storage technology with cross-region replication that you have failed over in a test, or accept a documented profile-rebuild fallback and say so to the business.
- Cloud Connectors in North Europe with their own outbound path, so registration does not depend on the West Europe hub.
What is almost certainly untested: the DNS switch for the storage account and the profile path. Teams routinely test 'can a VDA boot in DR' and never test whether the user's FSLogix container mounts, which is the step that produces the 60-second black screen in production.
Test script: force the DR catalog to serve a pilot group, log in with real profiles, measure logon duration against the West Europe baseline, and only then remove the pilot restriction. Record the numbers, because 'DR works' without a logon-time figure is an opinion.