Can't access Lisense Manager installed on Azure VM machine

AhmedShehata3 · ‎08-10-2022

Greetings

I've installed an Enterprise instance 10.8.1 on Azure using the Cloud Builder. Later, I tried to install and authorize GIS Professional Basic licenses using LM 2021.1 on the Portal machine. It was installed successfully and I can see licenses available, but I can't connect to it from my ArcPro. It says "A valid ArcGIS License Manager for your Licensing Portal couldn't be found on the specified host".

Based on this article I tried the below with no joy:

1- Changing the LM hostname in the Portal Admin to "VM" or "VM.Vnet" or "public name". All didn't work. The license file was generated by the VM.Vnet as Hostname. Worth mentioning that on Machine IDs in LM it only shows the VM name in both the Hostname and Domain.

2. Adding port 27004 to the service.txt file in VENDOR line. Also didn't work.

The only remaining thing to do is to change the portal.machine.name in the portal-config file on the Server machine. When I checked it, it's "ENTBUILDVM.34.........INTERNAL.CLOUDAPP.NET" which I think it comes from the VM template used by the cloud builder. Not confident to change this as it may compromise the entire EGIS

Another issue is that I don't seem to be able to access Cloud Builder 10.8.1 after installing LM 2021.1

Any idea what would be the best way to solve this?

ZacharyHart · ‎08-10-2022

Are you on the same network/domain as your Azure deployment? Does your IT provide you with VPN? Can you ping the host from your desktop/workstation?

As an additional test: on your/one of your VM's in Azure, can you install Pro there and test the connection to LM? (I'm presuming you've configured Pro appropriately to connect to Portal etc. in the licensing configuration).

AhmedShehata3 · ‎08-10-2022

Thanks for your reply. I'm accessing the portal from outside the deployment without a VPN. I can't ping either the local URL (VM.Vnet) or the public one (gis.example.org) from my desktop, but of course,I can access the public one from the browser.

I've installed ArcGIS Pro on the ArcGIS Server VM and tried to use it, but it returned an unknown error. Please see it attached.

When I googled the error, it was related to the ArcGIS Portal URL stored in the System Registry. When I check it, I can see it's the Portal public URL that I entered while logging (https://gis.example.org/portal).

ZacharyHart · ‎08-10-2022

I'm not quite sure I understand the host name changes, but they sound problematic. The host name in Portal Admin and our LM is simply the name of the VM...we've never made changes to that.

What I can tell you is that if any of our users attempt to use Pro/connect to the LM while off network, they are unable to unless they initiated a VPN connection to our network. I don't know what IT resources your organization has but this is the time to engage with them. By ping, I mean can you ping the host name of the VM itself? I presume you will not be able to.

Are you able to revert your changes to the host name in LM and Portal Admin and then try the connection from your Pro in Azure again?

The cloud builder adds in a load balancer by default which adds a layer of complexity here. It also creates your virtual directories in Azure storage. I don't know your use case here, like how large of a deployment you are scoping out. I will also be honest in saying it has been some time since I've worked with cloud builder. All that said, our experience with it was very poor and we spent so much time on the clean-up configuration after the initial deployment. In the end, we ended up scrapping all of it and redeploying conventionally within an Azure VM.

AhmedShehata3 · ‎08-10-2022

Hi Zachary, I've installed ArcPro on the ArcGIS Server machine (VM within the deployment), disabled the firewall on both Server and Portal VM and that allowed me to initiate ArcGIS Pro (opened the licensing portal and it appears by the public name). I think that tells that the hostname isn't an issue now.

Later, I tried to initiate ArcGIS Pro on an external desktop with the same license portal, but no joy.

Any idea what would be the next troubleshooting step? I don't think a VPN to the Azure deployment would be applicable.

ZacharyHart · ‎08-10-2022

our configuration is a bit different than yours. I presume you are using this article as guidance based on what you've referenced in your original post: https://support.esri.com/en/technical-article/000024588

I'm keying into this part here:

Edit the License Manager Info text box. Replace the default Azure machine name with the License Manager host name. If a client is connecting from a different domain than the License Manager, add the FQDN instead of the hostname of the License Manager.

Our LM is hosted on the same VM as Enterprise and therefore has the same host name. So we changed nothing here. Additionally, because our Azure Environment is stitched to our domain/network (kinda a WAN) we did not include the FQDN. I believe the URL you provided is what you're referring to as your FQDN of the VM? Do you have anyone as the admin of your Azure environment?

I also came across this: https://support.esri.com/en/technical-article/000027816 and this also references items related to your FQDN...again, I don't know all the details about your particular environment.

AhmedShehata3 · ‎08-11-2022

Thanks for sharing the articles, I guess the FQDN shouldn't be an issue now as it resolves in the VM registry by the public hostname. I believe my main challenge now is to ensure the ArcGIS License Manager and vendor daemon ports are open in the Azure virtual network and Azure Application Gateway. Do you think this would be possible with CB deployments?

ZacharyHart · ‎08-11-2022

I'm sure it would be possible, but I'm fortunate to (now days) have IT support to manage our Azure infrastructure. (I don't miss the days of having to be the DBA, server admin, and everything else needed to keep GIS stack of physical servers all up and working while trying to manage an Enterprise system (with project work!) all on top of that!).

Keep me posted on how this next phase goes for you!

AmnoyAm · ‎08-22-2022

Just got back from vacation and saw your post. I wasn't sure if you got this resolved. Looks like you got everything installed and licensed correctly. It's the communication that is the issue. When configured, Pro will call to the portal's public FQDN. If successful, it will display the portal's login prompt. You then log in with a user with an assigned Pro Named User license. Portal verifies the username and the license assigned. It then tells Pro to go to the specified license manager for the Named User license. This is where you're running into the issue. Pro is not able to connect to the license license manager. Either the named provided is not reachable publicly or the ports used by the license manager are blocked. The following are things to consider in this configuration:

1. The client machine where Pro was installed communicate with the license manager using TCP/IP protocol. Whereas the call to the Portal uses https.

2. Configure the license manager to work through a firewall. This involves locking down the ports and opening those ports through the firewall. Keep in mind, there are multiple firewalls to consider, the OS built-in firewall, Azure's firewall and your network firewall. The following document provides more detail on the subject and a step-by-step process: https://desktop.arcgis.com/en/license-manager/latest/configure-the-arcgis-license-manager-to-work-th...

3. Verify the license manager host name is reachable from the Pro machine. I assume you are using the public FQDN or IP Address. Go to your portal admin/License/Update License Manager. For the hostname, provide the public FQDN or IP Address.

Hope that helps.

AhmedShehata3 · ‎08-22-2022

Thanks for your reply.

From what you said, I think the issue could be with the public accessibility of the Portal machine. The deployment is on an Azure Vnet (not domain-joined), so I used the VM internal FQDN (https://vm.vnet) as the hostname in my Portal admin. When I used the public DNS of the Portal URL it failed to connect. How would I be able to make it accessible while it's behind an App Gateway and it doesnt have a public IP or DNS name?

With regards to the ports, I created inbound rules in the VMs firewall for ports 27000-27009 and 5152. Also created a Network Security Group with inbound rule for the same ports and assiciated it with Subnet including the VMs. Not sure if there's another place I should allow these ports on. Can't do it for the App gateway.