Happy New Year all, it’s good to be back at work and have so many things lined up to blog about in 2018! Where shall we start? Well, let’s take a dive into the minefield that is per-device software licensing on XenApp or RDSH.
Per-device licensing model – the background
For a long time, XenApp or RDSH administrators have struggled against the problems brought by per-device licensing agreements. When an application is installed on a XenApp server or RDSH server, technically that application can be run by thousands of client devices. If the application uses per-device licensing, the idea is that a license needs to be purchased for every device that can access and run the application. If you then install this application onto a XenApp or RDSH server to allow users to access it in this way, then you may find you need to buy a huge number of licenses, far in excess of the number of users you have that actually want to use the application. Many pieces of software behave like this, but perhaps the two best-known ones are Microsoft Project and Microsoft Visio.
Controlling access to the published application through things like Active Directory groups isn’t enough to satisfy the licensing requirements. This is understandable, because technically a user could use a separate published application to browse through the server filesystem and launch the application that they’re not supposed to have access to. Locking down the filesystem on a per-application basis is messy, time-consuming, and ultimately doesn’t satisfy the per-device licensing model.
Introducing the per-device licensing model into RDSH environments can cost a huge amount of money, as you can probably imagine. Take, for example, a company with Microsoft Visio installed on a XenApp 7.15 infrastructure and 1800 users with thin client machines. This application is only used by 70 users but as the servers with the app installed can be accessed from any thin client machine, the company must purchase 1800 licenses for Visio – 1730 more than will actually be using the application, making a mockery of the cost-savings associated with their XenApp and thin client infrastructure.
Microsoft did modify this approach slightly with the addition of “Roaming Use Rights” for Software Assurance customers, but the fact remains that the per-device licensing model is murky and potentially costly (especially in an audit situation). If you lock down your RDSH environment heavily with Group Policies and technologies like AppLocker, you can try to prove to an auditor that you have taken the required steps to restrict access to a specific subset of devices, but the problem remains that if they find any way in which a user could circumvent this, you will be on the hook for the extra licenses required, as well as an audit fine.
It’s not just Microsoft who take this approach – some of the bigger database vendors are known to do it too, and there are myriad other pieces of software out there that adopt the same model. it’s much better to be safe than sorry, arguably!
Now, for a long time people used tech like AppSense Application Manager (now known as Ivanti Application Control) to mitigate this issue. I even wrote a blog post about it, what seems like a lifetime ago 
(in fact that was published on my very first day of blogging!) Ivanti had a sort of quasi-official response from Microsoft that allowed them to run with this as a feature, but Microsoft have now distanced themselves somewhat from any specific third-party endorsement for per-device licensing compliance.
This doesn’t mean that tech like Ivanti Application Control is now invalid – just that Microsoft (and probably other vendors too) are now going to judge each case on its individual merits. Or to put it another way – if there’s any way you haven’t covered your backside with the solution you choose to deploy, they’re going to bill you for it. However, Microsoft have issued a set of guidelines that will drive the approach to auditing per-device licensed software in XenApp/RDSH situations.
- The software must be proven to be restricted to a specific set of client devices, without any possible way to circumvent the restrictions.
- The licenses must be transferable between devices.
- Reporting must be available on the current and historical license usage
So with these requirements in mind, you need to put together a solution that ticks all of these boxes to allow you to avoid big bills from non-compliance with per-device licensing.
The Ivanti Application Control method is still probably perfectly valid (as far as I know it should be able to satisfy the requirements, although you will need to validate this). However, if you’re not an existing Ivanti customer getting this tech in just to handle licensing is probably a bit of overkill from a functionality and cost perspective, to be fair, although there are some other really cool features of Application Control you may also find useful. For purposes of this blog, though, I’m going to look at handling the licensing through FSLogix Application Masking, because FSLogix is quick and easy to set up and get running, and simplicity is one of my target areas for 2018
Managing licenses with FSLogix
The Application Masking feature is ideal for this because it actually physically hides the filesystem and Registry entries from devices that aren’t allowed to run the application. If the user can’t actually see the executables, they are going to have a job running them! This makes FSLogix perfect to satisfy the first of the requirements above.
Firstly, you will need to install the FSLogix Apps software onto your XenApp/RDSH server (if you want to use the trial version like me, just download the latest version from the FSLogix website and crack on)
Then you will need to install the FSLogix Apps Rule Editor onto a management server or client. This console allows you to configure and deploy the rules and rule assignments that will get the licensing restrictions to work. Of course (pro tip), if you install the Rules Editor onto a server that runs from the same image as your production XenApp/RDSH servers, it will be much easier to set up the masking rules (because the applications are already present), so that’s what I’m going to do
Next, let’s install a per-device piece of software onto our XenApp server. In this instance, we will use Microsoft Visio 2016. If you’re like me and scatter-brained, make sure you get the version that runs on Remote Desktop Services!
We will now publish the application so it is available to our XenApp users
Next, let’s run the FSLogix Apps Rule Editor and create a Masking Rule for Visio 2016. If we’ve installed the Rules Editor onto spare XenApp system with the applications already pre-loaded or deployed, we can use the Add/Remove Programs method to read out the relevant Registry values and filesystem entries and save ourselves some work. Create a new rule, give it a name, and then choose Visio (in this case) from the “Choose from installed programs” list
The application will be scanned and the rule populated with the required filesystem entries and Registry values
We can use the function in the Rules Editor under File | Change Licensing Parameters to set a minimum time that a license will be assigned
Setting the minimum time allows us to fulfil the requirement for allocation and transferral that is stipulated. If a license is moved or deleted (by removing or changing the assignments) before the minimum allocation time, a warning will be shown to remind the administrator that they may be violating the licensing requirements.
The actual assignment of the licenses to devices is done by using the Manage Assignments function for the Masking Rule. Click on File | Manage Assignments to start this. Firstly, we will Remove the Everyone rule. Then click on Add.
Add an Assignment for Environment Variable. We are going to use the variable CLIENTNAME (this will be a variable within the user’s XenApp or RDSH session, that corresponds to the name of the connecting client). In this example, we are going to allow the client machine UKSLD205 to run the Visio software via Citrix and block it for all other connecting devices.
Firstly, you need to remember that FSLogix rules are evaluated fully from the top down. So this doesn’t mean it reads the first matching rule and then stops processing – it reads them all and evaluates the outcome. So to allow the application to be run by specific devices, first we need to add a wildcard rule.
Add an Assignment for Environment Variable CLIENTNAME, set the value to * (wildcard), and select Ruleset does apply
Next add an Assignment for Environment Variable CLIENTNAME, set the value to (in this case) UKSLD205, and select Ruleset does not apply
So the rule will look at both Assignments and decide to apply the ruleset to all machines except UKSLD205, in this instance.
To deploy the rules, you simply copy the .fxr and .fxa files into the C:\Program Files\FSLogix\Apps\Rules folder on any target servers. The service then picks up and processes the changed files. In this example I simply did it manually, but in production environments I normally use a script to push changed files to XenApp or RDSH farms.
Now, if we log onto Storefront and launch the published version of Visio from UKSLD205 (the machine that we specified to be allowed), we should see it launches successfully.
However, if we run the published resource from anywhere else, we get this error
Realistically, it could probably do with a custom error in this case, one that tells the user that they are restricted from running the application because of licensing rules. I will feed this back to FSLogix as a feature request.
What you could do (and that I know guys at FSLogix do) is redirect the file type associations to Visio Reader, so if a user isn’t allowed to run Visio, instead of getting this error message they actually get allowed to open Visio files in the installed Reader version. I may well do a follow-up to this article covering how to do this, once my backlog is cleared
The rules cannot be subverted, even in a situation where the user actively changed their environment variable for CLIENTNAME whilst logged in, because the FSLogix rules are read in at logon time and the application masked or unmasked as required at that point. A change to the variable during the session does not affect how they are processed.
To satisfy the last requirement, you can run reports on the current or historical usage of FSLogix App Masking for by using the function File | Licensing Report
Finally, there is a function within the software to easily import large numbers of machines to allow as Assignments. When adding an Assignment for Environment Variable, the From file function allows you to select a text file (one entry per line) that you can use to add rules for a number of machines at once. This functionality is a bit rudimentary (it would be nice to be able to add machines from particular OUs, Sites or IP address ranges, for instance) but certainly reduces the effort required to add a number of endpoints to the configuration.
Summary
So, if you want to exercise control over your per-device licensed software (be it Visio, Project, or one of the many others out there that adopt this model) in a XenApp or RDSH or VDI environment, FSLogix Application Masking offers you a quick, easy and audit-compliant way of achieving this (although as I said, there is no absolute certainty on that final point for anyone, you really need to construct the solution and verify it with the software vendor). However, based on my own experiences, I’m pretty sure that as long as you can demonstrate how the solution you’ve chosen meets the requirements specified, then there should be no reason why a vendor shouldn’t allow you to use it for these purposes.
With regards to addressing this through FSLogix, there are a couple of rough edges to this, namely the error that appears when the application is restricted and the flexibility around adding large numbers of allowed devices, but these should be easy enough to iron out. The core functionality is solid and does exactly what we need it to – I’d recommend it as an excellent way to deal with per-device licensing for any environment that experiences these issues.
I will be recording a video on this subject later on today – link will be posted here as soon as it is done!
The post Managing device-based licensing on XenApp and RDSH using FSLogix Apps appeared first on HTG | Howell Technology Group.