A case against Federation? Hidden Cost?

[ZacharyHart]

We are currently have a stand-alone ArcGIS Server deployment, our users consume these (map & feature) services primarily via a simple javascript web app, but are also used by a smaller pool of desktop users. Currently our users authenticate at the GIS Server tier. We only use ArcGIS Online to configure web maps (popups etc) for use in the WebApp Builder (the application that is created we host outside AGO).

We have spent some a good deal of time setting up a 'base deployment' of ArcGIS Enterprise 10.6.1 with a federated server.

We have configured our authentication against our Active Directory via LDAP. Everything works great.

However, we have reached a moment of reading the fine print.

Now all of our users must be assigned a named user license within Portal. The documentation says that any user must have a level-2 license (or with 10.7 an 'editor' or 'field worker') in order to edit via feature services. This is not currently the case with the user store at the GIS tier, we have 30+ users that have nothing to do with AGO/Portal. In fact, I could have an unlimited number of editors.

Here is the cost implication:

• At 10.6.1, Level 2 user $500/year * 30 = $15,000/year
• At 10.7:
  • 'Field Worker' $350/year * 30 = $10,500/year
  • 'Editor' $200/year * 30 = $6,000/year

Where in the documentations or any announcement of Enterprise does it advise managers about this cost increase? Does federating your site remove this functionality?

Is anyone else facing the same issue?

I certainly hope I'm missing something here.

[DanielCota1]

Hello Zachary Hart‌,

Thanks for reaching out to us with your concern. Glad to hear you are looking to better understand the full functionality of the ArcGIS Enterprise platform. 

It is understood that you are concerned with the apparent increase in cost for the workflows that you are currently implementing in your organization. While I personally cannot speak to the specific price points, based off what you described, I believe you should still be able to have users edit the services published to your server without having to provide them a named user in your Portal orgazaniton. However, this would entail sharing the services publicly as opposed to only within the organization.

For example, if you published a feature service with editing capability, it will be defaulted to be shared only to the publisher. Sharing it to a group or to the Portal org will require authentication from a named user in the Portal. However, if shared with Everyone (Public), then the service will be freely accessible to those who are not named users. This would allow for editing without a named user account. Of course this workflow comes with it's own concerns, but this would be a means of working around the cost.

Federating unlocks more functionality with your Enterprise workflows (i.e. Hosted Feature Layers, premium web apps, etc.), but you are right. It does entail having to be bound by Portal's user store configuration.

[ZacharyHart]

However, this would entail sharing the services publicly as opposed to only within the organization.

That isn't a solution.

[JohnBrockwell]

I've never felt entirely comfortable with the ArcGIS Enterprise deployment. Cost is an issue and federation is a serious decision. 

I setup the ArcGIS Servers to federate only to have network security decide my Portal web adaptor was in the wrong DMZ zone. Now I have to migrate to a new web adaptor and ArcGIS server can't find the new web adaptor. Federation is so easy to set up and so difficult to undue. It's just nuts how screwy this COTS software can get.

[CarrieCarsell2]

Thank you for publishing this Zachary, we have just run into the exact same issue on our end. We have some large internal applications that will not be able to have named users, as more than 120+ users in our company will need to edit at lease some data in the apps. We have been looking for solutions and this post (with Daniel's subsequent reply) confirms our suspicions.  It is not a great idea to have to make all our services public, as the whole point of upgrading was to allow for a higher level of security in our company. 

Therefore we are faced with with either losing all our security by opening up the services, or un-federating and going back to the old deployment. Seems like a no-win situation.

Daniel Cota‌, can you speak more to the more functionality we would gain by continuing to have Portal federated? The Esri documentation is fairly limited and not up-to-date as far as publishing from ArcPro 2.4 (directly to Server) and some other items.

[ZacharyHart]

Carrie Carsell‌

You are welcome, and congratulations! You now get to talk to your financial management people about a $24,000 annual budget increase. Esri didn't do a good enough job explaining these implications and the costs are significant.

I can only come to two possible conclusions:

1. Esri doesn't have a good grasp about it's customers needs and how they are implementing/utilizing their products.OR
2. Esri understands these cost implications and doesn't care. If they did there would have been much more transparency and customer outreach.

So it's up to you to decide which one it is. If anyone can offer #3, I'm all ears.

[Waan]

I think there actually is an option 3, but it's ……. less than ideal. And it likely won't work for Zachary Hart (but possibly might work for Carrie Carsell).

Is it possible to stand up a fully federated Enterprise site with Portal and all that junk, and then turn around and buy/install another ArcGIS Server in an unfederated environment for your 3rd-party users? If it is, that offers a potential workaround.

ADMITTEDLY this is still a hefty extra spend, but it might actually make sense if it's less expensive than buying everyone and their brother a named-user license. Of course it kinda kills the whole point of federation, but certain Esri applications are basically forcing us to adopt federation (my organization is facing this if it upgrades GeoEvent Server to any version beyond 10.5.1).

[ZacharyHart]

I see Senator Palpatine is really making the rounds. So you want to use GeoEvent Server? The Trade Federation would like a word...

[DanielCota1]

Carrie Carsell‌

I can only speak from a technical standpoint, but all of the functionality that comes with federating is outlined in the documentation below:

https://enterprise.arcgis.com/en/portal/latest/administer/windows/about-using-your-server-with-porta...

As for publishing directly to Server from Pro, this is definitely possible, but not without federating. This is because Pro is designed to be integrated with the WebGIS platform, so layers can be shared with and seamlessly pulled from your online portal (ArcGIS Online or Portal for ArcGIS). As such, the only way for Pro to communicate with the ArcGIS Server for publishing would be if it were a federated server. As of now, the only way to publish to a standalone server is still through ArcGIS Desktop (ArcMap).

I hope this helps. 

[CarrieCarsell2]

Thanks Zachary Hart and Daniel Cota, for now we have no other recourse than to unfederate. There is light at the end of the tunnel, however, and ArcPro will soon be able to publish directly to Server as noted by Philip Heede  near the very bottom of this long thread: https://community.esri.com/ideas/12258 

We have been working on this deployment for many months, and it feels like defeat to roll it all back. At least we still have the power of Portal and the power of Server, albeit independently of each other.