Select to view content in your preferred language

Users are unable to get ArcGIS Pro licenses depending on location..?

02-28-2023 07:10 AM
New Contributor III


We're seeing some strange behaviour where some users are not able to check out their ArcGIS Pro licenses depending on where they are (on which network they are I assume, otherwise I'm going nuts for real)..

One user that's been able to communicate with the License Server Administrator and get Pro-license without issues for weeks were today, from a new location/network, unable to get a license for instance. 

Has anyone else experienced similar behaviour?
I've tried some debugging but can't really see what the issue is. The user can ping the server running license manager (connected via Global Protect).

Can some ISP's deny some protocols/traffic while others let the traffic through? We're currently not tunneling all traffic through the GP-VPN but that might be an option going forward.
I've tried to open up some ports on the router the user was using today but that didn't work either.
I can't recreate the issue on my laptop, even though I've tried a number of different networks and hotspots in Stockholm today (RIP our cyber security manager), I always get a license when I'm starting Pro.

I've used Wireshark on the clients computer to try to sort things out but I can't see any TCP-traffic (or other) to the server hosting the LMA during a failed attempt, while we get loads of traffic during a successful attempt.
The set-up is that Portal and LSA is residing on different servers so according to the article: (ESRI) Named User the first call is made to Portal to see if the user is allowed to have a license and then to the LSA to actually check out a license, and then start Pro.
Does anyone know what kind of traffic that is generated to check with the LSA? For the first call to Portal it says it uses HTTPS.



We're on Enterprise 10.9.1 with LSA 2022.0.

The users are connected to out network with GP the whole time.

All input is welcome at this stage as we're running out of ideas here really. Thanks!

0 Kudos
9 Replies
MVP Regular Contributor

This is highly likely to do with firewall rules.  In your primary location the LAN may be able to connect directly to the license manager.  But each 'regional' office may have different license rules as they are WAN not LAN.  Have a read of this:

The chances are that the person who normally works okay, would work okay again if they came back to the primary office.

There is a thought that the connection is to the Portal on HTTPS (443) but this starts the negotiation, and then other ports are used in the background.

Scott Tansley
New Contributor III

Hi Scott,

Yes, the person recieved a license once he returned to his "regular office" and have had no problems since.

I've tried to go down the Firewall-road too, but that is a hard road to walk I feel like when talking to the company that runs our IT-infrastructure.
Do you have any recommendations on what to check or what to say more specifically regarding this?
Can it otherwise be that it's blocked by the users "own" firewall on different locations (sometimes built into routers etc..)?

The link is helpful, even if I've read it approx 1000 times by now 🙂 Thanks again!

0 Kudos
MVP Regular Contributor

hey - it's hard to give specifics without understanding your network topology.  In all honesty I tell most of my clients to use licensing from ArcGIS Online instead of Enterprise, but in New Zealand this is much a civil defence thing as well as a simplicity thing.  

The key thing possibly is passing on the ports information in the link from my first response.

There are also tools out there that can help test if a port is reachable:

Depending upon policies the user may not be able to install/run these, but your admins/providers should be able to.

BTW the port number will be in the JSON license file for your Enterprise Portal, I think that by default it is 27000  - but check the JSON file for the hostname and port that it's tied to...

Scott Tansley
0 Kudos
New Contributor III


Yes, I understand it’s hard without more details. Thanks anyways.

We’ve used a license on AGOL as a ”spare/backup” but feel that we need to solve this now as we’re completly moving away from AGOL. Migrated to Enterprise ~3 years ago. We’re not a gov/defence-company but a private one, but we try to have as tight of a security as possible ”anyways” 🙂

Yes, I’ve set the port to 27000 in the json.

I’ll look into portqry, I’m one of those that can give adm access so that might be a way forward. I’ve used telnet and others but not this one.


MVP Regular Contributor

good luck with it all.  Sorry my advice is a bit generic, hopefully the tools/thoughts help you on the journey.

Scott Tansley
by Anonymous User
Not applicable

The only thing I would add is to create a firewall rule for the entire range 27000-27009. 

Esri Regular Contributor

In your situation, Pro makes two separate calls when starting.  Upon startup, it communicates to the portal through https.  You're know when you you get the login prompt to your portal.  Once you log in with a valid Pro licensed user, the portal will verify the user and determine what license(s) are assigned to the user.  It also determine where to get the license from.  Pro then makes another call to the designated license manager using the TCP/IP protocol.  This is likely where the failure occurs.  If you refer back to the article mentioned above by Scott_Tansley,  It walks you through the process to open your specific ports through your firewall.  Keep in mind there may be more than one firewalls between Pro and the license manager depending on your location.  As for the ports, the license manager uses two ports, 27000 for the lmgrd.exe daemon and any open port for the arcgis.exe daemon.  You set this up in the service.txt file as described in the article.  Then open those two ports through the firewall.   When troubleshooting, just verify communication to the license manager through those two ports are possible.  

New Contributor III


Thanks. Yes the "right" ports are open in the FW and since 95% of the users gets their license fine I believe that's the reality, too.
Right now I'm leaning towards that the FW makes difference between traffic in some way depending on if it's originating from a LAN or a WAN as suggested by @Scott_Tansley.
I'll try to have our IT-infrastructure provider to look into this and see what comes out of if.

0 Kudos
New Contributor III

Hi all,

Have done some more investigations and according to our IT-infra provider the firewall is allowing on 27000/5152 no matter origination. Darn, would've been a neat and easy solution.

One thing that came up today was that when I look in Wireshark on a "successful license call" there's a lot of TCP-traffic between the client and the license server (filtered on clients IP). But when the call is unsuccessful there's hardly any TCP traffic, but instead just some SMB2 traffic. Don't know what this indicates really, but if any of you are good at packages/traffic maybe someone can pick up something from this..?
Failed call:

1008432.872533Client IPServer IPSMB2234Create Request File: 
1008932.889953Server IPClient IPSMB2298Create Response File: 
1009132.890468Client IPServer IPSMB2146Close Request File: 
1009432.911655Server IPClient IPSMB2182Close Response
1010032.961497Client IPServer IPTCP5464357 → 445 [ACK] Seq=273 Ack=373 Win=1022 Len=0
1253443.119308Client IPServer IPSMB2234Create Request File: 
1253943.137734Server IPClient IPSMB2130Create Response, Error: STATUS_FILE_IS_A_DIRECTORY
1254043.138850Client IPServer IPSMB2234Create Request File: 
1254443.160035Server IPClient IPSMB2298Create Response File: 
1254543.160427Client IPServer IPSMB2275GetInfo Request FS_INFO/FileFsVolumeInformation File: ;GetInfo Request FS_INFO/FileFsAttributeInformation File: 
1255143.178996Server IPClient IPSMB2258GetInfo Response;GetInfo Response
1255343.179175Client IPServer IPSMB2146Close Request File: 
1255743.197854Server IPClient IPSMB2182Close Response
1257643.249108Client IPServer IPTCP5464357 → 445 [ACK] Seq=946 Ack=1025 Win=1020 Len=0


And this is all we get really (did run Wireshark at the same time from both Client and Server and the logs are identical if filtered on clients IP)

Oh well, I'll keep digging 🙂

0 Kudos