Beacon probing in Citrix Storefront isn’t that well documented and I had a requirement to look into it a little more within some VDI’s themselves. Consider this situation, you have a number of users that have VDI’s this could be 10-100,000 users it doesn’t really matter. You also have Citrix Receiver or Workspace installed within those VDI’s that utilise the native single sign on to a store for published applications etc. A pretty common scenario I’ll think you’ll agree.
As we all know beacon probing is used alongside the native receiver feature to determine if the client machine is inside or outside of the network and it does this by the administrator configuring a number of internal and external beacon that receiver attempts to communicate with. The client machine will determine itself to be inside the network if it can get to the URL defined as internal and the external beacon points are used to verify that the client machines network has internet connectivity and to assist in verifying that the client is outside of the network.
For most organisations there is no need to have separate Citrix StoreFront servers for internal load balancing and external NetScaler Gateway proxy, separate Stores in the same server group make’s much more sense. However, this affects beacon probing as the configuration is global so the URL’s you specify will apply to nearly any and all stores within that group.
This is absolutely fine for client devices that roam such as users laptops, iPad’s etc but consider this behaviour for the VDI’s themselves which will never be outside of the network now if you increase this feature usage to around 10,000 VDI’s this activity doesn’t make too much sense and will generate a fair amount of unnecessary traffic which may have the networks team asking questions.
Receiver and Workspace also poll on regular intervals for its location status so its not just the initial Receiver or Workspace SSO logon that will generate this traffic. From my testing it appears that these URL’s are also retested every 15 minutes.
Additionally, when you add an account to Citrix Receiver or Workspace whether that’s manually through Group Policy or through the StoreFront configuration in Citrix Cloud or on-Prem DDC’s it will also record the default external URL used by the Store.
These details are stored within the registry of the VDI HKCU\Software\Citrix\Receiver\SR\Store\12312312332\Beacons and HKCU\Software\Citrix\Receiver\SR\Store\12312312332\Gateway. The Beacons key has an Internal and External subkey and additionally they will have further subkey’s named Addr0 onwards. The Internal key will generally only have Addr0 as you only specify a single URL for the service to determine the internal connectivity while the external subkey can have multiple keys (Addr0,Addr1,Addr2 etc). Each of the Addr Keys will have a string of “Address” with a value of the beacons configured.
Now theres a couple of ways you can stop the VDI’s from generating the traffic, the first and easiest method is pointing your internal VDI’s to an Internal Only StoreFront store. By configuring it to Internal only Receiver only connects to the service URL for probing it will not attempt to connect to the external ones. You configure store’s to be internal only by unchecking the “Enable Remote Access” checkbox in the Configure Remote Access Settings” option of the store.
If this is not possible and you need to use a store that is configured for External and Internal access then you can use FSLogix Rules Editor to disable the probing.
Firstly you’ll need to install the Rules Editor if you have not yet already which is included in the FSLogix agent download. Once installed create a new Ruleset and configure the following Directory Rule.
HKCU\Software\Citrix\Receiver\SR\Store\*\Beacons\External
HKCU\Software\Citrix\Receiver\SR\Store\*\Gateways
You’ll notice in the path that a wild card is specified this is where FSLogix comes in handy as part of the key value if you remember from earlier is a random string of numbers which is tricky if not impossible to get around with some enhanced profile management type products.
Once that is configured then you just need to add the memberships either by user or group or one of the many other ways available within FSLogix then distribute the ruleset either as part of the next automated build process for your VDI or through Group Policy etc to the C:\%ProgramFiles%\FSLogix\Apps\Rules folder.
Copying the rules into those folders produces instant results and the registry keys will be hidden straight away, so it is easy to test the effect by just exiting the Receiver or Workspace app copying the rules into the folder and then opening it up again.
Once you have confirmed the effect you can simply add the rules into your automated build process and your done.
Author: Dale Scriven
