nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

New deployment GIS Enterprise 12

dwebeltch

Have a customer that wants to upgrade to the newest GIS version but also wants to move the back-end to Azure. This customer has zero IT experience and only knows how to use the GIS system.

I'm a bit confused on how this is set up. I've read the documentation and watched some videos but things still aren't connecting.

There's a 1 server setup or a 6-7 (or however). Why use so many if 1 suffices?

There's something called Portal but also something called Online. We were assuming the Servers connected to the Online portal to work but some things read like this is set up as a web server. We don't want to manage a web server so is this something that connects to a SaaS front-end tenant?

The confusion in this is making it difficult to figure out what questions to ask to get this going so I'll stop here and see where this takes me.

thanks.

Najděte více příspěvků označených jako

Accepted answers

All comments

JoshuaBixby

You may be consulting for/on IT, but it is clear you have very limited knowledge of GIS, so the earlier comment about hiring a consultant still applies. ArcGIS Enterprise is a complex platform with many components. Which components get deployed and how depends on the businesses requirements, but having requirements means little if it isn't accompanied with understanding the product itself.

ryanuthoff

I'd assume 11 is recent enough to be still supported.

It depends on what your definition of supported is, but no, not all versions of v11 are fully supported. For example, v11.0 is fully retried already, and 11.2 is already in mature support. See Esri's lifecycle here: https://support.esri.com/en-us/products/arcgis-enterprise/life-cycle

My thinking is that they will need to upgrade the current system to 12 first

This is not a hard requirement, but won't really hurt either way. However, you should (imo) always be on a supported release of ArcGIS Enterprise, otherwise you won't get bug fixes and security patches. If the specific version of Enterprise is already out of support, I'd recommend upgrading first just so you can take advantage of bug fixes and security patches.

then we need to work with ESRI support to get a migration plan document (I assume support has instructions on how to do this)

Your milage may vary depending on the tech support person, but this is typically out of scope for Esri support. Again, you'd need to engage with someone from Esri Professional Services (extra $$) or hire a consultant (again, extra $$). See Esri's scope of support here: https://support.esri.com/en-us/knowledge-base/scope-of-support-000029916

I believe you would fall under #7 which would be considered out of scope.

I would be 100% for a consultant here and will speak to my management regarding that but it's a long shot

I'll be honest here and say that it's pretty wild that you are going to be expected to manage an ArcGIS Enterprise deployment (not to mention a migration to Azure along with it) with no Esri experience. Of course we here in the Esri community are always willing to help when we can, but it's not going to be a replacement for hiring a consultant.

D_Atkins

I disagree that "moving to the cloud is an all or nothing situation" but acknowledge that it requires careful consideration of the data volume, the desired velocity (no pun intended, ESRI), and so forth.

My post was more intended to highlight exactly what you say, "if we really want to go down the Azure rabbit hole, we need to consider EVERY component that touches ArcGIS Enterprise." It doesn't sound like @dwebeltch has a strong grasp on how many different tools and components are included with Arc.

We can even keep it more directly on topic: which combination of GIS Servers do you need? ArcGIS Enterprise servers—ArcGIS Enterprise | Documentation for ArcGIS Enterprise

@RyanUthoff wrote:

This is exactly why I said in my previous post that their best bet is to hire a GIS consultant that will come up with a comprehensive solution to not only migrate to Azure, but to ensure everything is setup correctly from the start.

@dwebeltch wrote:
We are the consulting for IT.

dwebeltch

Thanks everyone for the replies. I'm reading through things as I can.

I do understand a bit more on this as coming into this blind has been really frustrating.

The company is on v11. They are using a server per app build so I think that means each piece is on a different VM in Vmware. I cannot speak to what they use inside the system so not sure if things are depreciated or not. I'd assume 11 is recent enough to be still supported.

The company wants to move to v12. They are also looking to move these into Azure for more reliability as they are running the current system now in house with no redundancy (other than backups).

My thinking is that they will need to upgrade the current system to 12 first; then we need to work with ESRI support to get a migration plan document (I assume support has instructions on how to do this) and build out the Azure POC/test/all that. Once all is good then cut over when the data is synced or however ESRI does this.

I would be 100% for a consultant here and will speak to my management regarding that but it's a long shot so I feel most of this will be on my shoulders even though I know nothing of any of this. I guess 'IT Tech' means I know everything that plugs into the wall or runs on computer.

ryanuthoff

I didn't include the DB component since that was not asked about, but if we really want to go down the Azure rabbit hole, we need to consider EVERY component that touches ArcGIS Enterprise.

So as you mentioned, the DB's are an important component of that and will need to go up to Azure along with ArcGIS Enterprise. And of course there are various implementations of that, whether that's rolling your own install of a DBMS in Azure or using Azure's cloud-based DBMS. Depending on the implementation the organizations uses, it could possibly involve a lot of work in pointing the existing servers to the new DBs.

Not only that, but we need to think about how the end user interacts with the data in the DB. Any users that use ArcGIS Pro that make database connections where the DB is hosted in Azure will need to have a workstation in Azure as well. That's not a hard requirement.....but trust me when I say that if you don't have that, your productivity will be killed by terrible latency.

I guess what I'm trying to say is that moving to the cloud is an all or nothing situation. You can't necessarily move some components to the cloud, while leaving other components on-prem. Sure, it might technically work, but the performance is going to be terrible if it's not all or nothing.

This is exactly why I said in my previous post that their best bet is to hire a GIS consultant that will come up with a comprehensive solution to not only migrate to Azure, but to ensure everything is setup correctly from the start.

D_Atkins

