ArcGIS Server federated with Portal installed with Builder: problem with FQDN in URLs.

2642
11
Jump to solution
01-17-2018 07:38 AM
AlessandroValra
Occasional Contributor III

I have installed ArcGIS Enterprise 10.5.1 with the automatic procedure of the Builder.

Everything went fine, all green checks.

I came up with having two working web adaptors, one for portal, one for server.

Everything is working when used from within the server where everything was installed.

The problem is the web adaptor took the FQDN of the server machine, so I was not able to sue it from another pc.

So I uninstalled and reinstalled both webadaptor pointing to a domain which is accessible from outside the server (and for which I have a SSL certificate for HTTPS connection).

I was then able to access portal and server from outside.

However, when I tried to logging in, a page with the Portal for ArcGIS layoutshowed up, but instead of the iframe to insert my credentials, I got a 404 error page.

Everything seems caused by the fact that during login, the authorization goes through the Portal and the URL somehow is still set to the FQDN, causing the request to time out (becasue, again, it is not recognized from outside the server).

I have changed the tier from ARCGIS_PORTAL to GIS_SERVER in the server administratrion page.

I was then able to login but then then I had issues with validating the federated server.

I would need to have the server federated with the portal because I would need to publish services to it from ArcGIS Pro.

How can I overcome the problem of the FQDN/EXTERNAL DOMAIN?

Should I give up using the Builder and do a clean install from scratch by soing thins manually?

Also, if you want to see what I have already been trying, please refer to this other thread.

Thanks

0 Kudos
1 Solution

Accepted Solutions
PhilipMcNeilly
Esri Contributor

To add to what Jon said, the Enterprise Builder was designed for the simplest install possible.  The added complexity of using an alias for the machine is not something the Enterprise Builder can automatically detect.  

When installing the components of Enterprise separately, they too automatically detect the hostname of the machine, but you have the option, prior to federation, to set a webcontextURL.  This property effectively tells the components what to call themselves(i.e. an alias).  Then you can federate using the alias URLs.  The enterprise builder federates for you, so your federation URLs will be the internal FQDNs and not the external alias.  This will prevent your Portal items from being usable via the alias. To add to this, the reason you are unable to login to Portal is the same; a webcontextURL has not been set for Portal.  

Your best options are what Jon mentioned.  To install and configure the components separately using your alias URLs where appropriate, or you can try changing the etc/hosts file which would effectively force Enterprise Builder to believe that the machine name is the alias thereby using the alias URLs in the setup of the components.  

View solution in original post

11 Replies
JonathanQuinn
Esri Frequent Contributor

Considering you have aliases/multiple hostnames for the machine in your environment, I wouldn't use the ArcGIS Enterprise Builder. Actually, the ideal scenario is you'd have the web adaptors within your DMZ and the Portal, Server, and Data Store components on internal machines. The reverse proxy section of the documentation describes that a bit, (different context, same principle):

Use a reverse proxy server with Portal for ArcGIS—Portal for ArcGIS (10.6) | ArcGIS Enterprise

A reverse proxy server is a computer that is deployed within a perimeter network (also known as a demilitarized zone [DMZ] or screened subnet) that handles requests from the Internet and forwards them to the machines in your internal network. The forwarding of requests on behalf of the reverse proxy server masks the identity of the machines behind your organization's firewall, thus protecting internal machines from being attacked directly by Internet users. Additional security functions can be implemented in the reverse proxy server to further protect your internal network from outside users.

The web adaptor is essentially a reverse proxy, just simplified. If you do want everything on the machine that's exposed to the internet, you can try to set an etc/hosts entry on the machine so that the internal IP address is set to the external FQDN you want to use. That will tell the AEB to use that hostname for all components and URLs.

AlessandroValra
Occasional Contributor III

Hi Jonathan Quinn‌.

My scenario is probably the simplest one and the one which is supposed to suite the requirements of the Builder.

Reasons why you would not use the ArcGIS Enterprise Builder are any of the following:

  • Install the software components across multiple machines

So I imagined that having "all the components" means "including Web Adaptor/s".

However, in the very same bullet point I also read:

Reasons why you would not use the ArcGIS Enterprise Builder are any of the following:

(...)

  • Define the name of the ArcGIS Web Adaptor (IIS)

So, that's probably where my issues came from. The Web Adaptor installed with the builder automatically configures with the FQDN, which is not accessible from outside the LAN, which I think is a normal case (?).

