Software Asset Management has traditionally focused on managing the physical license installations on the desktops, laptops and servers of an enterprise. By this time, most companies have at least the outline of a SAM program defined and are executing against that plan to ensure that their license entitlements do not fall short of the overall installations and/or utilisation of that software. There is some level of discovery occurring, whether that is SCCM, Universal Discovery or another third-party vendor tool. Along with discovery, there is the means to provide reports and dashboards.

Taking one more step, the ability to track utilisation of software and implement a license re-harvesting process rounds out the tools needed to manage the software asset environment.

So, if you have, or are planning to implement the tasks above, you should be feeling pretty good about your overall SAM program. Then, as a result of an audit or the implementation of a virtual desktop environment, the light bulb goes off that you really don’t have a good handle on the software licenses being used, or not, in your desktop virtualisation and server spaces.

The desktop virtualisation environment is a great way to provide remote access for internal and external resources within your company. The creation of the desktop virtualisation icons for both internally developed applications and commercial software is all based upon the Active Directory (AD) groups that are assigned to them. Sounds straight forward, right? Create an icon that launches a software program and assign an AD group to the icon. What you, as a Software Asset Manager, may not be familiar with are the licensing terms applicable to the software being published in desktop virtualisation environments and what the AD groups actually look like.

You need to identify every licensed? software title that is being launched through desktop virtualisation, know what the virtual use rights are and create a process for provisioning that includes an approval by the SAM team that validates whether a license is needed and, if so, if there is one available.

That takes care of the current requests, but what about the legacy users who have been accessing applications in your desktop virtualisation environment for many years? This requires collaboration between your Desktop Virtualisation, Active Directory and SAM teams to review how your AD groups are defined. Standards need to be created so that the name of every AD group that launches licensable software reflects the software name. This segregates the desktop virtualisation icons and streamlines utilisation reporting. Once the desktop virtualisation icons are named appropriately, a deep dive into how your enterprise AD groups are created is required. If your organisation creates a minimal number of AD groups to more easily manage the environment, chances are there will be many more users assigned to desktop virtualisation icons that COULD launch licensable software than is required. The next item to check is to see if you have nested AD groups. This would be an AD group within an AD group; this greatly expands the number of users who COULD launch licensable software. The key to minimising the number of entitlements required for desktop virtualisation is to create separate AD groups specifically for the desktop virtualisation icons that are launching licensable software.

I have capitalised “COULD” in the previous sentences because this is the premise on which many software companies base their audits in the desktop virtualisation environment. If a user is in an AD group linked to a desktop virtualisation icon with licensable software, an entitlement for that user may be needed. This is where knowing the virtual use rights for your software becomes very important. There are two scenarios for this, the basic premise is that a user owns an entitlement for licensable software that is installed on their desktop but they also have a need to access via desktop virtualisation. The first scenario is that the entitlement owned for the desktop license covers the user’s access via a virtual environment. The second scenario is that the desktop entitlement does not cover access via a virtual environment and a separate license is required. It is the responsibility of the SAM team to know their virtual environment, their product use rights and to have a process in place to approve and manage the licenses consumed.

For the Virtual Desktop Infrastructure (VDI) environment, you should ensure that you have the underlying infrastructure licenses that are required for access. With some vendor products, licenses are linked to the operating system license. With others, you might need to purchase device-based virtual desktop access licenses. The same application software requirements hold true for the VDI environment, every software vendor will have separate licensing guidelines.

Virtualisation in the server environment is even more complex than for desktop virtualisation. The bottom line is to know the version of the OS you are purchasing and the product use rights associated with it. In some instances , you can have an unlimited number of virtual machines running on one host. In others, you may have limits on the total number of virtual machines you can run. There are also guidelines for when you can move a license from one machine to another, e.g., a 90 day waiting period may be required, which might also be waived in certain circumstances. Other licensing models include licensing based upon the number of cores on a machine.

There are many other product use rights associated with server software, including CALs, external connectors, core licensing, processor licensing and management devices. The best defence is an educated Software Asset Management team who knows the product use rights for the licenses being used in their environment.