Select to view content in your preferred language

Portal Best Practices for setup?

21958
29
Jump to solution
07-08-2015 04:15 PM
PaulDavidson1
Frequent Contributor

Surprisingly, I didn't find any prior posts about combining Portal with Server:

I am starting to setup an internal Portal  w/ Federated/Hosting servers

And a new server farm setup based on 10.3.1

I want to tie the whole shebang into our AD servers so that users should be able to do single sign in.

This will all be behind our firewalls on an intranet.

I'm in a virtual server environment, VMware

I've found two recent write ups rather helpful.

Portal for ArcGIS 101   - also published as a pdf somewhere....

http://www.esri.com/library/brochures/pdfs/arcgis-server-functionality-matrix.pdf

I'm curious as to how folks are doing some of the setup:

Are you dedicating a server strictly to Portal?

Putting Portal and ArcGIS Server on the same box?

Federating or Hosting?

http or https?  Am I correct in assuming that it's better to just start with https and go from there.

Seems like I've read that for something to work correctly, you need to be using secure services.

My reading indicates the best thing to do perhaps is to have an ArcGIS Server, with Portal and Data Store on the same box?

Is best to then only lightly load this ArcGIS server and let other Servers do the heavy lifting?

How does IIS play into this?  Separate server?

That's my plan.

Right now we have a server running ArcGIS Server, lots of map services and IIS and well....

It's not the most stable box.

How about when you toss a GeoEvent processor into the mix?

Should you dedicate a Server strictly for GeoEvents?

I'd imagine this depends on how many events are coming in and at what frequency?

What's the installation order that is most successful?

Build up your Server farm and then bring Portal into the mix?

Or stand up Portal first and then go from there?

I can always just build virtual boxes and toss them away if they seem to be wrong.

But without putting the setup into production, it's hard to load it properly for a real-time test.

Now I know a lot these potential answers are really dependent on the organization and it's level of activity.

But any comments or experience will be helpful.

29 Replies
PaulDavidson1
Frequent Contributor

Thanks Justin!

That confirms my understanding.

0 Kudos
SteveCole
Honored Contributor

Just wanted to chime in on a tidbit previously mentioned.

At the conference, ESRI did recommend placing the installs of Server and Portal on different servers but they did also note that this is not possible if you are using Server for Workgroups. In other words, if you are using an Enterprise version of Server, you can (and should) do this. Otherwise, they must be installed on the same machine.

PaulDavidson1
Frequent Contributor

Thanks Steven...

I heard the same thing at the UC.

Basically it seems like if you have the resources, you separate things.

But I also talked to a number of folks who had Porta/AGS-Hosting/DataStore and 2 web adapters on one box.

But I think this depends a lot on your resource availability and how heavy your load will be.

I'm going with separate Portal and AGS-Hosting VM boxes.

Now trying to figure out where to put the Data Store and data config files.

I also need a filer server for our file geo databases that our other AGS units dish up.

Thanks for providing that note!

0 Kudos
PaulDavidson1
Frequent Contributor

An update of what I've learned so far:

1. I built an all-in-one box on a VM on my local development box using the Chef cookbook from Esri.

This was after I had developed some stand alone boxes, federated them, hooked them to AD, etc...

The Chef method is very fast and gets you jump started.  I fumbled for a day or two understanding some settings.

But after getting the json file correct, I can do an install in a few hours and have a fully working Portal, Federated Server and Data Store all working on a single box.  Great for dev and testing.  Probably not best for production but others report success with the setup in production.  I consider this a development/sandbox setup.  And with Chef, it's one I can destroy and recreate in no time.  In fact, I've done that twice already as a test.

For more info:

GIS Standardized Installation Tool - Chef Provisioning Cookbooks

have now created individual boxes for: Portal, Federated Hosting Server, Data Store and IIS (which holds the web adaptors and eventually some websites).  The data config files are sitting in a shared folder available to all boxes.

This will be a Test setup.

I created these boxes using Chef as an individual install per box.  This is a bit outside the scope of how Pavel setup the Chef cookbooks so I  have to do some hand work with security and such.  But again, the use of Chef makes this process much easier.  Of course, one issue is you then don't read through all the help instructions so you may not understand Portal as well as you would otherwise.

