Migrations between XenApp versions or from XenApp to XenDesktop (or vice versa if you like), can be a hassle and become tricky in case of phased migration strategies (where users are moved to the new platform in groups) or if there is no “in product” migration path (as with XenApp 6). Users may get confused when the Web Interface address, they are used to connect to in the morning, is changed or they see application icons multiple times. On the other hand administrators may have implemented a myriad of application access user groups, which they do not want to change nor duplicate just for migration purposes.
I’m quite sure there are many strategies to tackle this, but within this blog I’d like to focus on some standard Web Interface functionalities such as Multiple Farm Aggregation and User Roaming.

Multiple Farm Aggregation

The first functionality of Web Interface that is relevant to us during migrations is called “Multiple Farm Aggregation”. This has been it the product for many years now, but it is still not common knowledge everywhere.
So what does it technically do and how does it help?
The “Multiple Farm Aggregation” feature allows a single Web Interface site, regardless if it’s a services or a regular web site, addressing multiple XenDesktop / XenApp farms at the same time.
So in a default configuration the Web Interface application enumeration process is as follows:

  1. User connects to the Web Interface web site and enters its credentials (Note: credentials are send as clear text across the wire by default, so you may want to use SSL here)
  2. Web Interface forwards the credentials to one of the XenApp XML-Brokers configured for the site (Note: credentials are send as clear text across the wire by default, so you may want to use SSL here as well)
  3. The credentials are validated / user will be authenticated within the Active Directory
  4. The XenApp XML-Broker will enumerate all applications / desktops which the user is entitled to access
  5. List of applications is send back to Web Interface
  6. Web Interface compiles a web site with all resources and presents it to the user
  7. The user will click on a application or desktop and a ICA/HDX session will be established

So far I guess it is common knowledge.
Now we need to open the Web Interface management console, select a web / services site, edit the server farm settings and (surprise, surprise) add another XenApp / XenDesktop farm.

Here you can add as many Citrix XenApp / XenDesktop farms as you want, but you need to keep in mind that if one farm cannot be contacted the whole Web Interface application enumeration process will stop until the timeout is reached.
For our scenario we want to add a XenApp 6 farm in addition to the already configured XenApp 5 farm.

After we closed the “Manage Server Farms” options window and ran a iisreset (to be on the safe side), the application enumeration process is changed as follows:

As you can easily figure out by looking at the diagram, the application enumeration process keeps the same as with one farm, except for the fact that Web Interface will forward the user credentials to both farms and consolidate the responses. This means a user will see a single web site showing all applications as well as desktops from both “worlds”.
This even works for mixed environments with XenApp and XenDesktop, where you get the following:

This approach has been a best practice for migrations since many years now, as it allows building a new, fresh and shiny farm in parallel without impacting the old environment. And, as a great benefit, it allows moving users to the new farm by just assigning the appropriate users groups to them. So no client side configuration change is required.

So why would we need anything in addition to this?

When we dig a little deeper into this approach, we will find a little downside. Just imagine you have installed and published Office within your old farm. Typically you would have assigned a dedicated application access group like App_Office to it, to allow access to Word, Excel and all the other programs to a specified group of users only.

So you now install and publish Office within your new farm as well. It is very tempting to use the same application access group (App_Office for our example) here as well, as all your processes and procedures referring to group names don’t have to be changed and the guys at your helpdesk don’t get confused with new group names. The problem is, in the moment you configure your new farm with old application access groups, all user will get the apps from both worlds. Given you’re using the same icons in both farms, the users cannot differentiate between the apps and will get confused.
So the common alternative would be: create new access groups and change your processes and procedures.
But there is a better solution out there. It has been a feature of Web Interface since some time now, but it is still widely unknown. The feature is called

User Roaming

When using the “User Roaming” feature the application enumeration process will be changed slightly, but with great effect.
To enable the feature we unfortunately cannot use the Web Interface Management Console. We have to go directly to the WebInterface.conf file of the Web Interface site we want to modify.
By default you can find the file at: C:\inetpub\wwwroot\Citrix\XenApp\conf. Within the file you will find a line similar to:

“Farm1=xa01w2k8r2.citrus.local,xa02w2k8r2.citrus.local,Name:XA6,XMLPort:80,Transport:HTTP,SSLRelayPort:443,BypassDuration:60,LoadBalance:Off,TicketTimeToLive:200,RADETicketTimeToLive:200”

This line basically contains all configuration settings to allow Web Interface talking to the XenApp 6 farm within my test environment.
A similar entry starting with Farm2= can be found at the very end of the WebInterface.conf file containing all information for communication with the XenApp 5 farm, we added earlier.
Next to the Farm1=… entry we can find:

“# Farm1Groups=domain\group”

This is the default example we are going to work with to enable the User Roaming feature. Here we can specify a user group or even a list of groups, which has access to Farm1. Users not member of any of the groups listed here, will not see any published applications or desktops hosted within Farm1 (our XenApp 6 farm).

In a first step we create two user groups, within the Active Directory.

  • Old_Farm_User_Group: Contains all users currently accessing the XenApp 5 environment.
  • New_Farm_User_Group: Does not contain any user in the beginning.

Secondly we add the following lines to our WebInterface.conf file:

Farm1Groups=citrus\New_Farm_User_Group
Farm2Groups=citrus\Old_Farm_User_Group

Now we can save the file and run an iisreset, which will change the application enumeration process as follows:

  1. User connects to the Web Interface web site and enters its credentials (Note: credentials are send as clear text across the wire by default, so you may want to use SSL here)
  2. Web Interface forwards the credentials to one of the XenApp XML-Brokers of the first farm configured for the site (Note: credentials are send as clear text across the wire by default, so you may want to use SSL here as well)
  3. The XML-Broker authenticates the user within Active Directory.
  4. A list of all groups the user belongs to is send back to Web Interface.
  5. Web Interface browses the list of groups and tries to match with the groups configured at Farm1Goups / Farm2Groups, to work out all farms a user is allowed to connect.
  6. Web Interface forwards the credentials only to farms the user is allowed to connect to (Note: Within the example outlined in the diagram above, the user is member of the “Old_Farm_User_Group” only.
  7. The credentials are validated / user will be authenticated within the Active Directory
  8. The XenApp XML-Broker will enumerate all applications / desktops which the user is entitled to access
  9. List of applications is send back to Web Interface
  10. Web Interface compiles a web site with all resources and presents it to the user
  11. The user will click on a application or desktop and a ICA/HDX session will be established

Very important to note is, that the first farm configured at Web Interface needs to be based on XenApp 6 (or higher) or XenDesktop 4 (or higher)! The XML services of versions earlier than that, do not support the XML requests required for the user roaming feature.
So for our migration example, this means we can build the new farm equal to the old environment and even add it to Web Interface without impacting the users. For the actual migration process, we just need to remove a user from the “Old_Farm_User_Group” and add him / her to the “New_Farm_User_Group”.

..and voilà we’re done.