But my SSL certificate is working only for the external domain (which I also suppose is normal).

The only way I could point the web adators to this external domain with the certificate is (as I said) by uninstalling them and reinstalling them by pointing to the external domain.

Everything seemed fine except that Portal is still pointing to the FQDN when it comes to log in, thus preventing me to use my Enterprise components from outside (and thus I won't be able (e.g.) to publish services...).

The web adaptor is essentially a reverse proxy, just simplified. If you do want everything on the machine that's exposed to the internet, you can try to set an etc/hosts entry on the machine so that the internal IP address is set to the external FQDN you want to use. That will tell the AEB to use that hostname for all components and URLs.

Do you know if this is actually working? Can you please give more details on how to do it or a link maybe?

Thanks in advance!

AlessandroValra
Occasional Contributor III

Just to clarify a bit.

It is not the first time I am performing a ArcGIS Enterprise install.

It is however the third time I am using the builder and failning in doing that.

Generally, the customers ask for a simple install: one server machine, everything on it.

They normally then want to access this server machine from client other machines to (e.g.) publish their gis servers with ArcMap or Pro. This is done most typically by adding a connection to the server machine with publisher credentials, or - with the advent of Portal for ArcGIS - by logging into their Portal.

The problem is: in order to publish to the Server, they need to Share from ArcGIS Pro to Portal for ArcGIS a feature service (or whatever other type of service), having the ArcGIS Server federated with the Portal and being it also the hosting server for the GIS services. And so they need to LOG IN.

Here comes the pain. Using the external address to access the portal (or the server) is fine as long as you don't have to log in.

I remember during manual install that when the Portal site is created you can specify a URL, which for our customers is generally the external accessible domain. The builder seems to set this automatically to the FQDN of the server machine server itself, thus redirecting any attempt of login to this rather than the external domain.

Am I totally wrong? Is there a way to access (LOG IN) the Portal or Server from outside after installing arcGIS Eneterprise with the builder?

Please, I really hope someone would shed a light on this since searching the web I saw many geonet's "presumably answered" questions but no certainties.

0 Kudos
PhilipMcNeilly
Esri Contributor

To add to what Jon said, the Enterprise Builder was designed for the simplest install possible.  The added complexity of using an alias for the machine is not something the Enterprise Builder can automatically detect.  

When installing the components of Enterprise separately, they too automatically detect the hostname of the machine, but you have the option, prior to federation, to set a webcontextURL.  This property effectively tells the components what to call themselves(i.e. an alias).  Then you can federate using the alias URLs.  The enterprise builder federates for you, so your federation URLs will be the internal FQDNs and not the external alias.  This will prevent your Portal items from being usable via the alias. To add to this, the reason you are unable to login to Portal is the same; a webcontextURL has not been set for Portal.  

Your best options are what Jon mentioned.  To install and configure the components separately using your alias URLs where appropriate, or you can try changing the etc/hosts file which would effectively force Enterprise Builder to believe that the machine name is the alias thereby using the alias URLs in the setup of the components.  

View solution in original post

AlessandroValra
Occasional Contributor III

or you can try changing the etc/hosts file which would effectively force Enterprise Builder to believe that the machine name is the alias thereby using the alias URLs in the setup of the components.

This is interesting.

Thanks both for this precious information.

I think I will try this way or avoid using Builder in future.

I think this is so important to include and highlight in the documentation before going crazy trying to figure out what can be done to fix the problems (= much more time spent for installing with an automated tool rather than doing it manually).

0 Kudos
PhilipMcNeilly
Esri Contributor

Adding functionality for including an alias in the Enterprise Builder deployment could make for a great idea on the ideas page(https://community.esri.com/community/arcgis-ideas)

0 Kudos
AlessandroValra
Occasional Contributor III

Did it!

https://community.esri.com/ideas/14619 

Please vote it if you like.

Thanks.

0 Kudos
AndrewValenski__IT_
Occasional Contributor III

Phillip is a good man.

ThomasPuthusserry
New Contributor III

Hi Alessandro / and other experts

I have come across your question after publishing mine. Basically in the same situation and struggling for a week.

Simply: have you figured out how to sort this? I managed to change the alias for the portal, but still unable to do this for the server. Any help / steps involved would be appreciated.

Thanks Thomas

0 Kudos