Comments so far seem to have missed the "Azure" in your opening post. In this case (and Community, please correct me if I'm wrong), a request for Azure-cloud service can be as simple as replacing on-prem RDBMS (SQL, Oracle), but not always or necessarily any other ArcGIS Enterprise components (Server, Portal).

Of course, you can go full cloud with Enterprise these days: Introduction to ArcGIS Enterprise on Microsoft Azure—ArcGIS Enterprise in the cloud | Documentation for ArcGIS Enterprise

Which reiterates others' question: what is hybrid?

* ArcGIS Online & ArcGIS Enterprise, both in the cloud: not uncommon but a bit redundant. We use both for different redundancies and traffic distributions. But then it's really two different systems -- 'two organizations' that can participate in a Collaboration model: see About distributed collaboration—Portal for ArcGIS | Documentation for ArcGIS Enterprise and Collaborate between ArcGIS Enterprise, ArcGIS Online and ArcGIS Field Maps

Despite the 'collaborations', administration of user accounts will likely vary between the two systems.

* The other common Hybrid model: Cloud data storage/redundancy with an on-prem Enterprise deployment. In this instance, you're just replacing references to SQL or Oracle with an Azure backend. In this case, administration is more streamlined to 'one instance' of ArcGIS.

In either case, Arc does not include the RDBMS -- it's an abstracted layer on top.

---------------------

One thing you haven't really clarified is what your starting point is? What version Geodatabases, and what is the backend (Oracle, SQL). If this an established organization with a decade or more data, and is still reliant on ArcMap, WebAppBuilder, Geometric Networks, or any other of ESRI's deprecated tools, then simply deploying a new environment is barely scratching the surface of an 'upgrade'. Of course, if it's a younger org primarily working out of File Geodatabases, then it's a bit more streamlined.

ryanuthoff

Ohh, I see. Thanks for the additional information.

ArcGIS Enterprise can be deployed in various ways. There is not an issue with all components being installed on the same machine, just as long as the machine has enough resources to be able to support everything.

For a base ArcGIS Enterprise deployment, you can install everything on one machine.

I was under the impression that we build out a server with the components installed. Then this server connects outbound to a SaaS web portal run by GIS that allows everything to talk/function and for users to interact and use the product. Is this not the case?

I'll directly respond to your statement above and hopefully clear things up. For a base ArcGIS Enterprise deployment, there is no SaaS. You host everything on your servers. There is no ArcGIS Online. ArcGIS Enterprise includes three components: Portal, Server, and Data Store. Then you also need the ArcGIS web adaptors or some kind of third party load balancer.

Portal is how most end users typically interact with it. That's how they access their web maps, etc. The ArcGIS Server is essentially "connected" to Portal. So all the map services you publish to Server will appear in Portal for people to view and access. You would need an IP address for Portal in this scenario.

Now, I did see your follow-up comment about the hybrid deployment. Keep in mind that organizations can have multiple variations of a "hybrid" environment. From how you're describing it, what I am assuming is happening is that you have deployed ArcGIS Server on-prem, but then want to connect ArcGIS Server to ArcGIS Online, which is how people use the web maps. In this scenario, your end users publish services to the ArcGIS Server. Then, they take the service URL and add it to ArcGIS Online. That is certainly one variation of a hybrid deployment. You are technically correct that the end user's connections go through ArcGIS Online, however ArcGIS Online will still need to communicate with your on-prem ArcGIS Server to retrieve the data from the service.

LavanyaVasudevanNES

Just to help you get this started, check out:

https://architecture.arcgis.com/en/

and

https://enterprise.arcgis.com/en/

Hiring consultants to help with the ArcGIS Enterprise is possibly the best option given that the client already has a system and needs that upgraded/migrated. Unfamiliarity with AGE can break the current production systems causing a bigger issue.

dwebeltch

Another bit of information; the client calls this a 'Hybrid' deployment where connections go through GIS Online and not to the internal servers themselves.

I hope that makes sense.

dwebeltch

Oh sorry I didn't add. We are the consulting for IT. I can build whatever I just don't understand what I'm supposed to be building here.

I can build out the servers they need, but my real issue is not understanding how this all fits together.

I was under the impression that we build out a server with the components installed. Then this server connects outbound to a SaaS web portal run by GIS that allows everything to talk/function and for users to interact and use the product. Is this not the case?

If my thinking is right then why would we need an application gateway or anything like that when a public IP would suffice to connect the server to GIS Online. This would be an outbound only connection correct?

Thank you for the help.

ryanuthoff

I think your best bet here is to hire a consultant that will understand your needs and build out a system that meets your expectations because there is a lot to unpack here and it's extremely important to set everything up correctly from the start, otherwise you're going to run into issues down the road that will cost the organization time and money.

To briefly explain, you have ArcGIS Online and ArcGIS Enterprise.

ArcGIS Online is a SaaS offering where all your data is stored on Esri's servers. You hosting any infrastructure or software is not a requirement.

ArcGIS Enterprise is where you host the infrastructure (whether on-prem or in the cloud) as well as the Esri software. Since your customer is wanting to upgrade and move to Azure, this tells me they are already using ArcGIS Enterprise. This means AGOL is irrelevant unless they want a hybrid option where you use a mix of Enterprise and AGOL.

If you don't want to manage any web servers, then you will need to use AGOL as AGOL takes care of all of that for you.

Alternatively, if you don't want to manage anything but need to stick with ArcGIS Enterprise, you can hire a third party to manage it all for you. Considering your organization doesn't have any IT experience, I think this will be your best bet. You absolutely need someone who knows what they are doing to build out and manage and maintain your IT and/or ArcGIS Enterprise environment.

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.