Understanding ArcGIS Enterprise Components

[mpboyle]

We are looking to roll out a base deployment of ArcGIS Enterprise and we're looking to fully understand all the pieces, and rather than read through a bunch of documentation, I thought I'd try GeoNet first to see if I could explain our current architecture and get some opinions on how we should move forward...

Our current architecture:

• ArcGIS Server Advanced with Image Server role (10.5.1)
• Web Adaptor 10.5.1 installed on reverse proxy configured to use Server listed above
• Do NOT have Portal installed
• Do NOT have Data Store installed
• Use ArcGIS Online for Organizations for managing Web GIS (all web maps, Pro licensing, users, Open Data)
• Use Web AppBuilder Developer Edition for creating apps that are self hosted on local web server

The main piece of ArcGIS Enterprise we are struggling to understand is Portal, and where it fits into our current architecture and workflow.  As mentioned, we currently use AGO for Organizations for managing all our Web GIS 'stuff', while publishing services to our ArcGIS Server.

In order to start fully migrating to Pro, and to be able to publish services using Pro, as I understand it, we need to have Portal installed.  I have always thought of Portal as AGO for Organizations installed locally, so I'm not fully understanding how we would use Portal...?  I think we are pretty pleased with using AGO for Organizations to manage our Web GIS (no maintenance on our end, etc...) but if we have to use Portal to publish with Pro, so be it.

My main questions are:

1. Can we use Portal to pass through our published services to our GIS Server?
2. Do we need to migrate any of our AGO for Organizations user accounts to Portal?
3. What is a federated ArcGIS Server?...and does it provide us any benefit?
4. What is a hosting server?...and does it provide us any benefit?
5. Can the Data Store and Portal be placed on the same server?  I doubt we would publish many hosted services that would use the Data Store.
6. Does Portal need its own Web Adaptor?  If so, can it be placed on the same proxy server as the one we use for our GIS Server?

I understand some of these questions can probably become quite involved, but I'm assuming (perhaps that's bad on my part) we aren't the only organization that has this type of architecture (Server + AGO for Organizations) and are wondering how Portal and the Data Store fit into our future.

Thanks!!!

[JonathanQuinn]

I imagine you'll get a few responses here, but I'll answer what I can. One of the important benefits to using Portal with your GIS Server rather than Online is that you have a central user store that controls access to Portal as well as your federated server and it's services. For example, if you were to create a secure service on your Server and then create a webmap using that service, your users need to sign into ArcGIS Online, and then sign in to reach the service. You need to manage distinct user stores which may get confusing.  If you had Portal and a federated Server, and you create a webmap with that same secure service, once your users sign into the Portal, they're already authenticated with the same credentials to reach the service. You can also take advantage of single sign on and IWA to further reduce the number of user stores. This comes at a cost of maintenance and administration of infrastructure, so it's important to keep that in mind.

Some organizations can't store data within ArcGIS Online, so using an AGOL account isn't an option for them if they want to publish hosted services through Pro, ArcMap, or any other client. They'll set up ArcGIS Enterprise, (which includes Portal, Server, and Data Store), within their own infrastructure.

Below is an overview of some additional information regarding the difference between AGOL and Portal:

Understand the relationship between Portal for ArcGIS and an ArcGIS Online subscription—Portal for A... 

In regards to your questions:

• Can we use Portal to pass through our published services to our GIS Server?

         Yes, you'll set up ArcGIS Enterprise, (Portal, Server, and Data Store), and then you can federate your existing Server so that the security is controlled by Portal.

• Do we need to migrate any of our AGO for Organizations user accounts to Portal?

         Up to you. You're managing content and accounts in separate locations, which could get tricky.

• What is a federated ArcGIS Server?...and does it provide us any benefit?

         A federated server is a server that has passed it's authentication on to Portal so that the Portal user store controls any access to services. The sharing model within Portal will determine who or which groups can access services.

• What is a hosting server?...and does it provide us any benefit?

         A hosting server is a federated server that you have selected to act as the server that will store any data copied to the server during publishing time. It gives you the ability to publish hosted services, run analysis tools, and add file based data directly to the webmap.

• Can the Data Store and Portal be placed on the same server?  I doubt we would publish many hosted services that would use the Data Store.

         Yes, as long as there are enough resources on the machine to effectively run both, (CPU/RAM). Many DBA's will likely tell you to have a dedicated machine for any databases.

