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

[JonathanQuinn · Accepted solution]

What version are you using? Depending on your version, there could be an option to enable the HTTP logs for the DR tool. That would help you identify what request is failing, and why. That setting would be in the logback.xml file under the DR tool folder:

<root level="DEBUG">
    <appender-ref ref="file"/>
  </root>
   <!-- Disable the org.apache debug log -->
  <logger name="org.apache" level="DEBUG" />
  <logger name="httpclient" level="DEBUG" />

I think we've improved that error in the latest versions, so it'd be interesting to hear what version you're on.

[DeanMoiler]

Hi Jon,

I'm on 10.7.1 for both environments, and yes, unfortunately the WebGISDR error was a little general to assist with troubleshooting.

The Debug logs helped find whether the error was, which was related to the authentication of one of the Image servers in IIS.

Interestingly, when the geoevent server was having a similar issue, it simply skipped past the issue saying "Failed to back up the ArcGIS Server:"

Unfortunately once it completed it simply deleted the backups and didn't perform the packaging operation, but did package once all of the servers were reverted to correct parameters.

I'm sure that as the tool is improved it will be possible to gather the shared configuration even when one of the servers is not reachable, and to package the export prior to deleting the separate backed up components.

Thankfully though, with the debug logs the needle was removed from the haystack and placed in plain sight.

Thanks Jonathan Quinn

Dean

[DavidColey]

Here's one for you guys- we updated our distributed deployment Enterprise to 11 from 10.9.1, but left the federated side at 10.9.1 as it has to continue to support a couple of ArcMap runtime services (feature access that contains a geometric network) for now.

The webgis dr tool keeps returning the 

‘Cannot get the the Web GIS configuration. Exiting the WebGIS DR utility.’

I was able to put the new log4j2.xml log config file into debug mode:

<!-- Valid levels are debug, info, warn, and error -->
<Logger name="com.esri.arcgis.webgis" level="debug" additivity="false">

and it turns out that something in the tool is truncating the 10.9.1 web adaptor name in the request url:

. . . . 

"privatePortalUrl":https://mydnsname:7443/arcgis ,"portalUrl":https://myf5name/portal ,"serverUrl":https://myf5name/agsfed ,"portalMode":"ARCGIS_PORTAL_FEDERATION","privateHostingServerUrl":https://myf5name/server ,"serverId":"avoF0rF9WMPfyZJp"}}

2022-09-14 13:45:44 DEBUG [ForkJoinPool.commonPool-worker-9] com.esri.arcgis.webgis.service.impl.WebGISDRFrontController - The response returned HTTP status code 404. Requested URL: https://myf5name/agsfe/rest/info 

. . . . 

So basically something is turning my federated web adaptor name 'agsfed' into 'agsfe' in the request.  How could that happen??  

In the meantime, waiting to see what support says for my case . . . 

@JonathanQuinn 

@DeanMoiler 

[JonathanQuinn]

Hm, the DR tool shouldn't even need to make a request to the services URL; it should use the admin URL for everything. I'll take a look.

[DavidColey]

Thanks @JonathanQuinn  if you like, here is the case number I started with support:

#03146363

[JonathanQuinn]

Unfortunately, this is a regression from a change to handle "admin" in the admin URL hostname. It strips any characters in the word "admin" from the end of the URL, which is why your URL that ends in "d" has the "d" stripped. Your services URL is https://myf5name/agsfed; what's the admin URL?

[DavidColey]

I'm not following you.  Are you referring to 'enabling administrative access through the web adaptor'?  In that case it is https://ags3.our_org.net/agsfed/admin/    where ags3.our_org.net is the alias we use at the F5.  agsfed is the web adaptor name.  I can access my admin page using the admin url . . .

[DavidColey]

 . . . But I would never do that, I always use https://my_dns_name:6443/arcgis/admin 

So I don't see how a federated site could ever have an admin url that has a different root from the services url when the required 'enable  admin access through the web adaptor' is enabled so the federation can work. 

[JonathanQuinn]

Sorry, let me clarify; at 10.9.1 and earlier, we had a parsing issue. We check whether the services URL has admin access enabled, and if not, use the admin URL. Ultimately, though, the DR tool constructs the URL to the admin API as https://admin.domain.com/arcgis/admin. It then needed to parse out the "/admin" URL path from the end, but mistakenly stripped the first occurrence. This meant there were requests going to https://.domain.com/arcgis, which of course wouldn't resolve. 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, resulting in https://ags3.our_org.net/agsfe. My question was whether the services URL and Admin URL are both set to https://ags3.our_org.net/agsfed, which makes a workaround more challenging.