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?
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 file..so 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 Citrix.com 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!