Forcing users to execute XenApp applications on specific sets of servers is something you might want to do for a number of reasons. In my case, I primarily run into this requirement during phased migrations, but there are many situations that may push you towards it.
Often I do projects where components or software within the XenApp infrastructure are being upgraded, and customers wish to take a slow migration path towards it, to deal with issues as they arise, rather than a “big bang” approach. Take, for instance, the latest example of this I came across, where AppSense (Ivanti) DesktopNow was being upgraded for the whole Citrix farm. The customer wished to start by updating a small number of Citrix XenApp servers which would then get the new agents and point to the new database. A small number of users would migrate across, run their applications, and feed back any issues.
Over time, more users would be migrated and more servers pointed to the new Ivanti infrastructure, and as this happened, more XenApp servers would be moved over. Eventually, the “rolling” upgrade would finish, hopefully with all problems ironed out as they occurred. The idea was to reduce the impact to the business, to not swamp the IT department with migration issues, and to allow quick rollback if anything went wrong.
Of course, this all depends on whether you can force the “migrated” users to open their XenApp applications on the “migrated” servers, whilst the “non-migrated” users continue to use the “non-migrated” servers! Now, the first thought everyone has in this situation is simply – “duplicate the applications”. Duplicate all the apps, assign one set of applications to “migrated” and one set to “non-migrated” – easy enough, right?
Unfortunately, it can get messy, and with lots of applications there is often a lot of time and resource involved in the duplication anyway. I’ve seen enterprises where a lot of migrations and testing have left Citrix XenApp farms chock full of duplicated, redundant and orphaned applications. I’ve also seen farms where vigorous duplication has also duplicated keywords to lots of applications that shouldn’t have had them! In short – it’s cleaner, easier and less hassle in the long run if there were an easy way of maintaining one set of applications, but forcing subsets of users to run said applications on particular subsets of servers.
So how can we achieve this? It’s not as simple as setting up something like Worker Groups in XenApp 6.5, because even with two Worker Groups assigned to a single application, there’s no way to preferentially direct users to one or the other. We will look at this for both Citrix XenApp 7.x and Citrix XenApp 6.5, because I have had to do both recently, and it makes sense to document both ways for posterity.
Pre-requisites
Obviously, you can’t get away from the fact that you need to separate one set of users from the other! 🙂 So the first task is to set up two Active Directory groups, one for migrated users, one for non-migrated users, in this example. And also obviously – make sure there are no users that are members of both groups.
So, how do we achieve this?
XenApp 7.x
On XenApp 7.x, there is no native Worker Group functionality. What is present, is a function called Tags that can be used to create the same delineations between sets of machines in a site.
I’ve already set up a Delivery Group (called, imaginatively, Delivery Group 001) and added two VDA machines to it. I’ve also created a test application (cmd.exe) within the Delivery Group. But as it stands, publishing the application would run it on either of the VDAs within the Delivery Group.
First of all, we need to Tag the VDAs so that they are able to be treated as disparate groups. We do this by setting Tags for the machines in the Search area of the Citrix Studio console.
Right-click on the first machine, and choose the Manage Tags option. On the next dialog box, choose Create to set a new tag
Enter a name and, optionally, a description for the tag before clicking OK. Repeat this until you have as many tags as are necessary.
Now, apply the first “worker group” tag to the first server by checking the box next to it
Once you click Save the tag will now be applied to the machine. Apply the tags as necessary to all of your XenApp servers to separate them into what are now effectively “worker groups”
So now we have tagged the first machine, UKSLRD002 in this case, as belonging to “Worker group 1”, and the second machine, UKSLRD003, as belonging to “Worker group 2”.
We already mentioned that we have an application published to the Delivery Group, in this case cmd.exe
This application is obviously published to all the users of the Delivery Group, but we want to make sure that our users from the “Non-migrated users” group only run their applications on the first server, and the users from the “Migrated users” group only run their applications on the second server.
To do this we use Application Groups. Right-click on the Applications node and choose Create Application Group. After the initial screen, check the box to “Restrict launches to machines with tag” and select the first tag group we set up.
On the next screen, select the user group who will have access to the application through this group.
Finally, we need to add the application which we have already created to this application group.
Once you have set all this up, review the Summary, give the group a name, and click Finish.
Repeat the above process for the second server, but change the tag to the second “worker group” instead, and apply it to the second group of users.
Once the Application Groups are set up, you should now be able to launch the applications from Storefront and see them directed to the required server, irrespective of load. So now you know why I chose cmd.exe as the test application, so I could grab the server name easily enough! 🙂 Here we see user jrankin, who is in the non-migrated users group, and every time they launch the published application it is running on the server from the first “worker group” we set up using tags
And naturally when you log in as the jrankin2 user which is in the migrated users group and run the same application, it launches on the other server
So there it is – in XenApp 7.x, you can use tags and application groups to replicate Worker Group functionality, and have specific groups of users launching the same application on specified groups of servers.
XenApp 6.5
There’s still a lot of XenApp 6.5 out there in the wild, so it makes sense to discuss how to do this in the older IMA version of the product suite as well.
It’s a lot simpler on XenApp 6.5 – firstly, it still has the direct “Worker Group” functionality that is somewhat hidden in XenApp 7.x. Create two Worker Groups and assign the servers to them as required.
Our test application (again, cmd.exe) should be published to both Worker Groups
Next, we need to set up Load Balancing Policies (not to be confused with Load Evaluators) to direct the users to the required server. These are accessed from the Load Balancing Policies area of the AppCenter console
Create a load balancing policy and give it an appropriate name
Set the Filters to Users, enable it, and match it to the AD group created earlier
Now apply the Worker Group Preference to the required Worker Group
Click on OK to save it.
Now repeat the process, but this time set the Filter to the other user group, and the Worker Group Preference to the other Worker Group.
These policies will apply to any application that the user launches, which is the main difference between this and the XenApp 7.x implementation.
So, when the user hits Storefront and launches the application, we should see user jrankin from the non-migrated users group launch the application on the first XA 6.5 server (UKSLXA003)
And every time user jrankin2 from the migrated users group launches the application, it will launch on the migrated server (UKSLXA004)
Summary
So, we should now be able to route our users to specific servers from single instances of applications, without having to duplicate those applications and create a mess for ourselves in the future.
You can also use both these methods to do other things, such as route sessions to a specific datacenter in an active-active configuration, and probably a lot of other uses you can think of. I never really dug too deeply into Load Balancing Policies and Tags/Application Groups previously, but they are very useful features that you can use to avoid extra work within your environment.
I should be recording a video on this very soon, I will update this post with a link when completed.
Share
