One of the more common challenges with onboarding applications to Frame, is supporting the various license models that come with the variety of software in the market. Most industry-standard licensing models can be supported by Frame with only a few exceptions. In cases where a particular licensing model is not supported, the software vendor will typically have an alternative license model that can be used. The following summarizes the common licensing approaches.
Apps that require standalone licensing may have trouble keeping their activation/licensing information active when published to production instances.
Standalone licensing sometimes fails in production environments due to the license being hardware-locked to a specific Windows hostname, network MAC address, hard drive unique ID, or some other hardware ID associated with the Windows installation. If you install the license on the Sandbox and then publish to production instances, the unique hardware fingerprint for the production instances will have changed and the licensing mechanism may prevent the sofwater from running. Note that sometimes these licensing mechanisms may allow some time period of use after being copied only to prompt for reactivation later. It’s always best to consult with the software vendor first to understand how their licensing is intended to work.
In some cases, Frame can ensure that production instances have the exact same hostname as the Sandbox that they were originally configured for. This will enable support for standalone licensing that only relies on the hostname. This configuration resides in the Frame Gateway and is part of the Vendor configuration. By default, this value is set to create unique hostnames for all instances as shown below (contact Frame if you require this setting to be changed and don’t have Gateway access for your deployment):
Most applications that have standalone licensing models also have other licensing options including enterprise volume licensing and network licensing.
Enterprise volume licensing¶
One of the most common licensing mechanisms available from software vendors is called enterprise volume licensing or volume activation. This approach makes it much easier for IT departments to distribute software across a large enterprise with many devices. Typically, a single key can be used to activate the software on the Sandbox (a.k.a. the “Gold Master”) and the publishing process maintains the activation. This parallels the process used in physical PC environments where a gold master image is used to push entire hard drive images to PCs connected on the network.
Note that with some software, there is a limit to how many times an image can be created and copied before activation restrictions engage and prevent use of the software. For example, you may be able to install and activate on a Sandbox and then publish from that Sandbox to the production instances on that account. But you may not be able to clone the Sandbox to another account and then publish from that account (this constitutes a copy of a copy being published).
Ultimately, the licensing protections that software vendors use for enterprise licensing can vary significantly. It’s therefore important to consult with the software vendor on what licensing approach is best for a managed environment like Frame.
Often, the best way to license applications for production instances is by configuring a dedicated network licensing server to serve licenses to production instances in real time. When a licensed instance is powered off, the license is then returned to the licensing server to become available to other instances.
This licensing server can exist within the same account (using Frame’s Utility Server feature), AWS VPC, or can be accessible via a VPN tunnel.
The licensing server must have inbound TCP ports open on both the Windows Firewall and via AWS. If the account is within a VPC, the ports do not need to be opened via AWS.
Client-side access to a licensing server on AWS must be configured via IP address, as hostname resolution is disabled on AWS for security reasons.
Typically, if the Sandbox is properly configured and can connect to a licensing server and receive a valid license, one simply needs to publish (cloning the Sandbox image to production instances) in order for the licensing to work on production instances.
This licensing model is common with high-end engineering and graphics intensive applications.
Software vendors have been increasingly turning to cloud-based licensing. This means that the software license is more flexible and is tied to the user rather than to a device. Thus, a user can run the software on any device so long as it has internet connectivity and can reach the software vendor’s cloud-based licensing system. Typically, a user login is required at the start of an application session. This login can be presented to a Frame user right after launching their Frame session. If entering a user’s credentials is not desired, then an SSO integration may be an option when using this licensing approach.
License integration with Frame¶
ISVs can build their licensing models with Frame in mind. Frame offers unique data-handling tools that can be leveraged for licensing.
For example, if an ISV can tie their user authentication to their licensing for their users, this information can be passed from the ISV directly into a Frame session and the application can then access the licensing data as necessary. This, of course, is assuming that the ISV has written their app to expect this licensing data when a Frame session is started.
Similarly, if the ISV has their own authentication mechanism used to validate users, an SSO integration with Frame is another option.
USB dongle licensing¶
While rare, some applications require physical dongles to be attached to the PC running the software. Naturally, this approach does not work with cloud-based virtual machines. In some cases, “soft” versions of the dongles can be used - but this typically requires close interaction with the software vendor.