Using "lmutil lmstat" to check License Mgr v10.+ status on a remote machine (solution)

40797
23
06-24-2010 10:17 AM
RebeccaStrauch__GISP
MVP Esteemed Contributor

updated Feb 20, 2018

This is to help anyone that may use the "lmutil" command line utility to check the status of concurrent license usage on a remote machine (i.e. from a local, non license manager (LM) machine).  Several things have changed from the 9.3.1 LM to the v10 LM and minor changes are needed to get this to work (at least with the LM release with the beta/release candidate).

Syntax we used in 9.3.1

lmutil lmstat -a -c   "\\<IP to out LM server>\Program Files\ESRI\License\arcgis9x\ArcINFO9.lic"

or "....\viewer9.lic".    This command would list all the licenses available and in use for that particular LM server.

Syntax we need to use in version 10

lmutil lmstat -a -c   "\\<IP to out LM server>\Program Files\ArcGIS\License10.0\bin\service.txt"

Beside the path/location and file name, the file format has also changed for the ArcGIS 10 license manager.  They replaced the multiple <product>.lic files with the service.txt which makes it much easier when you have to lock the LM to a port (for firewall issues) --- one file to deal with instead of multiple.    However, the one problem I ran into is that the default/generic "this_host" prevented the lmutil command from looking at the remote LM machine.  Instead, it responded that the license manager was not running on my <current machine name>. The quick fix is to change "this_host" to your LM server's name or IP address in the services.txt file.  At least that fixed it for me.

BTW - the command line syntax above assumes you are in a directory that can run lmutil, i.e.,either beacuse 1) it's in your path, 2) you have the lmutil.exe copied to your current directory, or 3) you are in the "C:\Program Files\ArcGIS\License10.0\bin" directory.

