Solved! Go to Solution.
The way I look at it is that the WebContextURL entry is the ultimate way of defining the public DNS alias and context for a site. It would override whatever URL was used during the web adaptor configuration.
When you register a web adaptor, the URL you use to access the configuration page (for Portal for ArcGIS specifically) is inherited as the Portal's URL. This is great for internal environments when using an FQDN or A/CNAME record to access the machine hosting the web adaptor, but when you throw a reverse proxy in front of that machine then you are no longer able to use the correct URL to access the web adaptor configuration page (it'll warn the user to access the page from the machine hosting the web adaptor). This is where the WebContextURL comes in handy and should be set prior to the creation of any content or the federation of any sites.
Setting the WebContextURL won't have any adverse effects on a site using a web adaptor, and is required when implementing multiple web adaptors since the same registration URL wouldn't be possible from two machines to keep the consistency of a single DNS for the site. If deciding to not utilize the web adaptors, it's important to keep the additional headers and rewrites in mind as well.
See step 2:
"Open the configuration page in a web browser using an HTTPS URL such as https://webadaptorhost.domain.com/webadaptorname/webadaptor. If a DNS alias will be used with the portal, the Web Adaptor should be configured over the DNS alias instead, using a URL such as https://<dnsalias.domain.com>/<webadaptorname>/webadaptor."
Hi Mehretab,
The short answer, to the best of my knowledge, is yes. The WebContextURL property must be set if the url to the portal's native endpoint (i.e. https:<portal host>:7443) is different than that of the Web Adaptor.
AFAIK, this must be set regardless of using the Web Adapter or other proxy (or both). I believe one of the functions of the WebContextURL property is to specify the allowed referrer url for authentication purposes (so Portal will trust referrers from the Web Adapator/proxy). It would be really nice if Esri made it possible to specify multiple referrers, as they do for web apps.
I'd be interested to see Esri respond to your question, perhaps they can provide more... context.
I always set the webcontexturl,
no matter if I’m using a WA or a third party load balancer. It makes my configurations complete!
when we start to create content, the URLS for web maps, some services and apps all have internal hooks to that URL and it can’t be changed easily. So adding the webcontextUrl is a belt and braces way of ensuring we have a robust implementation and that if someone puts another cname onto the web server, people can’t start using that instead.
in summary. You can’t go wrong by adding it. You can go wrong if you don’t.
The way I look at it is that the WebContextURL entry is the ultimate way of defining the public DNS alias and context for a site. It would override whatever URL was used during the web adaptor configuration.
When you register a web adaptor, the URL you use to access the configuration page (for Portal for ArcGIS specifically) is inherited as the Portal's URL. This is great for internal environments when using an FQDN or A/CNAME record to access the machine hosting the web adaptor, but when you throw a reverse proxy in front of that machine then you are no longer able to use the correct URL to access the web adaptor configuration page (it'll warn the user to access the page from the machine hosting the web adaptor). This is where the WebContextURL comes in handy and should be set prior to the creation of any content or the federation of any sites.
Setting the WebContextURL won't have any adverse effects on a site using a web adaptor, and is required when implementing multiple web adaptors since the same registration URL wouldn't be possible from two machines to keep the consistency of a single DNS for the site. If deciding to not utilize the web adaptors, it's important to keep the additional headers and rewrites in mind as well.
See step 2:
"Open the configuration page in a web browser using an HTTPS URL such as https://webadaptorhost.domain.com/webadaptorname/webadaptor. If a DNS alias will be used with the portal, the Web Adaptor should be configured over the DNS alias instead, using a URL such as https://<dnsalias.domain.com>/<webadaptorname>/webadaptor."
Hi Chris. It sounds like that WebContextUrl can be set from portaladmin, and once it is set, the value will be kept. However, in the 10.9.1 version I just installed, either using DSC script or manually deploy, the changed value cannot be kept and always is changed back to the web adaptor value by the system itself. Any insights on who trigger this reversion? Due to the web adaptor url, I can only access the new portal 10.9.1 inside Azure VMs, which is incorrect. We only have web adaptor, portal, arcgis server and data store on 4 Azure VMs, no reverse proxy. I posted the question here too. Thanks.