ArcGIS Enterprise 10.6.1- Webgisdr : Failed to backup the ArcGIS Server : Failed to generate a token to access ArcGIS Server from Portal

[NicolasGIS]

Hello,

I am trying to make a backup of our ArcGIS Enterprise configuration using webgisdr tool but it is failing to backup the hosting server (one portal, one federated server and 2 datastores work fine). I have the following error message:

Failed to back up the ArcGIS Server:

Url: https://gisags.enterprise.com/arcgis.
Failed to generate a token to access ArcGIS Server from Portal.

Setting webgisdr logging to debug, there is the following error:

{"code":500,"messages":["Error while processing request. Internal error. JSON response not set."],"status":"error"}

Setting the faulty ArcGIS Server log to DEBUG, I see the same error:

"java.lang.Exception: Error while processing request. Internal error. JSON response not set" from "Admin" source.

On portal log, I get the following errors:

"Generate Server Token failed, serverId not found "
Server URL can't be validated for granting server token 'https://gisags01.enterprise.com:6443/arcgis'

Also, export arcgis server site manually from admin interface works fine:

https://gisags.enterprise.com:6443/arcgis/admin/exportSite 

I don't know what is wrong with the configuration but when I validate the servers from portal administration interface both my hosting server and federated server are valid (green check mark).

So what is webgisdr trying to do ? What is the request that fails ? Where should I look for  ?

Thanks,

Nicolas

EDIT:

What I suspect:

I configured an alias on the hosting ArcGIS Server ("gisags") while the actual hostname is "gisags01". I configured an SSL certificate on ArcGIS Server with both domain registered so both https://gisags.enterprise.com:6443/arcgis and https://gisags01.enterprise.com:6443/arcgis url are valid from an SSL point of view.

On Portal for arcgis, it is the alias which is registered:

https://gisags.enterprise.com:6443/arcgis

and the validation from portaladmin works.

But the portal log mentioned above makes me think that webgisdr found out the hostname and use it to generate its token which works but then it tries to find the id of the ArcGIS server from the portaladmin based on the server name and it does not find because its name is with the alias  ("Server URL can't be validated for granting server token 'https://gisags01.enterprise.com:6443/arcgis'").

