To answer a common question:
The Sassafras Client runs equally well on virtual and physical computers and will track “thin” connections.
And yes, you can run the Server on a virtual server of any type. If you want to know more, keep reading 😉
In any context, the usage tracking, license control, reporting, and other functions behave in exactly the same manner. In order for Sassafras to track usage or manage the launch of any software, it is simply necessary for the client (KeyAccess) to be installed and running in the same OS where the application itself will execute. This rule of thumb applies to any manner of virtual, VDI, streaming app, thin client, etc technology (i.e. non-physical hardware) and any combination thereof. Even hardware inventory is collected in a virtual environment, though its usefulness is limited of course.
The infrastructure that your virtualization runs on can be on prem or cloud hosted. It doesn’t matter if the “host” is Microsoft Hyper-V, VMware VSphere, AWS, or any other container system. As long as there is a supported OS under the hood, our client will run in it. Your only concern with the location of the servers on either end is network connectivity (i.e. Firewall rules).
Virtual Technology examples
This is not an exhaustive or even current list of technologies. We make mention of a few popular options of various types that span the last decade for reference.
1) Stand-alone Virtual Computer (VMWare Fusion, Parallels Desktop, VirtualBox)
- Execution of the VM takes place on the end user’s local computer
- a “player” application is run on the local computer in order to “host” the Virtual Machine (VM)
For configuration, a complete system is installed 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, Parallels, VirtualBox) is invoked in order to run the VM in a window as if it were an application. In order for Sassafras 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. Despite this clever appearance that an application is running on the host OS and not the guest OS, KeyAccess must be on the guest to see those applications executing.
Note: in order to track applications run both in the host computer’s native OS environment and in a VM hosted there, the Sassafras client, KeyAccess, must be installed in both places. Sassafras will maintain a distinct computer record for each of these two distinct clients, one for the real computer and one for the virtual computer. The host (physical) record will have a blue icon, the guest (virtual) record will have an orange icon.
2) “Thin Client” Technology (Citrix XenApp, Microsoft Remote Desktop Server, some WVD configurations)
- Execution of a desktop session takes place on a remote server
- A screen view of the remote desktop environment is presented on client computers through a viewer or remote desktop application
- Multiple users are connected to a single OS
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 Services). 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, Sassafras 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 (see Application Virtualization below). 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 RDS host will connect to the Sassafras server and create distinct Computer records for each distinct client session based on the thin client id. These computer records will have a green icon. In the event of an admin logging in to the root OS rather than through the “thin client” technology (e.g. a “console” connection), an orange or blue computer record is created for the host server depending if it itself is physical or virtual. It is also worth noting these green thin client records will not perform audits by default, and will move to a dormant state within hours instead of the normal days or weeks.
3) Remote Virtual Desktops (VMWare Horizon, Citrix XenDesktop, Apporto, some WVD configurations)
- Execution of the VM takes place on a server appliance that hosts dedicated or pooled VMs (in house, Azure, AWS, other hosting locations)
- A “viewer” is run on a user’s desktop workstation in order to present the remote VM computer’s interface
- Each connected user has a dedicated virtual machine
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 stream 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 KeyAccess Client 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 Sassafras’s computer table. Again, usage tracking and license policy enforcement will proceed as usual with each presentation view being managed separately by Sassafras.
Note: these computer records will be orange to show they are virtual. It is important in managing this environment to ensure KeyAccess is properly installed on any template virtual disk that is cloned for a pool of virtual machines. If improperly deployed, each clone will share the ID of the parent and distinct records will not occur in the Sassafras Server. This will lead to confusing report results and possibly improper license enforcement.
4) Application Virtualization (Microsoft App-V, VMWare Thin-App, AppStream, AppsAnywhere, Citrix Virtual Apps)
- Execution of the virtualized application may take place on the streaming server or on the local computer depending on the technology
- Only an application is virtualized, not an entire desktop OS
- A “launcher” utility or “stub” 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. Unlike the Virtual Machine solutions (examples 1 and 3), Application Virtualization does not include virtualized hardware nor a virtualized OS. Depending on the technology, the application may execute on the server and only the window display is streamed to the client, or the app bits are streamed to the client and executed locally.
In either case, the application is not installed on the local machine and can not be run without access to the server. However, where you install KeyAccess depends on the exact technology. If the apps are executed on the server and streamed to the client, then you install KeyAccess on the server. The association of the execution to a user is handled through a registry pointer that pulls the connection information. In the event of app code being streamed to the client and executed locally via a stub application, then KeyAccess needs to be installed on the client not the server. A special Product may be needed to track the stub executable if it’s not using the same root identifiers of the streamed app.
License compliance in Virtual Environments
So now we’ve covered where to install KeyAccess in order to track usage and manage license usage for virtual environments. But what about the impact these technologies might have on software license terms and conditions, and the use of the Sassafras Server itself? For the first question, we can only advise you be aware of specific terms of use. While most companies don’t care if software runs on bare metal or virtual, you might find some do. Alternately, some terms might limit use due to the remote nature of most of these technologies. The second question is perhaps more interesting as LabSight and AllSight are licensed based on active computer records. Keep in mind, you may need to track both client computers and virtual computers as many site use hybrid deployments where software is executing on both sides.
License Metrics
The main take away here is that enforcing the metics you configure in a Policy in Sassafras doesn’t care what kind of system the application is running on. However, node based policies are likely less meaningful in most virtual settings. The issue there of course is even if you never went over your allocation at a given moment, it would be hard to show that in some cases. If you have a transient virtual pool, your reporting could reflect a great number more computers used the license than the terms allow. Concurrent and Site are going to be the most common, and User based are also easily used. Policy Scope based on Divisions and Groups may again be a slight challenge with a transient pool, but there are methods to work with this.
Disposable Computers
It is worth noting that the virtualization technology in play as well as the needs of the customer tracking will dictate the license needs for Sassafras itself. In a pure VM environment one may think a license is needed for every “orange” record just as with “blue” (physical computer) records. This may be the case, however it may not. Some pooled VM systems create and destroy the VM with the user session using transient (not recycled) computer names and MAC addresses. In such a case, there is a worry of needing seemingly infinite Sassafras license seats. Proper use of Rules for setting the login type of these machines however can help greatly, though a configuration that recycles virtual computer names is often best. Likewise with green “thin client” records there will be a decision about best identifier to keep record counts low (as well as meaningful), and use of Leased login state to allow for seats to be quickly released for other use.
As always, Sassafras support is happy to assist in these planning and implementation questions.
Subscribe
