ArcGIS Server services URL (...) cannot be validated against (...)

[MichaelSchoelen]

The issue:

• When validating the federation of our GIS servers, we are presented with the message: 

  Portal Administrator Directory

  Servers:

  Server Id: lrDg7sfm4UFAKE8W Status: success Messages ArcGIS Server services URL 'https://server01.website.com/server' cannot be validated against 'https://server01.website.com/server/rest/info'. If the service URL is a proxy URL verify it is accessible to clients. ArcGIS Server administration URL 'https://server01.website.com:6443/arcgis' is accessible. ArcGIS Server 'https://server01.website.com:6443/arcgis' version is compatible with Portal for ArcGIS.

The background:

• This issue is identical to one in the docs here. Unfortunately, the docs just say:

  "[In this example] the second server reports a failure as the Enterprise is unable to reach or ping it. This server requires maintenance."

• We don't have a Web Adaptor installed for the servers, so server01.website.com/server/... does not exist.
• My team recently deployed ArcGIS Enterprise (using Chef and Esri cookbook v3.1.0). All enterprise installs were "successful", including federation--there were no errors that halted any of the processes.
• We took the default for a few variables, including WebContextURL, if that would make a difference
• We are currently working in a test environment with no certificates. So we didn't specify any of the certificate parameters when running Chef-- the docs say that it will generate a self signed certificate. 

My Question: 

• Regardless of Chef, what might cause this error message? (Certificates, URL specifications...) If I know the root, I can hopefully define the correct variable.

If you want to see the Chef parameters, I can post those as well.

[RandallWilliams · Accepted solution]

If you didn't use the web adaptor recipe, then my guess is that the issue is in the federation recipe - like you mentioned, the web context URL portion. The failing parameter is supplied when manually federating.

Curious to see what happens if you change that parm to "web_context_url": https://domain.com:6443/arcgis,

{
  "arcgis": {
    "server": {
      "domain_name": "domain.com",
      "private_url": "https://domain.com:6443/arcgis",
      "web_context_url": "https://domain.com/server",
      "admin_username": "admin",
      "admin_password": "changeit",
      "is_hosting": true
    },
    "portal": {
      "domain_name": "domain.com",
      "wa_url": "https://domain.com/portal",
      "admin_username": "admin",
      "admin_password": "changeit"
    }
  },
  "run_list": [
    "recipe[arcgis-enterprise::federation]"
  ]
}

[MichaelSchoelen]

That's the beauty of Chef: I'll redeploy really quick and let you know!

[MichaelSchoelen]

It looks like just changing the web_context_url didn't trick portal (or there some deeper process going on in Chef that makes a Web Adaptor a requirement for proper federation). So I'm installing a Web Adaptor as part of the run list, and I'll let you know how that goes.

randall_williams-esristaff, I take that back. I forgot to specify the port. That worked! Thanks!

[RandallWilliams]

Interesting. While I know the web adaptor is a core aspect of the product, I didn't realize that it was a hard coded requirement for the Server side. The Portal side, sure.

[MichaelSchoelen]

Probably a best practice to install Web Adaptor for Server anyway.

[Jelle_Stu_PR]

Hi @RandallWilliams ,

4 years after the original post, and I am running into the same issue with an AGE 10.9.1 deployment. I am not using recipes a ssuggested in the comments of this pst, but manual installation of all the components on different machines. The server properties all seem correct. Any suggestions what else I could do?

Thanks in advance,

Jelle Stuurman

[BugPie]

I have run into the same message since we built our enterprise and are federating and then using as a hosted server. 

• ArcGIS Server services URL 'https://server01.website.com/server' cannot be validated against 'https://server01.website.com/server/rest/info'. If the service URL is a proxy URL verify it is accessible to clients.

It would seem that I made a simple typo when configuring enterprise last week and the ArcGIS Server services URL  is missing one letter. 

Is there an easy solution to update this url from the portaladmin UI or some other admin routine? 

[JohnBrockwell]

I'm having a similar issue. You can use the following:

https://ServerName.Domain/PortalName/sharing/rest/portals/0123456789ABCDEF/servers

update the server properties

[JaleelAbubaker]

I had the same issue.

Problem:

The link https://<yourdomain.com>/server  (residing on WEB ADAPTER or Load Balancer) was not accessible from PORTAL machine and SERVER machine. Both these machine in my case was on private subnet without internet and thus couldn't access the public dns name (https://<yourdomain.com>)

Solution:

I had to map the public domain name to its private ipaddress in the machines host file (C:\Windows\System32\drivers\etc\hosts).  e.g. yourdomain.com 10.0.2.206    So whenever the Portal or Server machine refers to yourdoamin.com it is mapped to the private ip and reaches the right place through internal network.