Configuring (and re-configuring) an ArcGIS Server Web Adapter's URL?

[JonSwoveland]

Hello all, 

This is something that has been a mystery to me for a while and has led to complications with several ArcGIS Enterprise deployments I have led.  There are two parts to my question:

1. How does ArcGIS Web Adapter "know" what it's own URL is?
2. Is there a way to reconfigure this URL?

I should clarify, the above questions are specific to a Web Adapter (WA from here on) registered with a Federated ArcGIS Server.

Re the first question, when installing and registering WA, there's no way to specify the hostname/FQHN to the WA.  I assume the registration routine looks at the IIS settings and decides for itself what to use, but  I've run into the situation where, after federating an ArcGIS Server, the WA's URL (as registered in Portal) is not as desired. Most commonly, this is a case of the URL using only the machine hostname instead of the FQHN.  

Re the second question, there does not seem to be any way, short of unfederating and refederating, to reconfigure a federated ArcGIS Server WA's URL in Portal.  I need to move an internal ArcGIS Server's WA to a public-facing DMZ and reconfigure it to use a publically available FQHN.  Seems crazy that I would have to unfederate / refederate the ArcGIS Server to simply reconfigure a setting in Portal.  If this server had many hosted feature services, those all become orphaned when unfederating the server. 

Thanks for any insight!

[Brian_Wilson]

There are JSON files on your ArcGIS Server. On MY server it is in C:\arcgisserver\config-store\ and there is a security\ folder and name of the file is security-config.json

The file has the URLS and secrets embedded in it so I won't paste the whole thing in here but it's readable.

I note there is a LOCK file which means someone (WA or Server?) has it open right now, so you'd need to shut everything down if you were going to edit it. Otherwise chances are either it will refuse to write changes to the file or you will find that when the service shuts down it rewrites the file wiping out your changes.

If you edit this file (may Esri forgive you) then it might just break unless you are doing something really minor like updating a server name because it changed in DNS. My guess is that it might not work because the secret won't work anymore but I am a daring soul and would just try it anyway. You may be more cautitous.

In my case all I had to know was which of the machine's names I had used. We have internal names and public names. I could not tell what was needed and it killed my upgrade because Esri support is closed on weekends.

I think this is the most stupid thing, they should fill in the form FOR you on upgrades, not make you guess and guess and not tell you what you are doing wrong (The message is basically "ERROR: you entered the URL OR the username OR the password wrong OR maybe all three you keep guessing good luck.") This killed a SATURDAY upgrade for me because I could not get past that stage and I had to back out and send in a support request the following Monday. So I am still peeved. You should only have to know the PASSWORD. On the second try I knew I had the correct URL and I was able to work out the admin username and password. Hopefully this message saves you a couple Saturdays for something like gardening or bicycling.

The Portal configurations appear to be stored in a secret PostgreSQL server, which seems like a monumentally bad engineering decision but no one asked my opinion on that. 😉 

[Brian_Wilson]

"Seems crazy that I would have to unfederate / refederate the ArcGIS Server to simply reconfigure a setting in Portal."

Actually this seems typical to me for commercial software.

Commercial software: "a setting is wrong, uninstall everything, reinstall everything, what? the setting is still wrong, uninstall everything again, and oh server is now offline good thing it's the weekend, try one more time then call support on Monday. OH LOOK it's already Monday"

Open source would be "edit a text file, restart, it's broken, fix typo, restart again, read the docs, edit one more time, restart again." AND also you can stand up a complete test environment and a complete developer environment and do your all your testing on Monday and have 0 downtime.

BTW the phrase "did you remember to federate your server?" is a running joke around here.

Happy Friday!

[Brian_Wilson]

Perhaps more relevant for YOU would be the config-store folder called "web-adaptors" which contains more JSON files,

I see one with its ID in its name and has a "machineIP" settings and a "webAdaptorURL" setting.

If you are trying to move the URL that the web adaptor listens on for incoming requests that might be the one you need to change. I guess you'd change it here and in IIS as well? Good luck!

[JonSwoveland]

Thank-you for your technical (and emotional) support, Brain!  I'll poke around those config files you mentioned.  I'm tempted to setup a test environment (oh, dang, I don't think I can because I don't have any available dev licenses for ArcGIS Server).  

Sorry to bring Esri licensing up on a Friday (or any day, for that matter) 😉

[JonathanQuinn · Accepted solution]

The WA URL is set based on the URL you used to access the registration page if you go through the browser, or the /w argument if configuring via the command line. If you have an alias and the wrong URL is used when registering, you don't really need to update it because the WA can still proxy requests to the server it's registered to even if it's accessed through a URL that wasn't used in the registration. That's not the same for Portal, though.

Once you federate, the URL you used for the services URL is what is stored in items in the portal. You can update the URL without unfederating/refederating, but you'll need to update references to the URL across all service items in the portal.

[JonSwoveland]

Thank you, Jonathan, for the detailed explanation!

I suspected the WA url was stored in each item's url. Too bad those aren't resolved at runtime.

Cheers,

Jon