Portal privatePortalUrl and Federation Admin Url from Cloud Builder deployment

17606
31
07-27-2017 04:16 PM
FraserHand1
New Contributor III

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

31 Replies
by Anonymous User
Not applicable

Hi Vish,

Thanks for your prompt response.

1) so takeaway for 1st point is we can also use privateportalurl like https://dnsforportal.company.com/arcgis which routes to 7443 port of portal?

2) privateportalurl is only meant for internal administrative purpose by esri software components. we can't use this url for our purpose e.g if I redirect main portal lb url to some maintenance html page so whosoever accessing this portal will be route to maintenance page and if we can use this privateportalurl to do all our maintenance work is not possible? Do you have any better suggestion here other than suggesting information banner and read-only mode because information banner only appears if user is accessing webapps or webmaps using main portal url but it doesn't work if webapp url is bookmarked in browser and access directly. also , information banner doesn't appear on top of operations dashboard either.

3) Is It ok to use federated highly available ArcGIS server serviceurl and administration url same like shown below

redirecting to ( we are not using web adaptor for our hosting highly available layer)

BR

0 Kudos
JTessier
Occasional Contributor II

Excellent, thanks Jonathan!

0 Kudos