Portal privatePortalUrl and Federation Admin Url from Cloud Builder deployment

[FraserHand1]

I am looking for a bit of clarification on the privatePortalUrl setting in ArcGIS Enterprise / Portal for ArcGIS and the Server Admin Url in federation in a Cloud Builder context

The description of the setting in the API reference says

• privatePortalURL—Informs the portal that it has a front end load-balancer/proxy reachable at the URL. This property is typically used to set up a highly available portal configuration.

In this thread Portal Best Practices for setup?  this comment is made

"In Portal HA, you'd also set the private portal URL for Portal, (the URL used by Server to talk to Portal) to go through a load balancer as well to make sure that even if one of the Portals go down, you can still reach the Portal." Jonathan Quinn

so is this url just for internal traffic only and doesn't need to be resolved externally? When deploying through Cloud Builder this is set to be one of the internal load balancers in front of Portal, but behind a public reverse proxy (using IIS with ARR).

The second part of this is also when deploying with Cloud Builder, the Portal / GIS Server federation has the public DNS for the services url and the internal load balancer in front of the GIS servers for the admin url.

What I see is that when using ArcGIS Pro it is very slow to share web layers etc and you can see this internal IP being exposed - there are multiple timeouts as ArcGIS Pro attempts to connect to the load balancer ip (on the admin url) - it eventually does bring up the sharing tool and does share ok but makes the experience in ArcGIS Pro very slow.

Looking at the AWS documentation it states that the services and admin url should be the same public DNS - is this the same for Azure? And why is Pro connecting to the federated admin URL anyway? Shouldn't this be faciliated by Portal? What happens if this is disabled as per portalscan / serverscan recommednations? I had thought that the admin url was another back end channel for comms between Portal and the GIS server?

So the question is if this is a private "backend" communication channel why does ArcGIS Pro attempt to connect to it? Should this setting be an external DNS? 

If anyone could provide some insight into the actual mechanics of ArcGIS Pro and the federated admin url that would be appreciated.

Thanks

Fraser

EDIT:

Deploy Portal for ArcGIS on AWS—ArcGIS Enterprise on AWS | ArcGIS Enterprise 

{"localHttpPort":"80","localHttpsPort":"443", "portalLocalHostname" : "awsportal.esri.com", "privatePortalURL" : "https://awsportal.esri.com/arcgis" }

There is another linkwith the federation whihc also has the external public DNS

[JonathanQuinn]

Even though the Data Store will list an "owning system URL", which may point to a single machine, or even when you register the Data Store, you enter a specific machine URL, the Data Store knows to communicate with all server machines in the site. Server also knows how to talk to all participating Data Store machines, so for the most part, you can disregard URLs in regards to Server to Data Store or Data Store to Server communication.

[Anonymous User]

Hi Jonathan,

Please let me know if my questions making you furious, my intention is to only understand the reason behind it and i may not seems to be satisfied for now . Sorry about that

When you say disregard this url as both server and datastore machines know how to talk to each other.

Then, why in both cases url's are different? please refer below screens

relational

and spatiotemporal

We believe since datastore is very much dependant on single machine url other than our load balance url is reason behind the isse when same machine is not working or stopped like OSI5666 or OSI5667. 

We believe owning system url should be https://gis.de-prod.dk/arcgis which is load balancer url for hosting servers. ?

Please suggest

BR

Saurabh

[JTessier]

Saurabh Gupta‌, we found at 10.5.1 that the Owning System Url seems to be important when migrating to new hosting servers.  During our migration we found that the OwningSystem url was set to the previous host and not the loadbalanced url and it caused us problems during validation - "Error Method argument cannot be null Code 500." for the standby.  Though not entirely sure this was the only issue.  But esri support helped us correct the owningUrl by issuing registerdatastore (without unregistering)  using command line: registerdatastore.bat <https:loadbalancedURLTOFEDHOSTED/arcgis> <adminuser> <password> --stores relational.