This was logged as a "bug" with this work around as the solution:
[#NIM058540  The command "lmutil lmstat" does not function properly for remote systems in License Manager 10 ]

Edit the service.txt file as follows:
Old - "SERVER this_host ANY"
New - "SERVER <hostname> ANY"

Hopefully this will save someone else using the lmutil a little time when making the switch.  -b

----

UPDATE (works with 10.4.x license manager too), now I just use:

lmutil lmstat -a -c @<servername>

with the @ sign, but  <server> will be the location of your license manager.   I have a copy of the lmutil,exe in the same folder as I create a  chk_lic.bat file with the line above.

EDIT: February 2018.  Someone was looking for the WhereDidAllTheLicensesGo by Julie Skuba (whose profile does not look active) on the ideas page Add new functionality to License Manager - Usage &amp; Analysis Tools .  It seems all the links for download of this tool are broken right now.  I found a version from 2004 that I zipped, but didn't see a way to upload it to the ideas page, so I will add to this post for others.  I am not the author of this script, and there may be other posts on the tweaks that are needed for newer LM versions...just posting here as a courtesy. 

23 Replies
RichardDaniels
Regular Contributor
There is also a free download from the old arcscripts site that gives you the application WhereHaveAllTheLicensesGone (http://arcscripts.esri.com/details.asp?dbid=14222). This still works for obtaining license status information, but to update it to v10 you must replace the lmutil.exe provided in the download with a fresh one from C:\Program Files\ArcGIS\License10.0\bin (i.e., you need to update lmutil.exe to version 11.6.1.0).

Rich Daniels, GISP
0 Kudos
MattCharton
New Contributor III
Thank you so much, Rich!  I was beating my head in on this.  I'm not using the arcScript that you mentioned... but I do have my own scripts that use lmutil, and all of them were failing after the update.  Replacing lmutil on the remote machine solved all my problems and I am very grateful.
0 Kudos
V_StuartFoote
MVP Frequent Contributor
Not sure that including the path to the license file is necessary or even desirable when querying a remote FLEXlm service using the lmutil lmstat -a -c command.  The -c "license file path" seems a local system convention.

Macrovision/Flexera's FLEXnet administration guide is pretty clear that for remote systems all you need is the @hostname, @FQDN, or @IPaddress; if you want a specific port, e.g. 27004 for ArcGIS 9.x license manager just prepend it.  

So, 27004@<IP to out LM server> should return the status for the ARCGIS vendor service. Without the 27004 and you'll get status on all FLEXnet license service running on that system.

Beleive the 27004@<IP or FQDN> convention should work in your scripts.

Also, the FLEXnet release at ArcGIS 10 is version 11.6.1, so you'll want to use that version or later of the lmutil as was indicated.  And for those managing multiple product license servers, there are no problems with using the latest release, version 11.8,  of the Flexera lmgrd with the ArcGIS 10 License Manager--in fact Flexera recommends that you always run the latest version of lmgrd.    Download the appropriate version of the latest release from the Flexera support site http://www.globes.com/support/fnp_utilities_download.htm and replace the ESRI deployed version.

Finally, I've had some issues with changing the "this_host" value in the "service.txt" file over to hostname or MAC, it seems more stable to just leave it as is while perhaps locking the LM and vendor services to specific ports with edits of the "service.txt" file.

It is probably worthwhile to have a read of the FLEXnet Publisher License Administration guide that is also available from that site.  There is some discussion of the "new" TrustedStorage encrypted storage that ESRI has used as an alternative to text based license files.

To reiterate--give a try to dropping the "path to license file" from the lmutil lmstat -a -c in favor of just the port@IP, or port@hostname, or port@FQDN;  do update to the latest lmutil, v 11.8, from Flexera; and compare functionality between the new ArcGIS 10 ESRI LSAdmin.exe tool and the still valid lmtools, lmutils and lmgrd provided and maintained by Flexera.

Stuart Foote
UT San Antonio
0 Kudos
RebeccaStrauch__GISP
MVP Esteemed Contributor
Thanks Stuart!  I tried the @<host> or in my case @<IP> and it worked.  Sure beats the full path name.
AlexZhuk
Regular Contributor
Thanks to everybody! It helped.
The program works now, sort of... Most of the time it shows all used licenses correctly, except the Maplex extension, which it shows as all (we have 3 of them total) unused. Go figure...

The only program I was using was ArcInfo plus a few extensions. Sometimes the WHATLG shows me that I'm using them plus one ArcView. I had to completely log off from my computer to have the WHATLG reset.

By the way, I think you missed "c$\" in the string "...LM server>\Program Files...". When I changed it to "...LM server>\c$\Program Files..." it started working for me.

Alex Zhuk,
San Francisco, CA
AdrianneBlack
New Contributor III
Rich,

I have replaced the lmutil.exe file in the "Where Have All the Licenses Gone" folder with one from the C:\Program Files\ArcGIS\License10.0\bin folder.  I have checked the version and it is as you suggested.  I have also changed the name of my server in the LicenseInfo.txt file, but the tool still doesn't run.  I tried some of the things that others suggested, but I'm not a programmer. 

The error message I get suggests the ESRILicenseUse.txt file is being used by another process.  However, I'm not sure how that could be the case.  The file is closed and I'm not using it anywhere else.  Sometimes I can run the lmstat.bat, lmutil.exe and/or the rtnhung.bat files individually, then the ESRILicenseUse.txt file will report the licenses in use.  However, this information never shows up in the handy WHATLG window. 

Can you provide any other suggestions? 

Thanks!
0 Kudos
V_StuartFoote
MVP Frequent Contributor
Adrianne,

Sounds like a permissions problem when running the script. Does your user account have ownership, or at least modify permission for the ESRILicenseUse.txt file?

Stuart
0 Kudos
AdrianneBlack
New Contributor III
Yes, the file is on my computer (laptop) and I have "admin" privileges.  And when I go to Properties and the Security tab for that file all boxes, except for "Special Permissions" are checked for both the Administrator account as well as my account.  - To confirm what you are referring to.

However, the license manager is on another computer (a server) administered by our IT staff.  Do you think I could have something to do with permissions on files on that computer?  We used to be able to run this tool with no issues at 9.3 and 9.3.1. 

Thanks!
0 Kudos
V_StuartFoote
MVP Frequent Contributor
Adrianne,

Ok, the other possibility is that you have a latency issue in capturing the result of the lmstat.bat back to the ESRILicenseUse.txt file.

Functionally the WHATLG applet runs a simple FlexLM query of the license server, pipes the result to the ESRILicenseUse.txt file, and then parses that file to populate the .NET 1.1 based WHATLG GUI

The lmutil.exe used needs to be a current version that is compatible with the lmgrd.exe and ARCGIS.exe FlexNet Publisher components in use on the license server. You've done that so that probably isn't the problem.

Here is an example command from the lmstat.bat batch file setup with WHATLG install.
lmutil lmstat -a -c @'your-license-server'  >  ESRILicenseUse.txt


The greater than ">" symbol simply redirects the output of the lmutil lmstat -a command into the ESRILicenseUse.txt file.

When the batch is run by WhereHaveAllTheLicensesGone.exe, the ESRILicenseUse.txt file handle is locked for redirect writing (showing as busy for any other access), and after some time elapses the .NET GUI is launched and populated by parsing the now released license use text file.

Think about what happens if there is a delay and the license use text file has not been closed yet, e.g. the lmutil lmstat -a is still writing to it? The WHATLG GUI will get nothing to work with, or you'll get an error that the file is in use.

I think that is what is occurring.

So how to fix it? First a test. Open a cmd.exe window and change directory to where you have a copy of the lmutil.exe.

Enter, and time how long it takes to complete...

lmutil lmstat -a -c @'your-license-server'


[INDENT]Check with your server admin as to which port the ArcGIS 10 LM is using, default would be first available in range of 27000 - 27009, or may have been set with an edit of the service.txt configuration file.
http://help.arcgis.com/en/arcgisdesktop/10.0/install_guides/License_Manager_Guide/index.html#/Lock_t...[/INDENT]

now enter, and again time how long it takes to write to the screen...

lmutil lmstat -a -c '2700x port used'@'your-license-server'


If there are no firewalls interfering it should be a shorter delay. If so, go ahead and make the same change in the lmstat.bat file. And run WHATLG again.

To explain, if there is no port prepending the -c @'your-license-server' the querry starts at 27000 and works its way up the range to 27009. Each port takes a moment for the lmgrd.exe service to respond and can take 10's of seconds total to complete the query. Specifying the port in use shortens the delay. The addition of a firewall can also impose serious delays, without open firewall ports on the server, when you send the lmutil lmstat -a query, the same 27000 - 27009 range is polled, but this time the firewall blocks the query which must timeout for each port before the next -- much longer for each and can total 100's of seconds. For just that reason I open ports 27000 - 27009 on my FlexNet license servers to clients on our network.

ESRI used port 27004 for ArcGIS 9.x LM, port 27005 for ArcGIS 8.x LM. At ArcGIS 10.x LM they no longer assign a port, but allow the lmgrd.exe launch configured by the service.txt file to float to the first available port in the range 27000 -27009. Edits in the service.txt configuration can bind the port for performance and firewall control.

See if making an adjustment to the lmstat.bat file fixes things. And perhaps ask your server admin about the firewall settings if any.

Stuart

P.S. if your laptop is coming in via a routed wireless, or worse a VPN--you'll have additional traffic routing/firewall issues
0 Kudos