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.
"[In this example] the second server reports a failure as the Enterprise is unable to reach or ping it. This server requires maintenance."
If you want to see the Chef parameters, I can post those as well.
Solved! Go to 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]"
]
}
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]"
]
}
That's the beauty of Chef: I'll redeploy really quick and let you know!
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!
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.
Probably a best practice to install Web Adaptor for Server anyway.
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
I have run into the same message since we built our enterprise and are federating and then using as a hosted server.
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?
I'm having a similar issue. You can use the following:
https://ServerName.Domain/PortalName/sharing/rest/portals/0123456789ABCDEF/servers
update the server properties
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.