Select to view content in your preferred language

Portal privatePortalUrl and Federation Admin Url from Cloud Builder deployment

20923
31
07-27-2017 04:16 PM
FraserHand1
Esri Contributor

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
JonathanQuinn
Esri Notable Contributor

Hm, interesting observation.  I would be surprised if a client would need access to those internal URLs; like you, I imagine Portal would facilitate that communication.  I'll do some testing and reply back.

0 Kudos
FraserHand1
Esri Contributor

Hi Jon,

Rereading the online doc Federate an ArcGIS Server site with your portal—Portal for ArcGIS (10.5.x) | ArcGIS Enterprise 

Administration URL—The URL used for accessing ArcGIS Server when performing administrative operations on the internal network, for example, http://gisserver.domain.com:6080/arcgis. If your organization requires HTTPS for all communication (such as when using Integrated Windows Authentication), use https://gisserver.domain.com:6443/arcgis.

It definitely says internal network so interested to how that IP leaks. Wondering if it may have something to do with certs not being right?

Ta

Fraser

0 Kudos
JonathanQuinn
Esri Notable Contributor

It doesn't have anything to do with certificates, but more so what information Pro or other clients request while publishing.  Currently, it seems like that information is required, as you're able publish once those requests fail, but it's not a good user experience.  I'm bringing this up to the teams here to discuss on how handle those situations.

0 Kudos
SebastianStey
Emerging Contributor

Hi!

Publishing Web-Scenes (3D) I see the same behaviour as described above for Web-Layers ("Copy All Data" + "Feature").

What I see in 10.6:

Publishing a Web-Scene (3D) [works]

  • ArcGIS Pro tries to contact the hosting server via the administration URL several times
  • it fail each time (as the administration URL is not reachable from that client machine)
  • finally, publishing succeeds even though the client machine can't reach the hosting server's administration URL

So far, it looks like described above.
However, publishing a Web-Map (2D) looks different.

Publishing a Web-Map (2D) [fails]

  • ArcGIS Pro tries to contact the hosting server via the administration URL several times
  • it fail each time (as the administration URL is not reachable from that client machine)
  • finally, publishing fails - it will only work if administration URL is reachable from the client machine

Can we have ArcGIS Pro ignore that administration URL?


While publishing, we encounter one additional problem. When Portal WebAdaptor in IIS is configured to use Integrated Windows Authentication (to have single sign on):

  • publishing a Web-Map works (if administration URL is reachable from client machine)
  • publishing a Web-Scene fails. It works as soon as I turn off Integrated Windows Authentication

Is there a way to publish Web-Scenes while Integrated Windows Authentication is switchend on?

0 Kudos
JTessier
Frequent Contributor

Any more word on this Private Portal Url and what it is and isnt used for?

0 Kudos
JonathanQuinn
Esri Notable Contributor

It's used for internal communication from Server to Portal. You'd set this in the event that the Server can't reach the Portal through the machine name, (so you'll use a URL that is accessible), or you'll use it when you're setting up a highly available Portal. If you're setting up an HA portal, you want to make sure that if one of the portal machines goes down, the federated Server machines can still reach the other portal machine.

0 Kudos
JTessier
Frequent Contributor

Thanks Jonathan, we are in an HA configuration and thus will be setting that value.  So is the workflow in HA?:

1) AGS tries a machine name of the primary Portal server first. 

2) If that doesn't respond it uses this Private Portal Url to try a second time (to get to the HA server)? 

Or if this value exists, AGS always uses it to communicate to a Portal in an HA config?

Next, how critical is it for this from the doc: (Step 8 - http://enterprise.arcgis.com/en/portal/10.5/administer/windows/configuring-a-highly-available-portal...)

Note:

Do not set the X-Forwarded-Host header for this URL.

Finally, per this thread, does Pro or desktop use this url too?

0 Kudos
JonathanQuinn
Esri Notable Contributor

The communication goes through the URL configured for the privatePortalURL and it's the responsibility of the component creating the URL, (load balancer, for example), to check the health of the machines it's load balancing requests to make sure the request reaches a machine that is up.

So, if it isn't set prior to federating, it uses one of the portal machines. If that machine goes down, then your federation is broken.

If it is set prior to federatng, then Server will communicate to the Portal through the URL, and the URL will either load balance the requests to the two portals or only send the request to the active portal if one is down.

It's important as the presence of the X-Forwarded-Host header tells portal that the request should be sent back using host and context of the WebContextURL. If the privatePortalURL is the same as the WebContextURL, you won't see a problem. If it's different, though, you'll see issues.

JTessier
Frequent Contributor

Also, the doc specifically mentions this step for a hosted server, but I would now think based on your details above that it would apply to a non-hosted federated site as well, thus my next question below (came before this comment and replied incorrectly to full item).

0 Kudos