How can VDI reduce your application license cost?

If you are an IT decision maker in your organization, you would have the unenviable and unrelenting task of driving down IT costs. We understand reducing spending and optimizing requirements are in your KRA. And nowhere is the pain for adding financial resources felt more than in the case of application licenses for users.

We were also suffering the same pain. So, we did some research, ran the numbers and came up with a certain methodology to optimize within our organization. And the results were so great and seriously surprising, that we felt like we had to share our insights with others. While the end results for you may or may not be as great as ours, it is almost 100% guaranteed that there will be quite a few dollars and rupees saved from your budget.

Let us go through an exercise of evaluating licenses to optimize the per user count and in turn reduce the overall license cost.

The initial premise

Being a virtualization vendor ourselves, it is but natural that we incorporate virtual desktops (VDI) in our work environment. But for long, we just assumed that having a dynamic centralized platform like VDI would automatically help drive efficiency. Turns out that for the assumption to be true, it had to be preceded with a more thorough understanding of our internal requirements for any real benefits.

And, we found out that the 1st powerful way to optimize application licenses was actually to know our own work environment. Easy thing to say, but it’s an exercise that is rooted in diligence. There are 3 key elements to discover:

  • Concurrency in individual application usage
  • Map of users vs departments vs applications
  • Availability of shared session application licenses

The Discovery Methodology

As mentioned above, our success was directly proportional to the results of our discovery. We’ll try and narrate what we did to have an accurate estimate of each of these elements. And we’d love to hear your suggestions of improvement or how you would have conducted this exercise in the comments below. After all, in this social media age of sharing, it is important that we build upon each other’s area of expertise.

Concurrency in individual application usage

I’m sure all of us, as IT admins in our organization, have had business teams coming to us with a list of softwares/applications that their team members need. This list is very often long and almost always each team member seems to need every application available. Same was the case with us.

There was one obvious thought that struck us (quite often we later find that the most obvious place wasn’t the one that we started looking for solutions). And that obvious thought was that “surely not everyone is using all their applications at the same time”. Turns out that this was quite true.

We started by looking at the top 5 applications that were there in our organization. We selected 3 time slots in the day (11AM, 2:30 P.M. & 4:30 P.M.) when we knew there would be the maximum number of folks at their stations. And we did a quick survey on open and used applications – the table across captures the findings.

Percentage of users having all 5 applications open 0%
Percentage of users having 4 applications open 0%
Percentage of users having 3 applications open 25%
Percentage of users having 2 applications open 60%
Percentage of users having 1 application open 15%

And in fact, not all that were open were actually being used. We surveyed this further over a stretch of 10 days and came up with exact highest number of concurrent users for each application. Which led to us to our next wishful thought – of designing a pooled system where applications could be provided on-demand to the users, rather than assigning an idle license for every user.

Map of users vs departments vs applications

Now this research on concurrent numbers was good. But as we all know, getting collaboration across teams isn’t something that can be accomplished easily. In our example, it’s all good knowing that there are 100 concurrent Powerpoint users, but a marketing team member in queue is not going to wait for a sales guy to finish his work for him to start his.

So, it’s important that we have a clear map and distribution of these applications and concurrency across departments. In our case, we were able to effectively distribute the results of our survey across individual functions. That way, we could assign quota of licenses to each department in a way that they would not run short.

Availability of shared session application licenses

In today’s complicated world of software licensing, we can all remember the times when we have “misinterpreted” how a software/application has to be licensed. With each application vendor having a different licensing model with its own inbuilt subtleties, it is a mammoth task being compliant.

What is of special interest to us in this exercise is how an application is licensed in a virtual desktop world. But before we get specifically into that in the next section, we can begin with understanding shared session licensing. The two key questions to ask our application vendor are:

Is the application licensed per installed machine or per user?

Can the application be accessed by multiple users from the same machine via shared sessions? If yes, will we need separate user CALs for this?

We’ll understand how to make use of this information when we get to our implementation in the next section.

The Implementation Model

The 2nd powerful way to reduce your application licenses is to enter into the dynamic world of virtual desktops or VDI. With a data driven approach, one can easily utilize the benefits of VDI even in this regard.

A true VDI OEM would generally give you 3 ways to orchestrate your virtual desktops – persistent, pooled & shared. They can be called different names from the individual OEMs, but in essence, this is what each of them mean:

Persistent – A persistent virtual desktop is once where a virtual machine is created and reserved for a particular user. This user can log in to his machine whenever he or she wants and the machine will always be available for them.

Pooled – Like persistent, even in a pooled virtual desktop, only one user can log in to the machine at any time. However, this pooled machine is not reserved for one individual user. Rather a collection of machines is put in a single pool and multiple users are made a part of that pool.

Suppose there are 3 machines in Pool A and there are 10 users allocated to Pool A. At any time, 3 of these users can have access and if a fourth user comes, he/she has to wait till a machine is vacated. This setup is particularly useful when people do not have a constant need for their machine, they work in shifts etc.

Shared – A shared virtual desktop is shared between multiple users at the same time. Multiple users can log in to the same machine, however these are non-persistent sessions. That means that unlike persistent and pooled users, if a shared user logs out of the system, his session is ended. He has to start a new session and open his applications and files again.

Similar to pooled, even in this case a shared group of machines is created and users are assigned to this shared group. An overloading factor can be configured which determines how many maximum shared sessions can connect to a single machine.

Now that we have understood how each type of VDI works, we can get into designing an optimized model of delivery in line with our requirements. Both pooled and shared can come in really handy in our objective of reducing application licenses. We’ll bifurcate each of the use cases into different scenarios.


Application allows for licensing per installed machine, but does not allow shared sessions

VDI type: Pooled

By now, we would have our map of maximum concurrent users in each department ready. Next, we should create as many number of pools as departments. Within each pool create and allocate as many number of VDIs as number of maximum concurrent users. You can add a small buffer if you want to this number.

This should be followed by defining the users of each department as pooled users. These pooled users should then be added to their respective department pools.

Now, this should lead to a really optimized environment. Only licenses equivalent to the number of concurrent applications running needs to be procured.


Application allows for licensing per installed machine and also allows for shared sessions without user CALs

VDI type: Shared

Similar to Scenario A, we will begin by creating as many shared groups as the number of departments. However, in this case, the number of VDIs in each group will be less than the maximum concurrent users because each VDI can be accessed by a number of users equal to the overloading factor. So, each group should have VDIs equal to the maximum concurrent users in that group divided by the overloading factor.

The users in this case will be defined as shared users and assigned to the respective shared groups of their department.

The number of application licenses required in this scenario is even more optimized. Where this is more economical than the pooled VDI is that the number of VDI virtual machines created will be less and the application licenses will be reduced to that number. This should also reduce the total cluster resources needed to run the VDI setup.


Application requires licensing per concurrent user and needs a user CAL

VDI type: Shared

The implementation model in this scenario is exactly similar to scenario B. The only difference in this case is that instead of assigning a license to the VDI virtual machine, the application will be able to track how many concurrent sessions are open for the application. So, each application in a shared VDI has to be provided with server CALs equal to the overloading factor.

The application licenses in this case would be equal to the number of concurrent users. And like Scenario B, the cluster resources required will also be less.

Well, that’s it! That’s how we can optimize the application license count. Thanks for reading through this long post. But we had to get into the nitty gritty of application licenses. After all many of us have fallen on the wrong side of an audit, so it’s time that we are well equipped to drive through our own objectives.

Leave a Reply

Your email address will not be published. Required fields are marked *