This corrected the issue.

[Anonymous User]

Hi J,

Wow this is really helpful comment . So you're suggesting me to use command line on both relational datastores server (or only on primary one) to correct owningsystemurl without unregistering it. And same goes for spatiotemporal datastores.

I hope doing so won't corrupted our datastores because these systems are in use since an year but please suggest if othrewise.

Br

[JTessier]

Hmm, well I would defer to Jonathon Quinn since he is an esri employee as to what you should do and if there is any risk to re-registering the datastores to the hosting servers (you definitely dont want to unregister if I recall is what we were told).  We only did it to the relational (do not have a spatiotemporal server in service), and we did it on the primary datastore, which I believe addressed it on both primary and standby.  We had no issues with data corruption or anything of that nature.  I think it just is a pointer to the hosting site so you wouldnt be impacting the data just enforcing the comms pathway between the servers.

[JonathanQuinn]

Once the Data Store is registered to Server, Server does not use the owning system URL to retrieve data. It uses a regular TCP connection, like a connection to any other enterprise geodatabase or database would use. Are you finding that stopping one of the machines causes a problem? What problem are you seeing? Theoretically, if the Data Store was dependent on the URL, then the only time you'd see an issue was if OSI5666 was stopped, because that's the FQDN listed in the URL. If you stop OSI5667, you also see a problem?

[Anonymous User]

Hi Jonathan,

Actually you're right when I stopped OSI5667 IIS because server is webadaptor context all our hosting services are still functional ( I hope all hosted service data resides in relational data store). 

Just for curiosity , why owningsystemurl is different for relational and spatiotemporal as shown above??

What are these owningsytemurl's then??

What are the number of connections as shown below? they are shown as 0 in our staging but still all hosted services are functional. 

BR

[Anonymous User]

Hi Jonathan

Can you please help in answering following

Actually you're right when I stopped OSI5667 IIS because server is webadaptor context all our hosting services are still functional ( I hope all hosted service data resides in relational data store). 

Just for curiosity , why owningsystemurl is different for relational and spatiotemporal as shown above??

What are these owningsytemurl's then??

What are the number of connections as shown below? they are shown as 0 in our staging but still all hosted services are functional. 

BR

[JonathanQuinn]

Do you have any data in the spatiotemporal data store? If so, you can try to stop OSI5666 and you should see those services continue to work because the URL does not impact ArcGIS Servers ability to request data from the ArcGIS Data Store.

I'm not sure why the URLs are different. It could be related to how you registered the Data Store if you registered them separately.

I'm also not familiar with how the number of connections value gets updated. Theoretically, Server should always have a connection to the Data Store. If services are working, it seems like those values may not be updating correctly, but that's not causing a problem.

[VishApte]

Hi Saurabh,

Re Questions

1) What does this url in your load balancer points to https://dnsforportal.company.com:7443/arcgis

Does it point to 7443 port of high available portal machines or it points to 443 port of arcgis webadaptor of portal machines??

In my case, we use 7443 based URL. The load balancer dnsforportal.company.com:7443 redirected to HA portal's port 7443. I short, load balancer's 7443 port to portal server's 7443 port redirect. As Jon mentioned, you could base it on port 443 or any other port of the load balancer as long as redirect configuration on LB uses portal server's 7443 port. From my understanding, privatePortalURL is never used by end-users, it is used by ArcGIS server to communicate to portal (and vice versa). Hence it cannot negotiate 401 challenge as Jon mentioned. 

2) What does this url in your load balancer points to https://portaldmz.company.com/gisportal

Does it point to 7443 port of high available portal machines or it points to 443 port of webadaptor of portal machines??

https://portaldmz.company.com/gisportalwill typically redirect to 443 port of web adaptor if you have it in front of portal. If you don't have web adaptor (best practice says we should), it will point to port 7443 of the portal server. 

Hope this helps.

Cheers,

Vish