wml2013
commented
4 months ago I have a similar issue for a Highly Available ArcGIS Enterprise deployment where the 'PrivatePortalURL' is recommended. This setting is used to access the Portal from any federated Servers and can either have the same value as the 'WebContextURL' or use an internal load balancer with the admin ports (6443 and 7443) allowed through.
Example: "WebContextURL"="https://myserver.mydomain.mycom/portal" "PrivatePortalURL"="https://myinternalservername.myinternaldomain:6443/arcgis"
The issue is that the PrivatePortalURL ALWAYS includes the Admin port (6443) when my requirement is to have it the same as the WebContextURL as it is simpler and the customer does not want a second (internal load balancer) in place.
Example of what we need:
"WebContextURL"="https://myserver.mydomain.mycom/portal" "PrivatePortalURL"="https://myserver.mydomain.mycom/portal"
It is unclear to us how the DSC creates the value of the PrivatePortalURL. We've experimented with including the internalLoadBalancer and other tweaks but to no avail. It always includes the admin port number for the PrivatePortalURL. Due to this, the Federation steps in the PowerShell DSC module does not complete and crashes out. We have to then manually change the PrivatePortalURL via portal admin page and can then manually federate the servers. This manual process makes the process not fully automated, so am keen to see what settings controls the creation of the PrivatePortalURL and the population of the parameter and how we can change it.
Architecture:
Azure Application Gateway x2 All in one ArcGIS Enterprise 11.1 Base deployments.
Module 4.2
cameronkroeker
Hi guys,
I have installed ArcGIS Enterprise on a single machine using this DSC library. I don't have a web adaptor as I'm using Azure App Gateway to route requests to the backend targets.
I have also set "AdminAccessEnabled" to true at a global level as I want to allow administrative access from the public endpoint. I don't want to use an internal load balancer to round-robin requests to the internal machines using port 6443 as it is not required.
The federation of the hosting server, even though I have "AdminAccessEnabled" set to true and have set the ExternalLoadBalancer URL, still uses the machine name of the hosting server, port 6443 and the web context arcgis. This same behavior happens when specialized GIS servers are federated with Portal for ArcGIS. Of course, I can use the InternalLoadBalancer to set up an HA endpoint but it overcomplicates the deployment when it does not need to be.
Maybe this is more of a preference thing, but in my opinion, if "AdminAccessEnabled" is set to true and an external load balancer URL has been supplied, the Admin Service URL used for the federation should match the Services URL.
Note that with self-signed certificates, the federation would fail because the certificate needs to be loaded to app gateway http settings first. Once loaded, the install would have to be re-run so the federation bit completes.
The way this works today, it forces me to unfederate, and federate manually. Also, note that when using a web adaptor and admin access is enabled, this is what happens. The Admin Service URL matches the Services URL. This behavior should be consistent even if App Gateway is used.
Also, as an enhancement, there should be a smarter way to automatically register the self-signed certificate automatically with app gateway to allow the end to end process to work in one go.
Hope this makes sense.
Cheers, Jose
Community Note
Module Version
Affected Resource(s)
Configuration Files
Expected Behavior
Federation Admin Services URL matches Services URL
Actual Behavior
Federation Admin Services URL uses the machine name of the server being federated with port 6443 and web context set to arcgis. We can use an internal load balancer sure, but it adds additional complexity where is not required in my view.
Steps to Reproduce
Configure App Gateway, and run an install of ArcGIS Enterprise and confirm that the hosting server is federated using port 6443 for the Admin Service URL.
Important Factoids
References