Cannot get the WebGIS Configuration

[DeanMoiler]

Hi Portal Experts,

I have a staging environment that is having problems running the WebGISDR utility and so cannot perform backups successfully:

     Cannot get the web GIS configuration.

I have two environments with the following configuration (this is the production env and is working successfully):

The production environment is working fine as in the above screenshot.

I have been running the backups via a scheduled task and running with a service account with admin privileges on the portals.

The config file is like this:

I've successfully managed to export a site/backup for each and federation validates successfully.

Has anyone come across anything similar?

Thanks!

Dean

[DavidColey]

Ok - clearly this seems like a pretty big issue that hopefully can be addressed in an Enterprise patch - or at least addressed at release 11.1,

I don't know how anyone could address this without creating a new federated site that somehow has different services and admin url roots.  I would not know how to do that . . . 

In the meantime, what I have done is to just set up a robocopy to run each day to copy out the portal content folder and then run seperate site backups on the hosting and federated sites if any new data/layers/objects are published.  The datastore is set to it's default every-four-days automated backups, but I may now change that to daily.

Any other suggestions are welcome!

Thanks for looking into this Jon -

[JonathanQuinn]

@DavidColey if https://ags3.our_org.net/agsfed is your services URL and has administrative access enabled and https://my_dns_name:6443/arcgis is your admin URL, try to disable administrative access on the web adaptor.

[DavidColey]

looks like our messages got crossed.  No - the the services url and the admin url currently are the same.  Both are coming through the web adaptor.

This is because I have administrative access enabled on the web adaptor - per the federation instructions - so things like Collector, Field Maps, Quick Capture will work correctly.

[JonathanQuinn]

To sort out what to do next, it seems like your services URL is https://ags3.our_org.net/agsfed, and your admin URL is https://my_dns_name:6443/arcgis. It also seems like you have administrative access enabled on the Web Adaptor for https://ags3.our_org.net/agsfed. If this is the case, then the DR tool will use that URL for a few requests and result in the parsing error I mentioned above. If administrative access is not enabled for the Web Adaptor on https://ags3.our_org.net/agsfed , then it will solely use https://my_dns_name:6443/arcgis. The last character in https://my_dns_name:6443/arcgis is not in the list of "a","d","m","i","n", so it will not truncate the URL incorrectly.

[DavidColey]

So you are suggesting to simply update my web adaptor settings by disabling administrative access through the web adaptor and in that way the admin access for the federated site will always use the internal dns name:

This is what my portal admin page at

https://gis5.ou_org.net:7443/arcgis/portaladmin/federation/servers/avo......PfyZJp 

reads now for our federated site:

Server: Federated

Name: Federated
Id: avoF0r....p
Url: https://ags3.our_org.net/agsfed
Role: FEDERATED_SERVER
Admin Url: https://gis3.our_org.net:6443/arcgis
Server function:

First - Won't that break things like field maps?  All the documentation has always said for things like field maps and collector to function properly dmin access through the web adaptor has to be enabled.  

Second - Has anyone else ever done this?  It seems very risky to do on a production environment like ours.

[JonathanQuinn]

While I don't work on those apps, I'm not aware of any client requirement for administrative access to be enabled on the Web Adaptor. Can you point me to the doc that says that? Do you have a staging environment that uses similar constructs for URLs?

Is your question has any ever disabled admin access on the web adaptor, or has anyone disabled admin access on a live production environment? If it's the former, then yes, it's a common practice especially in more secure environments to restrict who can reach the administrative APIs and endpoints for Server. Our security team has put together recommendations for load balancers, reverse proxies, and WAFs to disable access to administrative APIs as well. If it's the latter, then also yes; if there are workflows or operations that rely on accessing the Admin APIs or Manager through the services URL, those workflows may be impacted.

[DavidColey]

When you say "While I don't work on those apps, I'm not aware of any client requirement for administrative access to be enabled on the Web Adaptor. Can you point me to the doc that says that?" 

Not at the moment. It may be a legacy thing from earlier (like 10.6) releases. 

I think for our org the main reason we set up admin access through the web adaptor was so that we could access Server Manager while not on our internal network by going through the F5 and the portal user store in case of emergencies -  like hurricanes - and I was not on network or could not be on network but still need access to Server Manager.

I don't have a staging environment and don't want to try something like this on the fly.  You said earlier that:

"We addressed this in 11.0, but used an incorrect method, which looks for any character in the URL that matches any character in "admin". In your case, https://ags3.our_org.net/agsfed/admin/ all of the bolded characters are characters in "admin", therefore got stripped from the URL"

Well, I say that this is a bug and needs to be addressed - because it has only shown up at this very latest release.  Don't get me wrong - I really appreciate your insight here.

As always, I poured through the issues addressed 

https://downloads.esri.com/support/downloads/other_/110-IssuesAddressedList_07192022.pdf

and all of the 'what's new' and saw nothing about this, even in the 'Disaster Recovery' section of the document.

I'm just not sure I can change the admin access - and if something goes wrong and re-enable it, that when I do re-enable that the site will still validate, what will the impact to Monitor be, etc etc.

Thanks again - I'll have to give this more thought and will post back

[JonathanQuinn]

Well, I say that this is a bug and needs to be addressed - because it has only shown up at this very latest release.

Absolutely. Have the support analyst log a bug. They can contact me directly if they have any questions.

As always, I poured through the issues addressed 

https://downloads.esri.com/support/downloads/other_/110-IssuesAddressedList_07192022.pdf

and all of the 'what's new' and saw nothing about this, even in the 'Disaster Recovery' section of the document.

The original issue was found internally and an official bug wasn't created, which is why it wasn't added to the Issues Addressed list.

[DavidColey]

Thanks Jon.  Yes when I speak with Sukumar today I certainly will.  Let me ask you this:

Do you think it is safe to go into the web adaptor, disable admin access through the web adaptor, run the DR tool, and then re-enable admin access through the web adaptor after the tool completes?

My main concern is stability in how the fed site is registered with the portal, plus just the overall tricky-ness with any web adaptor configs/re-configs . . . 

[JonathanQuinn]

Yes, that should work. You can either:

1. Run the Configure Web Adaptor Utility to re-register the web adaptor without admin access, then run the backup, then again with admin access. If the web adaptor is not on the same machine as where you're running the DR tool, then you'll need to run it remotely via Powershell and the Invoke-Command function (https://learn.microsoft.com/en-us/powershell/scripting/learn/remoting/running-remote-commands?view=p...)
2. Use an API which allows you to update the setting from anywhere that the API is accessible from (https://server.domain.com:6443/arcgis/admin/system/webadaptors/<web adaptor id>/update)
   
   https://developers.arcgis.com/rest/enterprise-administration/server/updatewebadaptor.htm

I'll keep a lookout for the bug.