Lmtools License File
Cynthia Skane
Hi, I'm hoping you'll be able to help - I don't have much experience with network licenses and this situation is confusing me! I have a client who's running two versions of LMTools: v. 11.12.1.4 and 11.14.1.3. They are only running Autodesk programs so it's not because of other products' licensing needs. When questioned why they have two versions they said they tried upgrading last year but were getting the "FLEXnet Licensing error: -15,570:The license server manager (lmgrd) has not been started yet, the wrong port@host or license file is being used, or the port or hostname in the license file has been changed." in the new one so have stuck with the old one. I don't have experience with older versions of LMTools and I'm not sure if it's been properly installed - the 11.12.1.4 version is not showing in the list of all programs. I have checked the license and it is correct. Both LMTools show the same host name and MAC address in the System Settings, the MAC is static. They are running a virtual server with Windows Server 2012 R2 Standard 64-bit. The "new" LMTools is installed in the default location (C:\Autodesk\Network License Manager), the "old" one in a subfolder under C:\Autodesk.
1) I know LMTools can be copied across from one computer or server to another and it seems that's how the older version of LMTools ended up on the server (unless back in the day there was no installer?) but is this going to affect its functioning?
Both LMTools apps have been configured in the same way - using a service with the same name, pointing to the same lmgrd, license file and debug file - so there is only one service running when you check the Services.msc. When running the server status inquiry in the old LMTools, it shows the correct status, users can access the 2018 versions of the software (they have not installed 2019 yet so I have suggested to do this to see if it will work - currently waiting on feedback). When running the status in the new LMTools, it shows the error message quoted above.
Ideally I would ask them to remove the service, remove all LMTools and reinstall just the new version to test, but apparently they have users using software 24/7 so cannot afford the potential downtime. I am trying to understand what is causing the error but it is difficult without being able to test and with my limited experience. I would be grateful for any input!
It was since pointed out that perhaps it *is* the 11.14 version running, but for some reason it uses the 11.12 environment to show the status and for some reason it shows an error in its own environment? It sounds weird but it does make sense considering 11.12 should not be able to "read" 2019 versions?
@Mark.Lancaster, @DarrenP this is what I was confused about too. But when you start the 11.12 LMTools and run status inquiry, all is good, you can see 8 out of 11 licenses are being used and you can see who started what, when. There are no errors. Curiously, the status indicates the 11.14 LMTools is being used.
The log file is shared between the two apps, I think that's why it shows no errors, it picks up the usage from the working version. If I try to point one LMTools to another (newly created) log file, the other one gets redirected there too... so it all works as if the two LMTools are one entity, just for some reason with two interfaces each reporting a different version... I think if we deleted the old one it would all work perfectly?
Just to let you know.. If you stop the service or replace it.. There's a low impact to the users.. The user's every so often ping the license manager.. If its not there, it will try again.. About the 2nd or 3rd time of pinging, the users will get a message..
There's some confusion here. LMTools is just the program you use to configure and monitor the service. The service consists of one license manager deamon, lmgrd.exe, v11.14.1.3 in your service, and one vendor deamon, adskflex.exe, same version as lmgrd.exe if installed together. Version 11.14.1.3 is required for v2019 of Autodesk products.
Yo can safely remove the old lmtools.exe. In fact you don't need any lmtools.exe to have the license service running, it's just used for maintenance.
This was the correct thing to do all along, and after cleaning up the old version and restarting the physical server, we got rid of the ghost duplicate of the licensing service and everything started working properly. Many thanks to everyone for their input.
Hello jyadav,
no, it is a Hyper-V Server, which runs 7/24. There are some processes of lmgrd.exe from SYSTEM, but it seems, I have to start it also with my own user, via the lmtools (Start/Stop/Reread tab), then it will work. Former it was not a problem, I could logoff, and it run furthermore, nowadays as I log off, the software will be ended immediately. Therefore I assume, that a service user would be needed?
You must run the lmtools utility as an administrator. If you do not run this executable as an administrator, the User Account Control (UAC) dialog will display as soon as it is started (as long as the UAC prompt is not disabled on the system).
Even if you want to configure a license server manager (lmgrd) as a service, you must have Administrator privileges. The service will run under the LocalService account. This type of account (LocalService account) is required to run this utility as a service.
You should have already completed all preceding steps found in the article Hosting your FlexSim licenses with lmtools, including all those under the headings "Preparation and Prerequisites" and "Activate licenses to your license server".
After the service is started, head back to lmtools to check the log. You can view the service log from the Config Services tab, press the View Log... button, located toward the lower right of the Config Services panel.
This was working fine with the older licenses AND I updated the lmtools, lmutil, lmgrid, alterad and mgcld files to the newer version I found on the Intel website which was 11.16.2 for all components except mgcld, which was 11.16.4.
Now most of the PADSVX licenses seem to work fine, but there are a couple lines that seems to throw this error too. I'm not sure if that was the case prior to me updating lmtools and the other files or not, but it's only select line items for that program and not everything like it is for Quartus.
but the problem is that solution ended up being a rule within the windows firewall, however in my case it appears my predecessor had already completely turned off the windows firewall on this server and yet this problem persists,
We do not receive any response from you to the previous reply that I have provided. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
A few clients, have come across this error in more recent versions of LMTOOLS (since 11.13.x) where when configuring the Service an error message pops up stating Windows preferred path \ProgramData to store service data is not set..
As a result, the service fails to start. The artwork.exe vendor daemon file is not running in Task Manager and the server status inquiry shows that the license manager is not running. Subsequently, there may not be a debug.log file created or the log file contains little to no data.
Reason: As it turns out, recent changes to the LMTOOLS permissions when creating the service have attributed to this error. It is also more likely to occur when using Windows Server 2012/2016, which has much more strict permissions constraints than client OS machines or Windows Server 2008. As a result of this change, the service is created with LocalService rights rather than LocalSystem, as it has been in the past. This minor change in permissions is enough to prevent your license manager from starting properly. This is why LMTOOLS has recently defaulted the location for the debug.log file to the C:\ProgramData folder because that is where LocalService has its write privileges.
Work-Around: As it turns out, many of us do not prefer the debug.log file to be in some random hidden folder used by the operating system. However, since the LocalService doesn't have the same write privileges as LocalSystem or your own administrative group user, you will often run into one of these errors and your NLM simply will not start. Whereas I suspect you could simply change the Log On properties to LocalService, I prefer a much easier solution.
1. Create a new folder in the root of C:\ called C:\FlexLM and copy all of your license manager files (lmgrd.exe, lmtools.exe, lmutil.exe, artwork.exe, license.dat) into this folder. Note: Since recent releases of FlexLM, the default location of C:\Program Files has been changed due to the restrictive permissions of recent Windows Server Operating Systems. It is now best practice to install in a root directory of your choosing. If you do choose to keep it under Program Files, then the following steps will still apply.
3. In the Permissions properties window, click the Add... button. In the next window, type Everyone into the object names box, then click Check Names to verify. Then click OK to continue.
Click Add...Type Everyone then click Check Names..
4. On the Permissions window, Everyone should now be listed under Group or user names. Make sure it selected and then check the box for Full control under Permissions. Click OK and then OK again to close all property windows.