Cross platform client also works in Virtual Environments

All of K2’s flexible license management options apply equally to software installed on virtual and physical computers – in either context, the usage tracking, license control, reporting, and other functions behave in exactly the same manner. In order for K2 to track usage or manage the launch of any application program, it is simply necessary for the K2 client, KeyAccess, to be installed and running in the same OS environment where the application program itself will run. This rule of thumb applies equally to both physical or virtual computers.

With KeyAccess properly installed on client computers, K2 will enforce the license policy you configure regardless of how the software is deployed or accessed. For example, when managing compliance for an application licensed with a Concurrent Use Limit, K2 will accurately enforce the specified limit across any mix of physical computers, virtual computers, and thin clients.

Virtual Technology examples

1) VMWare Fusion, VMWare Workstation, Parallels Desktop (virtualized computer VM)

  • execution of the VM takes place on the end user’s local computer
  • a “player” application is run on local computer in order to “host” the Virtual Machine (VM)

For both VMWare and Parallels virtual machines, a complete virtual computer is embodied as a “VM” – a package of files that define the virtual computer’s hardware environment along with a disk image file that has the virtual OS plus application software installed. This VM package is deployed onto an end user’s computer where a “player” application (Fusion, Workstation, Parallels) is invoked in order to “host” the VM. In order for K2 to manage software running in a VM, it is simply necessary that KeyAccess be installed as part of the VM’s disk image file.

There are variations on the level of user interface integration that the player may provide on the end user host. For example, the Parallels “Coherence Mode” or the VMWare “Unity Mode” conflates the display of windows coming from both the VM and the host computer so the end user is hardly aware of the distinction between their own host OS and the virtual OS. In all cases, simply including KeyAccess as part of the VM lets K2 track and manage applications run within the VM. Note: in order to track applications run both in the host computer’s native OS environment and in a VM hosted there, the K2 client, KeyAccess, must be installed in both places. K2 will maintain a distinct computer record for each of these two distinct clients, one for the real computer and one for the virtual computer.

2) Citrix XenApp, Remote Desktop Server (thin client technology)

  • execution takes place on a remote server
  • a screen view of remotely running applications is presented on client computers through a “thin client” viewer

The underlying technology for Citrix XenApp or Windows Remote Desktop Server (RDS) is basically a combination of Fast User Switching (for multiple login accounts) along with Screen Sharing (e.g. graphical desktop view sharing via the Remote Desktop service- formerly known as Windows Terminal service, WTS). But unlike Fast User Switching where only one login account is active at a time, the server version of this technology allows multiple distinct user sessions to be active simultaneously with multiple distinct user interfaces served out via a Remote Desktop service.

The computer acting as Remote Desktop Server is actually the executing CPU and it runs the OS environment for all the applications whose interface is being served out – remote client computers are simply viewing an exported screen. It is the Server OS that provides the execution environment for running the applications. As usual, K2 management is supported by installing KeyAccess in the OS environment of the application programs – that is, KeyAccess must be installed on the Remote Desktop Server host.

Variations on the thin client technology include ways to link together multiple hardware devices to act as the server and ways to serve out just the user interface of a single application instead of serving out the complete view of a windows desktop. Usage will be tracked independently for each thin client session. Summary reports and license enforcement will treat these “virtual computers” just like a physical computer. Note: a single copy of KeyAccess installed appropriately on the Server host will connect to K2 and create distinct Computer records for each distinct client session based on the thin client id.

3) VMWare View, Citrix XenDesktop (desktop presentation server)

  • execution of the VM takes place on a server appliance
  • a “viewer” is run on a user’s desktop workstation in order to present the remote VM computer’s interface

Like example 1 (Fusion, Workstation, or Parallels), a complete virtual computer is built and embodied as a VM, but instead of execution on a local computer, here the execution of the VM is performed on the remote server appliance. Remote desktop technology is used to screen-cast the desktop of the virtual machine for presentation on client workstations.

Various management utilities support the creation of customized desktops for presentation to different users, perhaps storing a VM dedicated to each particular user account or creating generic VMs for a particular class of users. VMWare, Citrix, and others provide a dizzying array of products for creating and managing the presentation of a running VM to the end users but from the point of view of license management and usage tracking, the presentation server is hardly different from executing the VM locally (example 1). Following our rule of thumb, it is only necessary to include the K2 client, KeyAccess within each VM. The presentation server will execute multiple VMs simultaneously, and therefore execute multiple copies of KeyAccess, each corresponding to a distinct computer record in K2’s computer table. Again, usage tracking and license policy enforcement will proceed as usual with each presentation view being managed separately by K2.

4) Microsoft App-V, VMWare Thin-App (application virtualization)

  • execution of the virtualized application takes place within a protected environment on the local computer
  • a “launcher” utility is run on the local computer in order to stream the virtualized application container from a server

Application virtualization provides an efficient deployment mechanism and protected execution environment within the local operating system. In many ways, the server process that is provisioning virtualized applications is similar to a file server. However, a simple launch from a file server is often impractical or impossible due to performance issues or an application’s specific OS environment requirements. Application virtualization lets you “bottle up” these environment dependencies along with the application so that a specialized server process can efficiently stream just what is needed to a client computer, while insulating the client OS from any contamination of its local file system. Unlike the Virtual Machine solutions (examples 1 and 3), Application Virtualization does not include virtualized hardware nor a virtualized OS. Unlike screen casting technologies (examples 2 and 3), programs are executed locally, not on a remote server.

In the end, the Operating System environment for running a virtualized application is basically the client computer’s hardware and OS so KeyAccess installed and running on the client computer will track and manage the virtualized application in essentially the same way it interacts with locally installed applications. Note:when creating the virtualized application container (e.g. the App-V OSD), there is a simple configuration step that must be taken in order to enable communication from within the virtualized application container out to KeyAccess running in the host OS.

License compliance in Virtual Environments

The technical issue of where to install KeyAccess in order to track usage and manage license compliance for virtual environments is addressed above. But the practical meaning of license compliance can be drastically altered when the deployment efficiency of virtual technologies is added to the mix. The ability to instantaneously create and destroy entire computers along with their file systems and installed applications makes any license compliance metric based on counting installs ‘virtually’ meaningless. For this reason some vendors have amended their standard node locked licensing language to make it clear that an alternate license is required to support virtual deployments. Fortunately, license compliance metrics based on a maximum concurrent use limit are unaffected by the introduction of virtual technologies – as long as K2 or some other active license management technology is in place and properly configured to reliably enforce the concurrent limit, the distinction between software in use on a physical versus a virtual computer is immaterial.

As virtual technologies become an ever more dominant part of the computing landscape, software vendors will continue to fine tune their pricing and licensing models to match the realities of the marketplace. In addition to concurrent use metrics, we can anticipate wider adoption of licensing based on authenticated user accounts, subscriptions, and negotiated site agreements that acknowledge the inadequacy of simply counting installations. Negotiations will be facilitated by management tools such as K2 that can report on and enforce these alternative license policies. Along with these familiar licensing options, new avenues for negotiation are opened up by K2’s implementation of the “Leased License” model which combines the strengths of installation based (node locked) and usage based (concurrent use) metrics.