Unfortunately, having a screen shot of the error message is a good start, but it is rarely enough information to diagnose the problem. With a little bit of knowledge regarding your license installation configuration and what factors are involved, you may be able to understand what is happening and help to expedite the solution.
On the other hand, floating licenses allows you to use NX functionality from any work station on the same network because a license server controls the number of licenses handed out for the NX functionality that you are trying to use. Floating licenses are always counted by the license server, and are best characterized as a pool of licenses.
Is it true that you cannot use a license server for node locked licensing? This is not entirely true. It is true however, that all floating licenses must be managed by a license server, so you must use a license server if you incorporate both floating and node locked licenses in the same installation. Using a license server for node locked licenses can also be considered as a convenience, since it allows you to maintain a single license file on the server that controls both counted (floating) and uncounted (node locked) licenses.
For instance, when you are using a license server with node locked licenses, and you are upgrading from NX 9 to NX 10, you only have to replace one license file on the license server machine because all of your client machines will be looking to the server for an appropriate license when it is needed.
On the other hand, if you had a group of node locked licenses in a single license file that is not managed by a license server, you would have to distribute the license file to every machine in the list, and put it in the right location at each client machine.
Where does the license server reside and who maintains it? These are license configuration options that are determined by the customer. The SPLM License Server is simply a background service that can run on any machine in a supported Windows, Mac OS, or Linux environment. It is tied to a specific machine by Composite ID which is an encrypted hexadecimal number that is derived from the MAC address of one of the network adapters of the server machine.
The customer can register up to (3) composite IDs to assure replication in case a server fails or goes off line. The SPLM License Server service can be run on the same machine as the NX software so that the same machine can be both client and server.
If a floating license is tied to a server by Composite ID, what ties a node locked license to a specific machine? In node locked licensing, each piece of NX functionality is linked to a specific machine by an unencrypted MAC address of one of the network adapters installed in the client machine.
How do I determine if the license configuration for my NX installation is controlled by a server? The easiest way to make this determination is by looking at the system environment variables on your machine. You can view the Windows system environment variables by using the “set” command at the command prompt in a cmd window.
Here is an example of typical output:
SPLM_LICENSE_SERVER=<port_number>@<server_name> or <full_path_to_license_file> (note: for NX 9.0 and Later)
UGS_LICENSE_SERVER=<port_number>@<server_name> or <full_path_to_license_file> (note: for NX 8.5 and earlier)
UGS_LICENSE_BUNDLE=<license_bundle(s) separated by “;”>
If the SPLM_LICENSE_SERVER and/or UGS_LICENSE_SERVER variables are set to the <port_number>@<server_name> syntax, your license configuration is using a license server. The port_number (usually 28000) is the listening port for the server and the server_name is the computer name of the server on the network.
If the SPLM_LICENSE_SERVER and/or UGS_LICENSE_SERVER variables are set to the<full_path_to_license_file> syntax, your license configuration is not using a license server, and is therefore node locked.
What are some typical issues or problems that cause NX license errors? Most errors that occur in an installation that has a server are on the server side. Either the server goes down or is replaced, a piece of hardware is swapped out on the server and the composite ID changes, the computer name has changed on the server, or a newly configured firewall is blocking traffic to and from the server.
On the client side, as long as the environment variables are set properly and the server is alive and reachable, NX should boot and run properly. In an installation configuration where there is no server, the environment variables must be set properly for NX to find the license file. If a license file is swapped out to accommodate a newer version of NX the file path and name must match the SERVER environment variables.
What are NX license bundles? A license bundle is a tool that is utilized to group associated pieces of NX functionality. You can set and change your selected license bundles from the NX menu (File–>Utilities–>Select license bundles…). In this dialog, you can add a maximum of two of the available licensed bundles to your bundle list. Unfortunately, NX doesn’t remember your selection after you exit.
If you see what appears to be a license error at start up immediately after a fresh NX install or upgrade, you may find that the UGS_LICENSE_BUNDLE environment variable is not set properly. Setting it to at least one available bundle will allow NX to start up without error if everything else is in order.
Well, that is all that I have for now. As a person who spends a fair amount of time on the telephone with end users and IT professionals when things are broken, I wanted to share a little bit about the terminology that I deal with every day. My goal is not to turn the end user into an IT professional or licensing expert, but to share a brief overview about the basic structure and elements of PLM licensing. I hope that you’ll find it interesting and/or useful.
Thanks for reading…
Ron St. Denis