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.
Yeah that suggestion seems wrong... Would https://LBURL.domain.com/portal url even resolve? That url seems invlalid.
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.
Yes that URL will direct to https://LBURL.domain.com/portal/home/ which is the same as I get with using :7443/arcgis.
I gotcha, our system doesn't have that redirect in place and that url would fail for sure.
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
Thanks for the confirmation. I will make the change and see what happens.
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.
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.
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
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.
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.
Thanks, will do.
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.
do you have ADFS in the mix?
While we have ADFS for other uses I do not believe it is in the mix for our GIS system.
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.
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.
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#
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
