Simple ArcGIS Enterprise Deployment Strategy

[JanBenson1]

I am working on a basic install of ArcGIS Enterprise (10.6) to update and replace my ArcGIS Server 10.4.1 application.  Our current setup is a single physical ArcGIS Server on our internal network and a virtual server in the DMZ with the Web Adaptor.  The ArcGIS Enterprise Builder looks like a good solution with everything going on one server, however our security and network staff had concerns as the web adaptors are on our internal network.  My resources are a web application filter (Barracuda) in the DMZ and an IIS Web Server in the DMZ that could host the Web Adaptors.  I see two scenarios.  One uses the Builder to put everything on the internal virtual server and then communicate through the Barracuda in the external DMZ.  If I understand ArcGIS Enterprise correctly, it is possible to communicate through the Barracuda or Web Application Filter to the Web Adaptors.  A secondary question is are the web adaptors necessary or should they be used if we have the Barracuda in the DMZ.  The other scenario puts the two web adaptors on the external IIS Server in the DMZ while Portal, Server, and the data store all reside on the internal network.  What are the advantages and disadvantages of the scenarios?  Will one work better than the other?  Are there better scenarios?  What is the best practice?  I suspect both scenarios will work, but I don’t know why one is better than the other.  Suggestions?

[PaulDavidson1]

Jan:

I can't speak to your WA questions as the DMZ portion is only my to do list.

However, depending on the purpose of your DMZ, it could be that another option would be to leverage ArcGIS Online (AGOL) rather than a DMZ exposure.  I will be watching for your DMZ answers with interest.

I have yet to try the fairly recent Portal Collaboration options.  But I have used AGOL in conjunction with our Portal for exposing some mobile solutions and/or public facing information and maps.

We've found that with Data Interop (or via Python scripts), we can pull things from AGOL back inside easily enough if it's data being updated that we want in house.  Then our editors can QC any potential changes and/or we can just then store related tables and such in Oracle servers and gain the advantage of the nightly snapshots, etc...

If it's just maps we're exposing, then it's just a matter of publishing them to AGOL.

Just a thought...

There is also the Chef alternative to the Enterprise Builder.  Builder is easier for pure cookie cutter.  Chef gives you a provisioned environment in which updates and layout customizations are easier to support.  For example, we had a SSL Cert change on us.  I modified the cookbooks, reran Chef and was done.  I suspect with Builder, I would have to be installing the new Cert on each server component (Portal, AGS, Datastore, etc...)  Chef is more intensive to setup and having an IT type of background, while not required, is probably helpful. 

Best of luck with the project.

[JanBenson1]

Thanks Paul. I can't avoid the DMZ completely without redoing some

applications that are based on services from ArcGIS Server. However, I

could make the Portal completely internal and have new applications use

AGOL. I had not considered collaboration with AGOL as an option. Thanks

for that idea. Without converting the services I will still need a server

web adaptor for the public.

But you raised a question. So, it sounds like you could put everything

internally, then collaborate with AGOL, and share the feature with a public

group in AGOL thereby making it public. And for services, you could share

the service in the originating portal with Everyone as well as with the

group associated with the collaboration workspace. That has to potential

to mitigate exposure from outside the DMZ. The server applications would

still have to update their services URL, but otherwise the application

should work the same. Wow!

So now I guess I need to explore replication and collaboration. Thanks!

Jan Benson

[JonathanQuinn]

Looks like you're moving towards collaboration, but I can comment on a few things:

The Builder won't work for you as it completely sets up the environment, (including federation), and some important URLs, (user/front-end URLs) that you can't easily change will be configured at that point. Everything will point to the machine you ran the Builder on but since you'll likely be expecting different URLs to be configured, thing won't work as well as you'd like.

If you're not interested in IWA, a simple solution is to have your Barracuda reverse proxy in the DMZ which sends the traffic directly to Portal and the GIS Server on 7443 and 6443 within your internal network. You won't need the web adaptors in this case.

You could always set up the traffic to go from Barracuda -> Web Adaptors in IIS -> Portal/Server, but the Web Adaptors are an unnecessary hop.

[JanBenson1]

Do you know if I can I use a third party proxy server (Barracuda) for web tier authentication or does the application require the web adaptor for web tier authentication?  

[JonathanQuinn]

You need the Web Adaptors for web tier authentication, so the traffic would be Barracuda -> Web Adaptors -> Portal

[JanBenson1]

I am starting to feel like a ping pong ball.  i spoke with our Windows specialist who said if access comes from outside of our line office network, then it is considered external and I would have to go through the Barracuda filter and possibly the Web Adaptor.  But, yesterday our network and computer security staff said it was a good idea to go through the AGOL and would provide better risk avoidance.  I will be sitting down with our network, security, and Windows staff when my manager returns to determine the path forward.  I feel like I am back to where I started, but have defined the question better and learned more.  For example, anything coming in from outside our network has to go through the Barracuda.  Yet, system to system communication is still a doable.  In addition our Barracuda filter is brand new.  This means my current ArcGIS Server is outside the new configuration and my knowledge about it will not apply in the new design.  So regardless it sounds like an install of server, data store, and portal on one virtual server.   

  Then we need to decide if the virtual server with portal, server and datastore go on the internal or external network.  If internal then the web adaptors need to go on an external Windows IIS server in the DMZ.  If instead the virtual server is placed in the DMZ, than the Barracuda can act as a reverse proxy server with no need of the Web Adaptors.  In the first scenario using the web adaptors, the entry is Barracuda to web adaptors to internal server.  Is it going to be difficult getting the components communicating correctly?  Is there any advantage or reason other than having the virtual server on the internal network to use the Web Adaptors in addition to the Barracuda reverse proxy or will it just complicate the installation?  With our setup it is not an option to go from Barracuda in the DMZ directly to our internal ArcGIS Server and Portal.  Seems much simpler to place the virtual server in the DMZ and use the Barracuda as the reverse proxy server.  However, placing the virtual server in the DMZ has the down side of a bit more exposure. 

Lastly while testing things out I used the Builder putting everything on the one virtual server.  If I now uninstall Builder will it remove the software and links it created, or should I have the virtual server reset back to its original state as the server is empty other than the Builder install?