We are staging a new Vault server that will be a remote server connected using Connected Workgroups to our main vault server, the publisher. Licenses are to be handed out using distributed licenses. Most on our publisher, and a few on the Subscriber (in case of temporary network failure) I have distributed licensing set up, but it isn't behaving quite how I expected. Here is the behavior we are seeing:
With both servers online:
- All requests for a license from the publisher succeed.
- All requests for a license from the Subscriber are passed along to the Publisher, and succeed.
- If the Publisher runs out of licenses, it starts to draw from the Subscriber's pool successfully.
X: If the Publisher cannot be contacted, any attempts to pull a license from the subscriber fails. (simulated by connecting client and server together on an isolated hub)
Right now, both servers exist on the same subnet of a LAN, and their firewalls are off. Eventually, the Subscriber will be on a different subnet connected via a BOVPN. What have I done wrong, or are my expectations incorrect here?
Solved! Go to Solution.
First you need to make sure there is full connectivity between the distributed license servers. That means that you should be able to connect to them via IPv4 (not IPv6) and that ports 2080 and 27000 are accessible. You can test the connectivity from each server to the next with Internet Explorer (only) by going to the addresses:
Your result should look similar to:
You will also need to place ADSKFLEX_LICENSE_FILE system environment variables where the ADMS server can access the license server, since it is the ADMS that pulls the Vault license and not the clients. Add all of your NLM servers to the system environment variable following these instructions:
In addition, due to latency across the WAN, especially with VPN, you will want to add an additional FLEXLM_TIMEOUT system environment variable as well:
For more information about Network License Manager connectivity issues and IPv6, please see my discussion post here:
Cool. If you run into any additional problems after implementing this, let us know.
We're looking into this issue once again, and troubleshooting some oddities. Re-reading one of your links I saw the following that I missed on my first time through.
Consider the following when using the ADSKFLEX_LICENSE_FILE environment variable to specify license servers:
If I understand this correctly, the CLIENT needs this system environment variable as well? I thought these only needed to be set on the server, and the server would bounce the request for licenses as needed. My Vault 2013 deployment image is from before we had distributed licenses so this variable is not being set on clients. Am I understanding correctly that this needs to be fixed?
yes to both places
you need that enviroment variable on the server where the ADMS console is and also on the client where the CAD software is installed if vault is the only network license product then you only need it on the server where the ADMS console is
To clarify Darren's post ...
For vault licenses, only the ADMS servers need that environment variable, and it must be a system environment variable instead of a user environment variable. You will at a minimum need to restart IIS after changing the value, but it might need a reboot (I'm not sure).
And as Darren said, if you are also using distributed licenses for your CAD applications, then you need to set the environment variable on the client machines.
Hope this helps,
Got it, thanks. Right now Vault is the only network licensed Autodesk product. *whew* I was worried I'd missed something big.
We're still testing the environment, and will report back when I've learned more. I can report that we have the firewalls back up on the vault servers, the issue was that when I created the firewall rules to allow port 2080, I had restricted the remote port as well as the local port to 2080. When I changed remote port to Any, and left the local port to 2080 communication seemed to be uninhibited with the firewalls up. I don't recall if that was an error on my part, or if I got that from doco. It probably was my choice.
Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register
Start with some of our most frequented solutions to get help installing your software.