nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Encuentra más publicaciones etiquetadas con

Accepted answers

All comments

Dan_Brumm

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

Dan_Brumm

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.

BrianLeroux

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

Dan_Brumm

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

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

mgress12

We are experiencing similar behavior after implementing a privatePortalURL using the format: https://LoadBalanceURL.domain.com:7443/arcgis

This is a 10.9.1 HA deployment with two portal servers, two federated servers, and one web adaptor with IWA. F5 is the load balancer.

Federated servers will validate successfully off and on. We are also seeing this with publishing hosted feature layers and deleting items. The inconsistences came with setting the privatePortalURL.

We've tried turning off one portal machine to see if that clears up the issue but no luck so far. No blocks encountered in the firewall that line up with the errors we see in Portal.

Error messages include:

Could not connect to the ArcGIS component at URL 'https://LoadBalanceURL.domain.com:7443/arcgis.' The ArcGIS component on that machine may not be running or the machine may not be reachable at this time.Error: Connection reset.

We've opened a support case to work through the issue.

BrianLeroux

Your system configuration sounds nearly identical to mine. I also have a case open and they are doing a bit of research now. please keep me posted if you make any progress in resolving your issues and i will do the same. thanks.

PS for some strange reason when i right click copy your second link in your post above and copy to a browser it shows me your actually URL you must have copied in and edited. Probably not a huge deal but you may want to edit that out.

mgress12

Thanks, will do.

mgress12

So far we haven't been able to identify the cause of the connection resets between our F5 load balancer and Portal. We can see the resets through Wireshark captures but haven't yet found a solution.

As an alternative, we have had luck using the Application Request Routing module in IIS to balance the requests to our two Portal machines.

BillFox

do you have ADFS in the mix?

BrianLeroux

While we have ADFS for other uses I do not believe it is in the mix for our GIS system.

BrianLeroux

Thanks for the update. We are still working with ESRI on the issue and no solid leads yet. We are looking into firewall and traffic routing soon but I expect to see what you are seeing.

BillFox

I believe setting the private portal url and web context url is required to be set at the time of installation only and any adjustments after the build will have glitches or flop with any already created content.

BillFox

for example: all case sensitive

in your portal admin page,

home > system > properties

the two settings must be the same:

WebContextURL : https://<public facing url for portal>/<portal's webadaptorname>

privatePortalURL: https://<public facing url for portal>/<portal's webadaptorname>

and then in arcgis server's home > security > config

these two should be the same value as those two

portalUrl

privatePoralUrl

Then the two should be set to similar for arcgis server's web adaptor via the public url / reverse proxy / dns alias

serverUrl : https://<public facing url for portal>/<arcgis server's webadaptor name>

privateHostingServerUrl : https://<public facing url for portal>/<arcgis server's webadaptor name>

@ChristopherPawlyszyn https://community.esri.com/t5/arcgis-enterprise-questions/webcontexturl-or-web-adapter/td-p/1073142

https://enterprise.arcgis.com/en/portal/11.1/administer/windows/configure-existing-enterprise-deployment-for-ha.htm#

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.