• Does Portal need its own Web Adaptor?  If so, can it be placed on the same proxy server as the one we use for our GIS Server?

         Yes, it needs either a web adaptor or your own reverse proxy, (Apache, etc). Yes, it can be on the same server as the WA for your GIS Server. The names have to be unique.

[mpboyle]

Jonathan Quinn‌,

Thanks for your reply, it helps clear things up a bit.  I have a few follow-up questions based on some of your responses:

1. I do like the idea of our Portal and Server using the same identity store.  As you mention, this can sometimes cause confusion for our users, whereas they are using one set of credentials for AGO and another set of credentials for accessing secured services.  On Server, we currently use the built-in store for users and roles, meaning we are pretty flexible in allowing users from inside and outside our organization to view secure services if need be.  If Portal and Server are using the same user store, is that user store allowed to have BOTH integrated enterprise (domain) accounts AND named user accounts?  We like having the ability to use enterprise accounts in AGO for Organizations for users who have a domain account, however, there are some field workers who DO NOT have a domain account and we need the ability to create a named AGO account for them.  Is this type of user store available for Portal as well...and if it is...the same user store gets passed along to our Server if federated, correct?
2. Is there something analogous to Server 'roles' within Portal?  I get that the user store is passed off to Portal, but within Server, using the built-in user store, users belong to roles and roles are what get used when assigning security to a service/folder.  How are services made secure if using a Federated Server with Portal?
3. How is a hosting server different from the Data Store?...or are they one in the same?  I thought the point of the Data Store is to give users the ability to create hosted feature services, run analysis tools, drag and drop files that contain geographic content, etc...  Is a hosting server configured somewhere within Portal?...or during install?  Is a hosting server necessary?
4. How are user accounts in Portal and AGO for Organizations tracked?  For example, say we have 100 named user accounts available for AGO for Organizations.  I already have an existing user account in AGO using my enterprise account.  If I add my enterprise account to Portal, does that count as 2 accounts within our 100 user pool, even though it's the same credentials?
5. Along the same lines as the question above, how are Pro licenses managed?  Currently, all our Pro licenses are managed through AGO.  When we install Portal, I'm assuming you can manage Pro licenses through there as well, just like you can in AGO, correct?  Would we need to 'de-activate' / 'disable' a Pro license on AGO and re-configure Pro to look at Portal for licensing?
6. Do you HAVE to federate your Server with Portal in order to have published services pass through Portal and be published directly to your Server?  Or, does federating your Server with Portal simply mean the user store of Portal is passed to your Server?

[JonathanQuinn]

1) If Portal and Server are using the same user store, is that user store allowed to have BOTH integrated enterprise (domain) accounts AND named user accounts?  We like having the ability to use enterprise accounts in AGO for Organizations for users who have a domain account, however, there are some field workers who DO NOT have a domain account and we need the ability to create a named AGO account for them.  Is this type of user store available for Portal as well...and if it is...the same user store gets passed along to our Server if federated, correct?

         If you use SAML/ADFS, you can have both enterprise accounts as well as built-in users within your Portal. It sounds like you've already done that within ArcGIS Online. The experience in Portal should be identical to AGO.

2) Is there something analogous to Server 'roles' within Portal?  I get that the user store is passed off to Portal, but within Server, using the built-in user store, users belong to roles and roles are what get used when assigning security to a service/folder.  How are services made secure if using a Federated Server with Portal?

         Access to services is controlled by the sharing settings within Portal. If I, as a publisher, publish a service, it's automatically added as an item within My Content. By default, the service is not shared with everyone, meaning only me and Administrators within the Portal can reach the service. I can share that service with a group or groups and only members of that group can reach the service. If I share the service with the organization, anyone who is a named user within the Portal can reach the service. If I share the service with everyone, anyone who can access the REST endpoint can reach the service. I realize the link is specific to ArcMap, but it describes the sharing settings.

         Share a service with your ArcGIS organization using ArcMap—Documentation | ArcGIS Enterpris... 

         Your users will be assigned roles as well. Some may be Viewers, some may be Publishers, a select few will be Administrators, and you can create custom roles.

