Our web environment is currently running a single machine install of ArcGIS Server 10.4.1 Advanced. This meets all of our current needs (mobile editing with Collector, hosting map / feature services, adding map / feature services as items within AGO for end users, creating caches for custom base maps, using services within web map for WAB, etc...).
We have started looking at upgrading our web environment to 10.5.1 and I'm a little confused about ArcGIS Enterprise. I've read a base deployment of ArcGIS Enterprise consists of a combination of 3 products:
We have never seen a need for Portal for ArcGIS as we have always used AGO for Organizations as a means of publishing web maps via our services created through our own ArcGIS Server. With AGO for Organizations we have no additional software or hardware to maintain, and we have no reason to install Portal for ArcGIS, which, the only compelling reason I've ever heard anyone from Esri say to go with Portal over AGO for Organizations is if your data needs to be housed on-premise and behind a firewall.
So...my first question is: do we really need to install Portal for ArcGIS? Is this a requirement at 10.5.1?...or does it come along for the ride starting at 10.5.1 for those who wish to deploy it? Having worked a bit with ArcGIS Pro 2.0 there is no way to publish a service to ArcGIS Server. So, is our current workflow going to become obsolete once ArcGIS Pro is mainstream and ArcMap is only in maintenance mode? Our current workflow is to use ArcMap to publish map / feature services, add those to a web map in AGO for Organizations, and consume the web map in either AGO, Collector, Web AppBuilder, etc...
I'm very curious what the optimum workflow is from Esri's point of view for publishing services through ArcGIS Pro. You are able to share a web map to a portal, share a feature layer to a portal, but what exactly does that mean? There's no way we want to publish hosted feature layers if we have Server. Perhaps this is different if you are dealing with Portal, but to me, a hosted feature layer is a static snapshot of your data which is living in the cloud, and not referencing production or replicated data.
My second question is: what exactly is the data store used for? Is it a necessary component? We have registered folders and databases with ArcGIS Server so we don't have to copy data to the server. In this blog, it mentions that 10.5.1 will be the last release to support anything other than the da.... So...can services no longer reference a file gdb, enterprise gdb? Does a data store somehow reference production / replicated data sources to ensure 'live' data is being served by the services?
I'd appreciate any comments from the Esri Server team, or others that have a far better understanding than I on ArcGIS Enterprise, on how each component of ArcGIS Enterprise is meant to be used, seeing as how our current system only uses ArcGIS Server along with AGO for Organizations and meets our needs wonderfully.
What is ArcGIS Enterprise?—Documentation | ArcGIS Enterprise I'm sure you have seen this link, but including for others.
From a administrator/user's standpoint...
So...my first question is: do we really need to install Portal for ArcGIS? Is this a requirement at 10.5.1?...or does it come along for the ride starting at 10.5.1 for those who wish to deploy it?
No, No, and Yes. I would say that if you are getting everything you need from AGOL, and don't have any services that need to be secured behind you firewall, stick with that. server can be installed and run pretty much the same as your previous version. There may be some other major advantages or needs in the future (i.e. Working with Pro, federatin if that is what you need, etc), but in my opinion, those are not necessities or requirements at this point.
My second question is: what exactly is the data store used for? Is it a necessary component?
From what I understand, it is required for Portal and is used when hosting services in Portal, and I think, if Federated with Server, this is where the GP results are stored. I was told you can also take advantage of the DataStore even without Portal, by registering it with ArcGIS Server, but I have not tested that myself yet. It sounds like there are other benefits to using the DataStore too.
in our shop, we are looking at using Portal in an unfederated environment so we can have some apps that are totally behind our firewall that can access our secure services with a proxy. We will use AGOL for public services. It all comes down to where we can use a proxy, vs. where we will need named users. We are still in the process of testing this ourselves, so it is all theory at this point. Fwiw.
Have you tried publishing services with ArcGIS Pro and Enterprise 10.5.1? I'm curious where Pro fits in with publishing services at 10.5.1. I don't see any tool within the Share tab to publish directly to ArcGIS Server. You can publish a web map or feature layer to a portal, but since we use AGO, the portal we sign into for ArcGIS Pro is arcgis.com. So...if I want to share a web layer or web map, it seems to be sharing directly to arcgis.com ... which would create a hosted feature layer.
I'm very curious what the workflow is ... or if there even is one ... on how to publish a service to ArcGIS Server using Pro.
If I understand correctly, you can publish to both Portal AND Server with Pro, but must use Pro if publishing to Portal. (Going from meme more, not in the office).
there are tools for ArcGIS Server in Pro An overview of the Server toolbox—Help | ArcGIS Desktop But I have not tried them yet.
The key thing that I would point out (even though you haven't asked this particular question), is if you federate with Portal, it basically takes over the administrator of Server. For some, that may make the administration easier, but for our shop and the named user situation, at this time it would not (always subject to change). Things are changing on the software side too, as they are starting to open up Portal-to-Portal and Portal-to-AGOL "collaboration". I'm not 100% sure how this will work with named users, that is, if one (organization level) named user will eventually work across all, or if you still need a slot in each...that may be a turning point in my thinking and acceptance anyway. All my opinion.
Btw, the previous Image Server extension (if you have it in 10.4.x) can not be installed as a stand alone software...still licensed thru a core ArcGIS Server however.
I did take a look at the Server toolbox within Pro. The Upload Service Definition tool seems to be the way to publish to ArcGIS Server (if I'm reading the screenshots below correctly). You have to create a service definition (.sd) file first and then publish the .sd file. We normally publish straight from ArcMap and do not create a service definition, so it would seem we would need to do an extra step or two.
I haven't asked ... and maybe I should ... what exactly does federating Server with Portal do? What are the benefits?
Re: federating. Take look at the q and a https://community.esri.com/thread/199383-portal-federated-ags-and-secured-services for some info. I do think the benefits v's the disadvantages depend on you situation for licensing, IT, administration, etc., and some specifics are best discussed with your customer rep/local distributor. Personally, we don't currently have the number of named users we might need to have federation...again, all subject to change as nothing is truely static.
the up side of federation Portal with Server (long term) if it works for you is that you will be able to take better advantage of the technology moving forward, as Portal and Pro seem to be the future. In the short term, ability to use single sign-on with you active domains users (for example), one point of security administration, and the collaboration I mention earlier could all be positive reasons for federation.
So, I do think there are some good things about Portal federation, but for us, it's the licensing that is more of a hurdle. If that is not an issues, then it is worth looking into. Again, my opinion.
Great questions and great discussion! We currently have the same ArcGIS Server setup and workflow with AGOL as you, Matthew, and are wondering how we will accomplish the same delivery of map/feature services with Pro and Enterprise. I look forward to more discussion in this thread.
> We have never seen a need for Portal for ArcGIS as we have always used AGO for Organizations as a means of publishing web maps via our services created through our own ArcGIS Server.
This is a perfectly valid deployment option of the ArcGIS Platform to enable the "web GIS" pattern. In the web GIS pattern, a "portal" is a central destination for all of an organization's geospatial assets. All of Esri's client apps are designed to work with data and content from a portal - which could be ArcGIS Online and/or Portal for ArcGIS.
Many customers use this option for the same reasons you stated.
> do we really need to install Portal for ArcGIS? Is this a requirement at 10.5.1?...or does it come along for the ride starting at 10.5.1 for those who wish to deploy it?
No, you don't have to install it. It is optional. You're already using ArcGIS Online as your portal. If you wanted, you could also install Portal for ArcGIS, if perhaps you wanted to also have an "internal only" portal. For example, you could do this:
> I'm very curious what the optimum workflow is from Esri's point of view for publishing services through ArcGIS Pro. You are able to share a web map to a portal, share a feature layer to a portal, but what exactly does that mean?
ArcMap publishes data directly to ArcGIS Server to create web services. ArcGIS Pro shares content to a portal (ArcGIS Online and/or Portal for ArcGIS) and can create a web map, web scene, web layers, and their associated web services. When you share content to a portal, you get more than just web services. Web maps, web scenes, and web layers can have other properties such as: pop-up configurations, layer symbolization, etc. These additional aspects are part of the "geoinformation model" that only exists within a portal. These settings are all honored by the Esri client apps and Esri APIs/SDKs - which means the data can be viewed in the same manner.
> There's no way we want to publish hosted feature layers if we have Server. Perhaps this is different if you are dealing with Portal, but to me, a hosted feature layer is a static snapshot of your data which is living in the cloud, and not referencing production or replicated data.
You don't have to publish hosted feature layers - this is optional. ArcGIS Pro supports sharing data and content by referencing registered data sources since the v1.2 release (v1.4 for cached map services).
(see the Referencing registered data sources section)
With Portal for ArcGIS, when you publish/share a hosted feature layer - the data gets copied into the ArcGIS Data Store.
> what exactly is the data store used for? Is it a necessary component? ... can services no longer reference a file gdb, enterprise gdb? Does a data store somehow reference production / replicated data sources to ensure 'live' data is being served by the services?
There are 2 key separate ideas here,
1. ArcGIS Server "data store" concept - this is a valid location that contains data used for web services. This has been around since the ArcGIS Server 10.1 release. Source data for your web services are located in a "data store" (could be a database or a folder) such as file GDBs, enterprise GDBs, etc. Sounds like you've already been leveraging this functionality in your deployment. These are still valid and applicable in ArcGIS Enterprise - nothing has changed with this functionality.
2. ArcGIS Data Store component - this is a separate software installation included as part of ArcGIS Enterprise since the 10.3 release (formerly called ArcGIS for Server 10.3). You use this to support a hosting server, which is used in to enable "web GIS" with ArcGIS Enterprise. This means you would install: i) Portal for ArcGIS + ii) a hosting ArcGIS Server site + iii) the ArcGIS Data Store registered to the Server site. It is used when Portal members upload data directly into Portal, when you run the analysis tools in the Portal Map Viewer, and by both the GeoEvent and GeoAnalytics Server Roles. The blog you referenced says that post 10.5.1, we will no longer support using an enterprise GDB to support a hosting server deployment - but they can still be used as a "data store" (the concept) for ArcGIS Server.
> I'd appreciate any comments ... on how each component of ArcGIS Enterprise is meant to be used
FYI, please see these 2 resources:
> I would say that if you are getting everything you need from AGOL, and don't have any services that need to be secured behind you firewall, stick with that.
I agree with Rebecca Strauch, GISP's statement.
> I was told you can also take advantage of the DataStore even without Portal, by registering it with ArcGIS Server
This is not correct. Portal is required.
> I'm very curious what the workflow is ... or if there even is one ... on how to publish a service to ArcGIS Server using ArcGIS Pro.
This workflow is currently not supported. Please see this Esri 2017 pre-UC Q&A question on the topic,
Is there a plan to allow publishing of services from ArcGIS Pro directly to ArcGIS Server?
Questions and Answers | 2017 Esri User Conference
(the question is under the ArcGIS Pro section, 14th question in the list)
> what exactly does federating Server with Portal do? What are the benefits?
When you federate a Server site with Portal for ArcGIS, you are telling the Server site to use the same authentication and security model that's been configured with Portal. FYI, to set-up a hosting server, the Server site must be federated with Portal.
Apologies for the long response, but I hope this helps,
Thanks for detailed response!
I guess the crux of my initial question has to do with the workflow for publishing services using ArcGIS Pro. As you mention, there currently is no workflow like the one that exists within ArcMap for publishing a service directly to ArcGIS Server.
As basically all the posts in this idea mention, in my opinion, this is a glaring oversight with Pro. For users that already have ArcGIS Server and have no use for Portal, Pro seems to be basically forcing our hand to use Portal. We are very happy publishing services to Server and then adding feature service endpoints to our AGO Organization as items, configuring layer symbology, filters if necessary, pop-ups, etc..., all that you seem to mention as a benefit of publishing an item to a portal. Or, we can simply add REST endpoint map services directly to a web map and either save the web map as-is or configuring an application through a template or Web AppBuilder. Another main advantage of this workflow is that AGO is hosted by Esri; we don't have to license an OS, deploy a server, or manage the software. We would have to do all of this with Portal, with little to no advantage that I can see.
ArcGIS Desktop's (ArcMap/ArcCatalog) days are numbered, and at some point will be in non-development mode with ArcGIS Pro being the main desktop application in use. Is there really no other planned way of deploying your data to the web other than publishing a hosted feature layer within AGO (which, again, those of us with ArcGIS Server would probably never consider) or federating Server with Portal and having to manage both Server and Portal?
> As basically all the posts in this idea mention, in my opinion, this is a glaring oversight with Pro.
In the ArcGIS Idea thread you reference, I posted the official Esri UC 2017 Q&A response to this question. Please vote for the enhancement request and also add your comments to the thread.
Hope this helps,