Why Is There No Hosting Server Available in Portal?

[Mark_Hotz]

I'm in the process of implementing ArcGIS Data Store, and a part of that process involves first designating a hosting server.  I have just upgraded everything on our Sandbox to version 10.6.1 (ArcGIS Enterprise and ArcGIS Desktop).  I am going through the steps on our isolated sandbox server first in case I blow something up.  When I get to the window in Portal for ArcGIS (Organization ► Edit Settings ► Servers), the drop-down under "Hosting Server" is empty.  However, when I review the same drop-down under Hosting Server in our production environment, an option is available:

The Sandbox is supposed to be an exact copy of what is in Production...so how could there be a discrepancy?  How do I ensure that there is indeed a Hosting Server option here?  From where is Portal retrieving this Hosting Server path?

Thanks

[JonathanQuinn]

I'm guessing that the federated Server in your sandbox environment either doesn't have a relational ArcGIS Data Store registered (anymore, perhaps), or it's not validating. Take a look at the data stores first through Manager or the Admin API and make sure that you can see the ArcGIS Data Store registered and it validates.

[Mark_Hotz]

Johnathan:

Thanks for the pointer...that is probably what I'm doing wrong.  I'm still doing things out of sequence it seems.  I will work on the Data Store configuration and registration first.  I started to do this a week ago but quickly discovered that I was doing this with version 10.6.1, when everything else is 10.6...and I was not permitted to configure until the versions were synced.  Now that I have everything upgraded in our isolated sandbox environment I should be able to configure and then register Data Store.  I'll keep you posted.

Thanks again

[AaronDorsey1]

Were you able to resolve this? I have the site federated in Portal, Server Manger shows the Data Store as the Managed Database (and validates), and the Data Store config status shows that Relational and Tile Cache are configured, but nothing shows up under hosting server in Portal (same as your sandbox screen).

[JonathanQuinn]

If you have verified that the Data Store is registered and validates, it may be that Portal doesn't trust the certificate used for the admin URL during federation. Check the logs and if you see an error that indicates a certification path isn't trusted, import the certificate used for the admin URL into Portal:

Configuring the portal to trust certificates from your certifying authority—Portal for ArcGIS (10.6)... 

[AaronDorsey1]

Well, I missed the part about updating the SSL cert for the Data Store. So I ran updatesslcertificate with no errors. I see agsdatastore.ks in the DataStore/etc/ssl directory. (Is that the only way to tell that an SSL cert is being used?)

No dice.

Note that I already have the same cert (wildcard) setup on IIS and Portal with no issues (that I can see).  BUT I'm pretty sure I imported it in Portal using Import Existing Server Cert.  Does that matter?

Thanks for your help.

[JonathanQuinn]

The certificate for Data Store is only applicable for the 2443 endpoint, which is only used when configuring Data Store via the UI or when the DR tool is backing up and restoring the Data Store.

If there's an issue with a certificate, it's the certificate assigned to the admin URL that you used in federation. If that's a wildcard certificate then that's definitely going to be problematic until you configure the Portal to trust the certificate.

Monitor the network traffic when loading the Edit Settings page. A request to the Admin API for Server will fail and that's the reason why the drop down is greyed out. The home application can't get a valid response when making a request to determine if there are any registered Data Stores.

[AaronDorsey1]

Well, tldr; I rdp'd into the server and I get no errors and it shows up under hosting server.

BUT, on my local machine:

When I go to Portal > Organization > Edit Settings, I see a 403 on:

https://maps/arcgis/sharing/proxy?https://maps:6443/arcgis/admin/data/findItems?managed=true&f=json&token=<token>

When I remove https://maps/arcgis/sharing/proxy? the findItems request works (from my desktop) and I get a response with the data store info, etc.

Portal log: "Invalid SSL certificate found. PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target"

Under :7443/arcgis/portaladmin/security/sslCertificates:

I see the cert I uploaded under "Import Existing Server Cert" (which is the one I see under /sslCertificates/update)

And I see the cert I uploaded under "Import Root or Intermediate", how can I tell if it is actually using it?

Also, there are the default certs portal and samlcert.

Or is it a token issue?

[JonathanQuinn]

When the request goes through Portals proxy, (https://portal.domain.com/arcgis/sharing/proxy), the Portal machine itself is making the request, not your browser. So if your machine trusts the certificate for the URL it's proxying to, then it'll go through. If Portal doesn't trust the certificate, then it'll fail as you're seeing.

If you ran the Import Root or Intermediate operation and provided the certificate for the admin URL, then you should be good to go. Portal will restart and then that request should work without a problem. Import Existing Server Certificate is not the same operation as Import Root or Intermediate, so if you used the former to import the cert, you'll still need to run the latter.

[AaronDorsey1]

OK, so back when I installed Portal I only used Import Existing (using a .pfx cert with a password which came from IIS). Then under Update, I changed the name to that existing cert.  All was good, no errors.

Today, I used Import Root or Intermediate with the (domain/wildcard) .crt file. It loaded, restarted, and is listed under SSL Certificates.

I just reexported the pfx from IIS (where the wildcard cert is installed) and reloaded it in portal admin and then reloaded it in Data Store.  Same 403.

Since the proxy request target URL is the manager (6443), should I reload those certs? If so, importRoot or importExisting?

EDIT: I ran importRoot with the crt and importExisting with the pfx... same error.  Also, I have a cname dns record for maps.domain.com for this server, but the actual machine name is used under the admin settings...