Configuring license sources for FlexLM, FLEXnet, Flexera, FLEXenabled, Flex apps

Applications that are "protected" with FlexLM/FLEXnet/Flexera licensing servers need network connectivity to the license server. But how does the application know where to look?

The FlexLM order of precedence

Applications look in several sources for the location of a license server. If more than one license server source exists, the following order of precedence is used:

1. The vendor-specific FLEXnet environment variable
2. The vendor-specific registry entry or configuration file
3. The "global" LM_LICENSE_FILE environment variable
4. Any .lic file in the license path

This means that if you've configured the global LM_LICENSE_FILE environment variable, the Flex runtime will ignore any .lic in the license path. When you are troubleshooting license check-out, make sure you're not unintentionally overriding your lower precedence license preferences.

Bonus points.

Lower precedence license preferences: say that 5 times fast for 10 internet points.

The "global" LM_LICENSE_FILE environment variables

The LM_LICENSE_FILE environment variable configures the license server information for all products that use the FLEXnet framework. The LM_LICENSE_FILE variable should be used sparingly because there may be more than one FLEXenabled app on the computer, and you don't want to accidentally override this.

The vendor-specific registry entry or configuration file

Most FLEXnet vendors have a vendor variable that can be used: for example, ESRI ArcGIS uses ARCGIS_LICENSE_FILE.

Configuring environment variables on Windows manually

To configure the LM_LICENSE_FILE environment variable manually, perform the following tasks.

1. Go to Control Panel > System.
2. In the System Properties window, go to the Advanced tab and click the Environment Variables button.
3. Under the User variables and System variables, ensure there is no variable you are trying to create does not already exist. If it does, delete it.
4. In the System variable section, click New.

5. Enter the relevant variable name and value.

6. Clients do not need to be restarted for changes to take effect. These setting become effective when the System Properties dialog box is closed. Yes, I've tested this.

Configuring environment variables on Windows via Group Policy

Environment variables can be configured via the registry. The registry entry is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. 
Registry keys or scripts that change system variables can be deployed via Group Policy (via custom ADM templates) or a package deployment system such as Microsoft SCCM/SMS or Altiris. 

Configuring system variables in Unix/Linux/MacOS

License variable can be set in Linux or MacOS by using the setenv or export command depending on the shell. You can either type the command in a shell session (which will make it only last for the session) or add it to the appropriate file in your home directory. Examples include:

C:

setenv LM_LICENSE_FILE=27000@licenseServer1

bash:

export LM_LICENSE_FILE=27000@licenseServer1

What should the environment variable be if a FlexLM triad is being used?

Specify the 3 servers separated by commas.

27000@licenseServer1,27000@licenseServer2,27000@licenseServer3

Should I use an FQDN in the environment variable?

Some versions of the FlexLM runtime don't understand FQDNs and just error out. MATLAB is one of them. This needs to be tested on an app-by-app basis.

Decommissioning a VMware ESX host with a Nexus 1000V VEM – why and how?

A decommission process for ESX hosts is essential for environments of any size. Without a decommission process, you risk leaving behind all sort of garbage: DNS records, CMDB entries, allocated IP addresses, etc. If you use Cisco Nexus 1000V virtual distributed switches (vDS) in your environment, you’ll need to have a few extra tasks in your host decommission process.

I don’t have a decommission process for my physical switch ports, why should I need one for my virtual switches?

The Cisco Nexus 1000V has several limits including maximum VEMs registered and maximum vEthernet interfaces. If you don’t properly decommission your hosts, you will be prevented from installing the Nexus 1000V VEM on additional hosts!

A Cisco Nexus 1000V. If you zoom in close enough,
you can see all 8192 ports.

Surely if I remove/disconnect a host from vCenter, the ESX host’s VEM is unregistered from the VSM and the vDS ports are automatically freed up?

Nope! You will need to perform these three tasks manually

1. Unlink the vDS uplink ports
2. Remove your ESX host from the vDS
3. Uninstall the VEM

Unlinking the vDS uplink ports

During the server decommission, you’ll need to remove the Nexus VEM from the ESX host. This should be performed after the host has been placed in maintenance mode but before it has been turned off. The first step is to disconnect the ESX host’s virtual uplink ports to the vDS.

1. In the Networking screen (Home > Inventory > Networking), right-click on the vDS and click Manage Hosts
   
   
   
2. In the Select hosts screen, select the ESX host you want to unregister then click Next.
   
   
   
3. In the Select physical adapters screen, unselect the physical adapters (vmnics) attached to your Nexus 1000V. In this case, vmnic2 and vmnic3 are used by the switch N1K.
   
   Once you have unselected the physical adapters click Next.
   
   
   
4. In the Network connectivity screen, click Next.
   
   
   
5. In the Virtual machine networking screen, click Next.
   
   
   
   
6. In the Ready to complete screen, click Finish to unlink the vDS uplink ports.
   
   
   
7. If you receive a warning message, click Yes to continue. Don’t worry, you’ve already placed the host in maintenance mode so there’s no risk of VMs losing network connectivity.
   
   

Now we have to remove the host from the vDS.

1. In the Networking screen (Home > Inventory > Networking), select the vDS that the host was connected to.
   
2. Click the Hosts tab.
   
   
   
3. Right-click on the host then click Remove from vNetwork Distributed Switch…
   
   
   
4. Click Yes to continue.
   Because you’ve already placed the host in maintenance mode and removed all the uplinks, it is safe to proceed.
   
   
   
   

One last step! We have to remove the VEM from the host. This step unregisters the VEM from the VSM.

1. Execute the following command at the ESX console.
   
   vem-remove –d
   
   
   

All done! You can continue with your usual ESX host decommission process.

Now, if you haven’t followed these steps correctly, you might receive the error message

Not removing VIB: Nexus 1000v switch found (N1K)
Please remove host from DV switch or run hotswap script.

If you get this, you haven’t performed steps 8 to 11. Remember, you have to remove the host from the vDS before you unregister the VEM.