Hello @CraigRussell
- Ok, so referring to the documentation for using a reverse proxy with ArcGIS Server, it states that if you aren't using web adaptor (i.e. you are directly communicating with ArcGIS Server over port 6443) then you need to use /arcgis as your web context to avoid URL redirection issues. This is somewhat mentioned in the Portal documentation as well, but it doesn't explicitly discuss direct access over port 7443.
It is possible to have a name other than /arcgis and works; we have environments where use an F5, an Apache or an IBM WAS where the paths are different (/portal & /server) and use a reverse proxy, we don't always use the /arcgis; since 10.8.1 in Azure with the cloud builder contexts can be other than /arcgis. The key is in the configuration and being able to rewrite the output / input.
- Technically while you federated using /portal and /server web adaptors, you've uninstalled them - they are no longer part of the deployment.
There is a snapshot of the server and it can always be reconfigured; the change was first made in testing so it is not critical for normal operation.
I think you have three options here:
- Re-install the web adaptors on your DMZ IIS machine and use them instead of URL Rewrite; or
Yes, this is possible but it is what we want to avoid.
- Install the portal and server web adaptors on the ArcGIS Enterprise machine, which should allow you to then use the /portal and /server context in the DMZ reverse proxy rules; or
Start over (unfederate Portal and Server), but:
Do not install the web adaptors as part of your deployment; and
Its needed keep the environments separated, in other scenarios we could have the Web Adpators in the IIS and put them in the server with Portal, or in some other and make a NAT in the router to be exposed; but in this situation the internal servers can not be exposed in this way, its required use the DMZ.
- Set up you reverse proxy/URL rewrite rules using the /arcgis context for both Portal and Server before federating
We could use /arcgis to make it work, the long short story is that this required un-federate and then federate again, then having to do some work with web maps, viewers etc. this is preferred to avoid.
- Regarding option #1, you mentioned this in a previous post:
"...in production they are now using Web Adaptors but for a special situation it is required to be done through IIS."
- What is the situation which requires you to use IIS without the Web Adaptors?
By organization rules, they have chosen not to have third-party applications on this servers in the DMZ, they do it directly with the IIS; this is due to a security breach with a similar application that caused them inconveniences.
- While I think that you should be able to set up using the second option if you really want to, it is clearly not as well documented as using the Web Adaptors, and supportability might be an issue.
The reverse proxy settings I've found on forums / youtube works partially, I've been editing and testing, some work with Portal fine, but then I have issues with ArcGIS Server for publishing etc. I haven't found one that works fine. I haven't found specific information in forums, articles or Salesforce either.
- One other thing - ensure that your URL Rewrite reverse proxy rule isn't doing SSL offloading. This is not supported in ArcGIS Enterprise.
Yes, we are not using/doing SSL offloading.
Regards.