Citrix StoreFront Beacons Explained

Beaconing is one aspect of StoreFront and Receiver that I get asked about frequently. Oddly enough, it’s also one of the few pieces that I get questions on from both clients AND colleagues who are working on understanding them. So this blog post will hopefully help those who may not fully understand beacons by answering these three things: What it is, Why its important, and How it works.

What Are Beacon points?

Let’s start with the Citrix definition:
Citrix eDocs

Citrix Receiver uses internal and external URLs as beacon points. By attempting to contact these beacon points, Citrix Receiver can determine whether users are connected to local or public networks. When a user accesses a desktop or application, the location information is passed to the server providing the resource so that appropriate connection details can be returned to Citrix Receiver. This enables Citrix Receiver to ensure that users are not prompted to log on again when they access a desktop or application.

So beacon points are just URL’s that Citrix Receiver tries to contact to figure out where it is. Is it outside the network or inside? That will of course determine if they connect directly to the StoreFront load balanced VIP on a NetScaler (if you deployed an HA pair of StoreFront servers, and you did RIGHT!?) or if it will connect via the NetScaler (Access) Gateway. By default, StoreFront is going to use your internal services URL (StoreFront LBVIP) for the internal Beacon Point, and you would want to set the external to some highly available websites that you know should always be accessible.

So to sum up in a single sentence what beacons are: Beacons are URLs that Receiver uses to determine its location and connection method based on that location.

Example screenshot from a StoreFront 2.0 deployment below.


Why Are Beacons Important?

Technically, they matter because they direct Receiver to connect to your Xen* infrastructure via the the correct method, either AGEE or SF LBVIP.

Beyond the technical reasons, beacons are important because it’s about moving away from URL’s..its inconvenient for a user to have to remember a specific URL to access their applications and/or desktops. Its another hoop that we made our users jump through to get to what they need. By eliminating that, all they need to know is to get Receiver from their respective app store. From there it’s as simple is entering their corporate email address (because you configured email based discovery, RIGHT?) and everything they need is available to them. In my opinion this is paramount because we are finally making strikes at the user experience now, leveraging Receiver and beacons to make it simple for the end-user which is what we should all strive for.

How Do Beacons Work?

So technically this should be how does RECEIVER work with beacons..but oh well. First, your internal beacon should (of course) not be resolvable externally. This is a big change from the web interface days where you normally had the same internal and external URL setup for your users to access, in fact if you used the same internal name on your StoreFront LBVIP DNS entry and external AGEE entry it will break receiver.

Most clients run split-brain DNS where they have an internal zone that is a duplicate of their external namespace (read HERE to understand more). In this case its easy, our internal beacon (by default) is your StoreFront service URL or it can be some other internal highly available server, really doesn’t matter.

Secondly, in regards to order of operations it will check internal beacons first then move to external. Another thing to be aware of is it considers ANY http response a valid response. You may have run into this, but OpenDNS is notorious because when you are external and try to resolve a (then) unresolvable internal beacon FQDN where the domain is covered by a wildcard certificate it hoses your Receiver and you can’t connect.

I should also add, beacons are provided from StoreFront to receiver in the config if you go changing your internal beacons after you’re users are configured…ehh..just don’t. If you do, you have to make sure users update their configuration file via a web store or export it from StoreFront and distribute it. StoreFront is going to default to the internal services URL for internal beacon and for external it will use the NetScaler Gateway information you enter into StoreFront and as the primary and secondary external beacons.

Finally..don’t get confused..beacons are nothing more than connectivity checks..your actual StoreFront/Access Gateway URL’s are independent of the beaconing checks. Again though, use one URL for your internal StoreFront LBVIP and it should not be resolvable externally, and another URL for your Access Gateway external access. If you follow my post on deploying StoreFront you’ll be fine though, you can find it HERE.

Hope this helps someone out there!


9 thoughts on “Citrix StoreFront Beacons Explained

  1. Pingback: How to... Installing and configuring Citrix StoreFront, the web.config file !

  2. Thanks for the great post.

    I have a doubt though. Does beacons ever come into picture if I try to add FQDN directly.

  3. Hey there, great article. Only thing I’m confused with, is regard to the external beacons… in so much that any URL i provide my storefront for the external beacon, is going to be internally visible also? (ie , facebook… or indeed the external namespace of our netscaler does also resolve internally) .. so wouldn’t this confuse the receiver into thinking its external? (because it can resolve those hosts) ?

  4. Thanks. One question – if we wanted to force users to always go via the Netscaler, could we create a false internal beacon URL that is guaranteed to fail?
    The reason I ask is that internal users on non-domain joined machines / mobiles do not necessarily trust the Certificate on storefront that comes from an internal CA. As a result they are ok when connecting from outside the corporate network but get errors when connecting within the corporate network.

    • I am also very interested to force all users to go via Net Scaler no matter what so the fake internal beacon idea is great — did it work for you?

  5. Pingback: Citrix Receiver und Outlook Anywhere vs. Telekom Navigationshilfe - derTest - – derTest –

  6. Pingback: Citrix not working externally via gateway; ICA file does not contain gateway address or STA «

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s