privatePortalURL Value

[BrianLeroux]

I am try to fix a portal validation issue where the will occasionally fail and other times succeed. It was suggested to update theprivatePortalURL from https://LoadBalanceURL.domain.com:7443/arcgis to https://LoadBalanceURL.domain.com/portal. All documentation i found shows to use :7443 so I am not sure the suggestion otherwise is accurate and our system was initially configured by ESRI. 

@ChristopherPawlyszyn Any insight on this?

This is an HA system running on 2 VM servers. Each server has Server, Portal, and web adaptors(arcgis/portal) installed. We use an F5 load balancer. 

[DanielBrumm1]

Yeah that suggestion seems wrong... Would https://LBURL.domain.com/portal url even resolve?   That url seems invlalid. 

[BrianLeroux]

Yes that URL will direct to https://LBURL.domain.com/portal/home/ which is the same as I get with using :7443/arcgis.

[DanielBrumm1]

I gotcha, our system doesn't have that redirect in place and that url would fail for sure. 

[DanielBrumm1]

I was thinking that you may have an issue with one of your VM's and depending on what one the LB sends traffic to it will either validate or it wont. A simple test would be to stop one of the VM's and try and validate. Then stop the otherone and see if it will validate. May help narrow down the issue. 

[ReeseFacendini]

When configuring an HA Portal site, both the webContextURL / privatePortalURL should both be set to https://lb.example.com/portal. With a single node of Portal, the privatePortalURL can either be ignored or set to be https://machine.name.local:7443

[BrianLeroux]

Thanks for the confirmation. I will make the change and see what happens.

[BrianLeroux]

Well setting the privatePortalURL  to https://lb.example.com/portal was a failure. I could no longer sign in to arcgis/rest/services or arcgis/admin using my windows account. rest services just went into an infinite loop of trying to authenticate and admin stated the credentials were invalid. I was able to get back in under the PSA account and put it back to 7333:arcgis and i am able to log in again. 

[ChristopherPawlyszyn]

If you have web-tier authentication enabled on the WebContextURL it cannot be used for the privatePortalURL. For architectures where the backend servers are able to access the WebContextURL for Portal for ArcGIS, it's easy to match the privatePortalURL to that value to avoid the need to provision a separate listener on the LB.

The privatePortalURL for an HA site does need to be load balanced so in the case of a single Portal for ArcGIS machine going down the federated ArcGIS Server sites/machines still have an administrative connection to the remaining Portal for ArcGIS machine.

The example, https://lb.example.com/portal, is a stub URL used to build the full URL by the underlying components, so would be correct with the caveat mentioned above.

[BrianLeroux]

Understood on the stub URL. We are using the correct load balance URL here within our domain.

For ArcGIS server we have the webcontextURL set to https://LB.mydomain.com/arcgis which does have web-tier authentication enabled. In the security config we have Portal authentication tier set with the portal properties set to portalUrl = https://LB.mydomain.com/portal and webcontextURL = https://LB.mydomain.com:7443/arcgis. As mentioned changing that webcontextURL to match the portalURL broke authentication so we reverted back.

For portal we have the webcontextURL set to https://LB.mydomain.com/portal which does have web-tier authentication enabled. The privatePortalURL is set to https://LB.mydomain.com:7443/arcgis