Introduction

A Citrix migration can bring the new Delivery Controllers online while StoreFront still brokers app and desktop launches through the old ones. Users see the right storefront URL but sessions enumerate from the retired site, one store works while another still launches against the previous controller, or launches fail only after the old controller is shut down because StoreFront stores, XML service bindings, and NetScaler integration often move in stages.

Treat this as a brokering-path problem instead of a generic Citrix outage. Start by checking which Delivery Controller an affected StoreFront store actually uses for enumeration and launch, because migrations often validate the new Citrix site manually while production stores still rely on older controller group definitions.

Symptoms

  • StoreFront still brokers apps or desktops through the old Delivery Controller after migration
  • Users can open the Citrix portal, but resource launch still depends on the retired controller
  • One store, site, or gateway path uses the new controller while another still uses the old one
  • Launches fail only after the previous Delivery Controller is disabled
  • Resource enumeration looks inconsistent across stores or Receiver/Workspace clients
  • The issue started after moving Citrix controllers, StoreFront, or ADC gateway integration

Common Causes

  • StoreFront stores still list the old Delivery Controller or XML broker endpoint
  • Store subscriptions or resource aggregation settings were updated in one store but not another
  • NetScaler or Citrix ADC integration still hands sessions to the previous StoreFront or controller path
  • Automation or StoreFront replication restored an older controller list
  • DNS aliases or load balancer VIPs for XML services still resolve to the old controller
  • Validation confirmed the new controller accepted test launches but did not verify which broker production StoreFront stores actually used

Step-by-Step Fix

  1. Capture one affected StoreFront store and record the exact Delivery Controller or XML service endpoint it uses for resource enumeration and launch, because the live broker path determines where sessions are really handed off.
  2. Compare that active StoreFront broker path with the intended post-migration Citrix design, because one stale controller group can keep many users tied to the retired site.
  3. Review StoreFront store configuration, Delivery Controller lists, XML service bindings, subscriptions, and any load balancer or ADC integration for references to the old controller, because Citrix launches depend on storefront, broker, and gateway layers together.
  4. Check each store, Receiver for Web site, and gateway-integrated path separately if behavior differs, because migrations often fix one storefront while another still points at the previous controller.
  5. Update the authoritative StoreFront and brokering configuration so affected stores enumerate and launch through the intended Delivery Controller set, because standing up the new Citrix site alone does not retarget existing stores.
  6. Run a controlled app or desktop launch from an affected store and confirm the intended controller handles enumeration and brokering, because a visible storefront login page does not prove the right broker is being used.
  7. Verify the old Delivery Controller no longer receives broker traffic from migrated StoreFront instances, because split Citrix paths can remain hidden while both controller pools stay reachable.
  8. Review STA entries, gateway callback settings, and StoreFront replication if launches still fail, because the destination can be correct while gateway trust or replicated config still breaks session handoff.
  9. Document which team owns StoreFront stores, Delivery Controller registration, and gateway integration so future Citrix cutovers verify the actual broker path before retiring the previous controller set.