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

[MarcusAndersson]

Hi,

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!

[Scott_Tansley]

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:

https://desktop.arcgis.com/en/license-manager/latest/configure-the-arcgis-license-manager-to-work-th...

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.

[MarcusAndersson]

Hi Scott,

Thanks!
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!

[Scott_Tansley]

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:

https://www.thewindowsclub.com/how-to-use-port-query-tool-portqry-exe-in-windows-10

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...

[MarcusAndersson]

Hi,

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.

Thanks.

[Scott_Tansley]

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

[Anonymous User]

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

[AmnoyAm]

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, https://desktop.arcgis.com/en/license-manager/latest/configure-the-arcgis-license-manager-to-work-th....  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.  

[MarcusAndersson]

Hi,

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.

[MarcusAndersson]

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:

No.	Time	Source	Destination	Protocol	Length	Info
10084	32.872533	Client IP	Server IP	SMB2	234	Create Request File:
10089	32.889953	Server IP	Client IP	SMB2	298	Create Response File:
10091	32.890468	Client IP	Server IP	SMB2	146	Close Request File:
10094	32.911655	Server IP	Client IP	SMB2	182	Close Response
10100	32.961497	Client IP	Server IP	TCP	54	64357 → 445 [ACK] Seq=273 Ack=373 Win=1022 Len=0
12534	43.119308	Client IP	Server IP	SMB2	234	Create Request File:
12539	43.137734	Server IP	Client IP	SMB2	130	Create Response, Error: STATUS_FILE_IS_A_DIRECTORY
12540	43.138850	Client IP	Server IP	SMB2	234	Create Request File:
12544	43.160035	Server IP	Client IP	SMB2	298	Create Response File:
12545	43.160427	Client IP	Server IP	SMB2	275	GetInfo Request FS_INFO/FileFsVolumeInformation File: ;GetInfo Request FS_INFO/FileFsAttributeInformation File:
12551	43.178996	Server IP	Client IP	SMB2	258	GetInfo Response;GetInfo Response
12553	43.179175	Client IP	Server IP	SMB2	146	Close Request File:
12557	43.197854	Server IP	Client IP	SMB2	182	Close Response
12576	43.249108	Client IP	Server IP	TCP	54	64357 → 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 🙂