These boxes were all built under VMware on my local PC (it's a beast) and are now with the Systems guys to finish putting into the sphere.  I ended up putting the all in one dev box onto the sphere also where it runs faster.

I figure going through all this should mean that a Production installation will be faster & simpler and quite solid.  I'll report back on how well the Chef method worked as individual installs and the gotchas I encountered.

BillFox
MVP Frequent Contributor

Hi Paul,

I'm going through similar steps to keep separate Portal for ArcGIS site and its federated ArcGIS Server site (data store is just another enterprise geodatabase).

Maps for Office, editor tracking with AD & SSO in the works with this setup too.

I have SSL Web Adaptors for both ArcGIS Server and Portal on same box as Portal for ArcGIS.

The ArcGIS Server site started as single cluster with multiple ArcGIS Server machines but production use proved tough to troubleshoot and maintain so we dropped it to a single machine. Having everything in Vmware allows us to scale the two machines (1-ArcGIS Server and 2-Portal for ArcGIS) as needed.

Also, had the config store on its own file server to support multi-ArcGIS Server machines but this too was a sore spot that recently led to network issues corrupting some of the functionality. It is now on the same server as ArcGIS for Server with full functionality.

I also tried the HA Portal for ArcGIS and got working but another sore spot for troubleshooting and dropped it back to single server to get going forward.

The share with everyone option is working fine with initial Portal for ArcGIS roll out. More testing to do with secure apps/services.

-Bill

0 Kudos
PaulDavidson1
Frequent Contributor

Hi Bill,

sorry, very late reply....

Here's an update on where I've ended up going with our Portal.

It's a complete change of direction for me but I was successfully convinced to do so by Esri's release of a Chef cookbook for installation.  I have documented that here:

GIS Standardized Installation Tool - Chef Provisioning Cookbooks

I have setup Portal by hand on separate servers, took many days to do this.

And I have stood up a Dev, a Test and a Production Portal using the cookbook in about a half a day per machine.

You still have to configure everything and you have to have sufficient resources in order for everything to run on one box.

We're in a very plentiful VM environment where resources are no problem.

But we also don't have anything into production yet where many users are hitting things.

That will be the real test of course.

I setup our Prod Portal to use a fileserver for the config files with the intent to implement an HA setup shortly.  That will be awhile probably though since once Portal is up, my time is dedicated to standing up data, etc...

So far in our testing, things seem to work pretty well.  With large complicated maps we have learned to save the map often because we occasionally have things hang up.  I am leaning towards this being an IE issue and not a Portal issue because when one of my analysts reports that he is now hung, I can go onto Portal and things work fine.

One of the convincing arguments for me regarding the allinone box was that you only have one box to go down instead of three or four.  i.e. you reduce your odds of a hang/reboot scenario.  Assuming you have sufficient resources to throw at the box, this makes sense to me.

I finally convinced myself to go with the all in one setup for two reasons:  (1) the ease & consistency of the setup with Chef (2) I can always end up going back to my stand alone setup if needed.

I will report back to this thread as our experience with this setup grows.

HNoakes
Esri Contributor

Hi Paul,

I'm interested in knowing what your workflow is like for getting maps/applications from your Dev environment to your Test and ultimately Prod environment. Do you use a tool for synchronizing these items across Portal installations?

Thanks,

Heather

0 Kudos
HNoakes
Esri Contributor

I'm answering my own question, promoting items can be done using the ArcGIS Online Assistant

GitHub - Esri/ago-assistant: A swiss army knife for your ArcGIS Online and Portal for ArcGIS account...

Cheers,

Heather

PaulDavidson1
Frequent Contributor

Heather:

Sorry, I meant to (or thought) I'd answered your question.  I was going to point you towards that exact solution.

There are also the Portal admin tools from GeoJobe: Admin Tools New - Geo Jobe

We're still working through our work flows to go from Dev/Test/Prod but I imagine we'll make heavy use of the Online Assistant.  We also do a lot of scripting with Python so we'll be using PortalPy and ArcREST tools.

PaulDavidson1
Frequent Contributor

Hey Heather,

I also just came across this:

Automated Setup & Reporting | ArcGIS Solutions

I haven't used it yet but I believe there are the basics of a good scripting setup.