WebContextURL or Web Adapter

[Mehretab]

Recently I Installed an ArcGIS Enterprise. I have done it before and I use to install portal and configure it with WA. Then  we use our proxy server to forward request.

But during recent 10.8.1 installation I got the following Note:

"If you use the ArcGIS Web Adaptor, you need to install and configure it for use with Portal for ArcGIS. To get started, see About the ArcGIS Web Adaptor.

Once you've installed the Web Adaptor and configured it for use, you’ll access your portal using the Web Adaptor’s URL. For example: https://pvil-arcgisportal.bafg.de/webadaptorname/home.

If you are not using the Web Adaptor, configure the Web Context URL."

Previously I have been using WA and as the same time set WebContextURL property.

1. My question is, do we need to set WebContextURL property if we configure portal with WA?

2. Are they complementary or a substitute for one another? If so which approach is better?

Thanks,

Mehretab

[JonSwoveland]

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.

[Scott_Tansley]

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.

[ChristopherPawlyszyn · Accepted 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."

From: https://enterprise.arcgis.com/en/web-adaptor/latest/install/iis/configure-arcgis-web-adaptor-portal....

[JYI]

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.