Many customers have coupled the migration from Web Interface to StoreFront with broader support of native Receiver-based connections, as well as a migration from legacy PN Agent deployments to a newer 4.x version of Windows Receiver. Unfortunately, this means that it is not uncommon for Receiver issues and StoreFront issues to be conflated.
The first step in troubleshooting just about any StoreFront issue seen when connecting through Receiver should be to first attempt to reproduce the issue via a web browser connection (whether or not you can do so will eliminate a lot of variables one way or the other). We recently had an example of this in a PN Agent replacement use case that I think may apply to more customer environments out there, so decided to share. This scenario relies on excluding the Receiver configuration from roaming with the user profile, which is not as easy as it sounds.
The scenario we are trying to solve for is allowing users to roam between machines with the same roaming user profile but different Receiver account configurations, have Receiver update with the new account information (forget the old account and add the new one), and update all application shortcuts in the start menu/desktop (which may or may not be overlapping between the various accounts) all seamlessly to the user.
Where this gets really interesting is the added requirement that self-service be disabled and the various StoreFront URLs are unknown to users, therefore published applications are only accessible via the start menu (or desktop). This would apply, for example, if users have access to different VDI desktops with different Receiver configurations to pull in published applications (maybe one production and one failover or several production across different geographical regions). This particular customer chose to assign the Receiver configuration via the Delivery Group in Studio, but this would also apply if Receiver were being configured via GPO.
Sounds easy enough and, per my earlier point, works very easily through a web browser; you can log into as many different StoreFront URLs as you want across different tabs and the applications you have available in each configuration will show up as designed. If all Stores are mandatory; all applications will appear. Native Receiver, however, caches account information in the user profile as well as application shortcut data, which complicates the ability to seamlessly roam across machines with different StoreFront accounts because information from the last configuration is still present in the profile. Note that all of this complexity is dependent on the user profile being shared across these different machines; if user profiles are not roaming across these devices, then these various Receiver configurations will remain independent.
I’ll avoid the play-by-play of issues we encountered when testing this and skip to the solution. We ended up having to configure several registry, folder, and file exclusions (customer was using Citrix Profile management) to get this to work seamlessly as follows:
|Registry||Software\Citrix\Dazzle||This is the key that is actually updated by the Studio or GPO settings. Although we determined it was not strictly required to be excluded (it was updated automatically), since we know Receiver configuration information is stored here, it does not hurt to help provide a clean slate on each login|
|Software\Citrix\Receiver||The “SR” and “Inventory” sub-keys cache data about the configured account (mostly URLs) and are not updated based on Studio or GPO settings. If these are not excluded, Receiver will continue to try to reach out to the original Store configured and you will get errors trying to connect to any other Store as the Dazzle key will be pointing to something different than what is configured here|
|Software\Microsoft\Windows\CurrentVersion\Uninstall||All application shortcuts in the start menu reference this key. Whether the application is subscribed or mandatory, this key is referenced. This was a surprise as we thought eliminating subscriptions would simplify things (Receiver should just show everything), but if this key is not excluded, overlapping applications will not be updated as Receiver thinks they are already cached. For example, if account A includes published Office and account B also includes Office, without excluding this key, the Office applications will not be updated and will fail to launch.|
|Folder||AppData\Local\Citrix||*Only required if AppData\Local is not excluded overall
This folder includes the cached icon files for the applications and an XML file with a record of the account details and cached applications (under Citrix\SelfService).
|File||AppData\Roaming\Microsoft\Windows\Start Menu\Programs\*.lnk||*Only required if the Start Menu is roaming with the profile.
This prevents the start menu application links from roaming with the user. This may have to be adjusted if a specialized folder has been created for Citrix applications. If this is not configured, duplicate shortcuts in the start menu will be seen for any applications that overlap between the various accounts.
In conclusion, although this specific scenario may not apply to you, if you are looking for a way to stop the Windows Receiver configuration from roaming with the user, the above configurations should get the job done. Hope this helps others out there looking for a similar solution!