Skip to content

Controlling device-based licensing in Citrix

Publishing an application to a restricted user group in Citrix does nothing for a per-device licence. The control has to be enforced where the licence is measured — at the device — and you have to be able to prove it was.

Virtualised delivery was supposed to simplify things. For licensing, it frequently does the opposite. VDI, Citrix and Terminal Services change the metric under which software is counted, and they widen access to that software enormously at the same time. Those two effects compound, and the result is a licence position that is far larger and far more expensive than the number of people doing the work would suggest.

The clearest example is publishing an application inside Citrix.

Why locking down at user level does not work

The instinct is to control access with a user-level mechanism — publish the application to a named group, restrict it by group policy, and consider the matter handled. It is a reasonable instinct and it is the wrong control.

Publishers including Microsoft license certain products per device rather than per user. Under a per-device metric, every device with the ability to access the software requires a licence, regardless of how many people use it or how often. A user-level restriction does not remove a device’s ability to access a published application; it only governs who may sign in. The obligation attaches to the device population, and the device population in a Citrix farm is the whole farm.

Work it through. A farm delivers published applications to a thousand devices. One user needs the application. Because that user can launch it from any of those devices, all of them fall inside the licensable population. You are buying a thousand licences to serve one person.

That is not a grey area or a negotiating position. It is a straightforward calculation, and it is one an auditor can run quickly.

What the control actually has to do

Buying a licence for every device is compliant and expensive in direct proportion to the size of the farm. Installing the software locally to bypass the thin client layer solves the licensing problem by creating a patching problem and a governance exception nobody will remember to review.

The third option is to enforce the restriction at the level the licence is measured at: the device. That means two things, and the second one is the one organisations tend to miss.

Prevent execution on unlicensed devices. Not discourage it, not publish it selectively — genuinely stop the application from running anywhere outside the licensed population.

Be able to demonstrate that the control was in force. Contrary to a persistent myth, publishers do not maintain lists of approved tools for this. What matters is whether you can produce evidence, covering the period in question, that unlicensed devices could not and did not run the software. A control you cannot evidence is worth very little in an audit conversation.

How CerteroX SAM handles it

CerteroX SAM provides Access Control rules covering RDS, Citrix and VDI streamed-application licensing. You define which devices are permitted to run a given application; execution attempts from anywhere else are blocked.

The evidence comes from the Blocked Files log, which records what was blocked with per-user and per-device block counts. That log is the artefact you hand over when a publisher asks how you know the restriction held. It converts an assertion about your configuration into a record of enforcement.

Two further capabilities do useful work alongside it.

Terminal Server and RDS remote usage is tracked per device, so you can see the real access pattern before you decide anything. This is usually the fastest route to discovering how small the genuinely licensable population is — and occasionally it reveals that the population you have been paying for bears no relationship to the one that exists.

The Exclude From Licensing workflow removes legitimate exceptions from the count: MSDN, development, training and second-use devices. If those are inflating the number you are defending, you will spend the exercise arguing about figures that were never real.

The trade-off, stated plainly

Per-device licensing penalises exactly the property that virtual desktops exist to provide. The whole point of a published application is that anyone can reach it from anywhere, and that is precisely what the metric charges for.

You do not have to give up the architecture. You do have to enforce the restriction where the licence is measured, and keep the log that proves you did.

To see Access Control and the Blocked Files log on a populated Citrix and RDS deployment, book a demo.

Related reading

Other posts covering the same ground.

  • Device-based licensing and access control

    Locking an application down at user level does not make you compliant with a per-device licence. In a Citrix or RDS environment, one user with access can cost you a licence for every device in the organisation.

    • ITAM
    • SAM
    • Governance
    4 min
  • Gartner Myth Buster – Part 1

    A third-party summary of a vendor can be wrong, and it stays wrong for as long as people read it. The case for checking a vendor's facts at source — and the current, sourced record for Certero.

    • ITAM
    • SAM
    • Governance
    7 min
  • The role of good data in software audits

    An audit is won or lost on the quality of your inventory long before the letter arrives. Six ways data goes wrong, and what it takes to have the answer already in hand.

    • ITAM
    • SAM
    • Governance
    8 min
From reading to evidence

Put the hardest claim here
to a technical person.

Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.

No gated download at the end of it.