3) How is a hosting server different from the Data Store?...or are they one in the same?  I thought the point of the Data Store is to give users the ability to create hosted feature services, run analysis tools, drag and drop files that contain geographic content, etc...  Is a hosting server configured somewhere within Portal?...or during install?  Is a hosting server necessary?

        A hosting server can only be set if you've registered the relational Data Store with the Server and you've federated that Server with Portal. The ArcGIS Data Store is really just storing the data used for the hosted services, they're still running on the hosting server, (which again, is a federated server, but set as the hosting server). The hosting server is set when you federate your server with Portal. Then, you'll have the option of setting it as the hosting server. Here are some key points:

• A federated server is a server that you've added to the Portal that will use the Portals security store.
• A hosting server is a federated server that you've selected to be a hosting server through My Organization
• The relational ArcGIS Data Store has to be registered to the federated server to set that federated server as the hosting server

      A hosting server is only necessary if you plan to do any of those things listed.

4)  How are user accounts in Portal and AGO for Organizations tracked?  For example, say we have 100 named user accounts available for AGO for Organizations.  I already have an existing user account in AGO using my enterprise account.  If I add my enterprise account to Portal, does that count as 2 accounts within our 100 user pool, even though it's the same credentials?

         ArcGIS Online and Portal use separate identity stores, therefore I believe the same user will count for 2 named users. I suggest you discuss that with your account manager.

5)  Along the same lines as the question above, how are Pro licenses managed?  Currently, all our Pro licenses are managed through AGO.  When we install Portal, I'm assuming you can manage Pro licenses through there as well, just like you can in AGO, correct?  Would we need to 'de-activate' / 'disable' a Pro license on AGO and re-configure Pro to look at Portal for licensing?

         Licensing isn't really my strong suite, but I believe that's correct. You'll need to move those licenses to Portal. Your account manager may be able to clarify.

6) Do you HAVE to federate your Server with Portal in order to have published services pass through Portal and be published directly to your Server?  Or, does federating your Server with Portal simply mean the user store of Portal is passed to your Server?

         Federating is the easiest way to pass credentials between Portal and Server. Another option, though, is to add the service to your My Content and embed credentials within the item. Anyone that has access to the item will be able to reach the service as the credentials are embedded with the item.

         Connect to secure services—Portal for ArcGIS (10.6) | ArcGIS Enterprise 

[RebeccaStrauch__GISP]

Excellent Q&A post.  Good, clearly stated questions and clear answers.  Now for a users point of view, my opinions only.

I think that the federated Enterprise, with Pro are the way we all will be pushed in the not too distant future.  Many of the workflows that are being developed and presented at the Developer Summit, the UC, etc are expecting this. Many of the app (mobiles, studios, dashboards) want a named user from a portal (whether AGOL or Portal). And the fact that Pro will not publish to ArcGIS Server direct all seems to have the writing on the wall.

However, that does not mean that you have to federate right away.  For a number of reasons (including being in the middle of 10.2.x to 10.5.1 upgrade and limited time), we are not federating yet.  But I get many questions as to why.  The upgrade is the main reason at this time, but I can see that this will be complete, and the topic will come up again.

Talking to a few other (mid-size) organizations last week at the Dev Summit, it seems that I am not the only one that has a bit of hesitation to make the switch. (my guess is it is a one way switch...once federated, it probably would be a major project to reverse....backup first??) 

For me, the main reason I do not want to federate is that Portal then takes over control of the security of ArcGIS Server services.  We have some secure services that are accessed thru a proxy for public JavaScript web pages.  Looking at this thread Generate token for Federated ArcGIS Server through webadaptor   my concerns of getting this to work the way we want (or have it now) are at least partially confirmed.  That doesn't mean that it isn't possible, but more research and testing will need to be done.

We also have not had Portal up and running before, but especially with the unlimited Level 1 (read-only) named user accounts, that does at least resolve the issue of not being able to afford to provide intern sites.  So, we'll see how that all plays out.

With all that said, as Jonathon pointed out, you might already be half way there with your federation with AGOL.  So, then you have to weigh the need for extra features of federation vs the things you may lose (i.e. AGS managed security... and maybe service organization?).  I tried to get a clear answer last week at the dev summit as to what the process is, how hard, and if it will mess up setting up things as we have it, then federating at a later date "in-place".  I was not able to get any clear answer.

So, this may not help in your decision, but it is another perspective.