Description of the server from the portaladmin REST interface (https://myportal.enterprise.com:7443/arcgis/portaladmin/federation/servers/foobarid)

Name: gisags.enterprise.com:6443
Id: foobarid
Url: https://gisags.enterprise.com/arcgis
Role: HOSTING_SERVER
Admin Url: https://gisags.enterprise.com:6443/arcgis

The hostname "gisags01" is not mentioned anywhere, so I believe it is why portal logged:

"Generate Server Token failed, serverId not found.
Server URL can't be validated for granting server token 'https://gisags01.enterprise.com:6443/arcgis'"

I am only guessing...

One may wonder, why did I use an alias: in the documentation for a highly available portal, it is written;

"Note that when you federate a highly available ArcGIS Server site with Portal for ArcGIS, set Administration URL to a URL that the portal can use to communicate with all servers in the site, even when one of them is unavailable, such as a load balancer URL." (lien). I thought it would be more flexible to use an alias if later I want to add a load balancer or add another arcgis server to the site and kill the previous host for example.

Is it a misconfiguration or rather a bug from the webgisdr ?

Jonathan Quinn, I believe you might have the answer ?!

Thanks for your help,

[BillBott]

WebContextUrl . 

When you use a DNS alias or a reverse proxy the WebContextUrl property is used see: Using a reverse proxy server with ArcGIS Server—ArcGIS Server Administration (Windows) | ArcGIS Ente... 

Then ArcGIS Server will respond with packets that appear to originate from the alias, otherwise it uses the local machine name. 

[NicolasGIS]

Thanks for the reply.

I just tried and unfortunately, it did not solve the issue.

Also, when I make request to the arcgis server using the alias (and without adding this property), ArcGIS Server does respond to it so I am not sure it is exactly the same.

Finally, the documentation mentionned "If you're using a reverse proxy server and the URL to your site does not end with the default string /arcgis (all lowercase), you should also set the ArcGIS Server WebContextURL property" so it seems like it is more about the context and my arcgis server site does end with "/arcgis" so I believe that is why it is currently working without this property set.

Thanks anyway !

[BillBott]

Hi Nicolas, did you re-federate after you set the property and bounced arcgis server? Portal will need to know the server is returning a different FQND.

1. Unfederate the server from portal in its existing state (no webcontext)
2. Login into server, set web context url. Server restarts
3. Clear browser cache (I also restart portal here too, but you probably don't have to)
4. Refederate the server in portal using the webadaptor address that everyone is publishing too (for both user/admin)

[HarroldSompotan]

Hello all,

This is actually a known Bug: 

BUG-000116145: Having ArcGIS Web Adaptor admin access disabled within an Highly Available ArcGIS Ent...

BUG-000116145: Having ArcGIS Web Adaptor admin access disabled with.. 

*Workaround so far is to "Enable Admin Access" on the Web Adaptor for Arcgis Server or change the PORTAL_ADMIN_URL within the webgisdr.properties file to use https://portalFQDN:7443/arcgis.

[BillBott]

He never mentioned web adaptor though? I assumed he did, but was only assuming...

[HarroldSompotan]

No worries Bill, this one took us some time to figure out that the call it was making during the Webgisdr process.

Since exporting Arcgis Server alone via the server-admin end point will not behave the same if you have Web Adaptor enabled or disabled. Hope that makes sense. 

[NicolasGIS]

Many thanks Harrold Sompotan ! It is exactly my scenario. I do use web adaptors (one for portal and one for each arcgis server) with admin access disabled. Apologize not having mentionned it.

[NicolasGIS]

Hello Harrold Sompotan‌, 

According to the bug you mentioned it is supposed to be fixed at 10.7 but I still get the error on this version.

Maybe what I am doing is slightly different : I want to use an alias for ArcGIS Server Admin Url so that I can later on, replace the alias with a load balancer as stated in the documentation :

"Note that when you federate a highly available ArcGIS Server site with Portal for ArcGIS, set Administration URL to a URL that the portal can use to communicate with all servers in the site, even when one of them is unavailable, such as a load balancer URL."

I successfully federated my ArcGIS servers with portal for ArcGIS using their machine alias. 

So in settings tab/Servers of Portal I have the following:

https://myalias1.company.com:6443

https://myalias2.company.com:6443 

Everything works fine and in the Portal share API, there is no mention of the ArcGIS Server hostname:

/sharing/rest/portals/0123456789ABCDEF/servers

Server Name	Server URL	Is Hosted	Admin URL
myalias1.company.com:6443	https://myalias1.company.com/arcgis	false	https://myalias1.company.com:6443/arcgis
myalias2.company.com:6443	https://myalias2.company.com/arcgis	true	https://myalias2.company.com:6443/arcgis

Also, I successfully configured the 2 webadaptors using the machine alias.

But when exporting a webgisdr backup, I have the same error:

"Failed to generate a token to access ArcGIS Server from Portal"

If I activate administrativ access on the 2 webadaptors then the backup is successful.

Checking the "webgis-config.json" file exported by webgisdr, I can see that the admin URL of the ArcGIS Server is set with the hostname value:

"adminURL":"https://myhostname1.company.com:6443/arcgis/admin"

Do you know where does it get this info from ? Or maybe you have better option to suggest ?

Thanks,

[JonathanQuinn]

You'll be able to update the admin URL of a federation after you actually federate. Not sure if aliases/traffic resolution is the problem here but just wanted to point that out. Can you provide a network diagram so we can understand your architecture? What URL are you using for the PORTAL_ADMIN_URL?