There are quite a few customers that are upgrading their environment to either Citrix DaaS or the latest Citrix Virtual Apps and Desktops (CVAD) 2203 LTSR or a CR release. The majority of these upgrades are performed as a parallel build. There are several reasons for that, such as OS upgrades, phased migration plans, etc.
For a refresher on site aggregation, please check out this Citrix Tech Zone article. In short, this a feature presently unique to StoreFront and not found in Citrix Workspace service which allows administrators to configure user farm mapping (only enumerate certain Citrix Sites based on user group membership to reduce the number of Stores) and/or aggregating multiple Citrix Sites for the purposes of load balancing or failover through aggregation mechanisms.
Now here is a caveat when it comes to Citrix StoreFront server parallel build upgrade plan. I already wrote about StoreFront SRID in the Issue: Duplicate Icons in Citrix Workspace App After StoreFront Migration (ferroquesystems.com) article and the impact on the Citrix Workspace app. In this article, I want to cover StoreFront subscriptions and site aggregation settings.
Let’s begin with the statement from Sarah Steinhoff’s StoreFront Aggregation Groups Revisited | Citrix Blogs article (no longer available as of 2024). In addition to this statement, I would strongly recommend reading this article.
“If your StoreFront environment went live without aggregation groups (but with subscriptions enabled) and you subsequently decide to configure aggregation groups, all user subscriptions for aggregated resources will disappear because of the change in subscription record format. A workaround for this is to export the subscription database, replace all records for resources that will be aggregated with the proper format, and re-import the subscription database after the configuration of aggregation groups. Depending on the number of unique resources, this may be a very easy or a very onerous task, but it is a required task nonetheless unless you want all users to re-subscribe to their apps.”
Here is where it becomes interesting. Let’s see how the subscription.txt file looks after we export it from a StoreFront before site aggregation.
S-1-2-34-1234567890-123456789-1234567890-123456 CVAD Site.Application A B96549B81E242FB8482388C55E2E9834 subscribed dazzle:position b position g
Let’s review this line of the subscription.txt file
- S-1-2-34-1234567890-123456789-1234567890-123456 – User SID
- CVAD Site – Site name (as defined in the StoreFront store)
- Application A – Application/Desktop name
- B96549B81E242FB8482388C55E2E9834 – Unique, per subscription GUID
- subscribed dazzle:position b position g – Application/desktop icon position on the screen so that icons maintain their order
To allow for the subscription to be imported properly to the new StoreFront store, you need to replace Site name with the Aggregation Group name in the proper format. In general <Site Name>.<Display Name> needs to be replaced with <AggregationGroup>.<DisplayPath>\<DisplayName> To find aggregation group name check you web.config for the Store (and not StoreWeb).
In our example, let’s say our aggregation group is called Aggregation Group 1, and the above line will need to be modified to read:
S-1-2-34-1234567890-123456789-1234567890-123456 Aggregation Group 1.\Application A B96549B81E242FB8482388C55E2E9834 subscribed dazzle:position b position g
This is just the first part of the problem. Next is the Application/Desktop Name. On some occasions, you will modify your subscription.txt file but there will be some icons missing. Those icons are for the applications whose name has been changed. Once we run Get-BrokerApplication PowerShell command on the Delivery Controller, there are three properties we need to look up:
- ApplicationName: The simple name of the application within its parent admin folder (if any)
- BrowserName: Unique browser name used to identify this application to other components in the site. This value is not visible to the end users.
- PublishedName: Published name of the application as seen by the end user. If not specified, it will use the Application Name.
Once we publish the application, we can differentiate between ApplicationName and PublishedName properties in the GUI, but BrowserName inherits the PublishedName property once the app is created. If we change PublishedName, the BrowserName stays the same as when it was created.
Now, what happens to the subscription.txt? The Application/desktop name is actually BrowserName within the subscription.txt file. So if the application has been renamed, after the subscription is created, the application name in the file won’t change. This is where we run into the problem, and how to fix this.
One way is to filter the subscriptions.txt file, find applications that have their name changed, and replace it with the ApplicationName property.
The second way is to use a PowerShell script and make sure BrowserName matches ApplicationName using Set-BrokerApplication command for applications that have their name changed.
