Portal Best Practices for setup?

[PaulDavidson1]

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.

[Drew · Accepted solution]

I can give you our set up.  We are slowly getting people onto Portal so it may need to scale a little bit in the future.

• VM Box -  Xeon @3.3Ghz, Quade core, 16 GB Ram
• ArcGIS Server 10.3.1 and Portal on the same box
• Managed Database on a separate database server
• IIS with web adapter
• Federated
• HTTPS - i believe its required.
• Install
  • ArcGIS Server first and the Portal
    • Simply because we federated the server - we needed AGS installed already

[PaulDavidson1]

Hi Andrew,

Thanks for your response, very helpful.

Based on the other responses, it's looking a lot like what I thought.

It really depends on your loading!

Which of course is the beauty of the VM world, or at least with VMware, we can bump resources up and down in real time as needed.

I just wanted to verify some things:

You're running a VM box with 4 cores and 16GB

Are you using VMware or Msoft HyperV ?  (or whatever MS is calling their current incarnation.)

I'm just curious, I doubt it matters as I know folks using both.  I prefer VMware but it's what I know.

When you say Managed Database, are you referring to a database backed Geodatabase or to the Data Store that comes with Portal?

Do you have AGS boxes serving up content (map services, feature services, imagery, etc...)?

With AGS & Portal together, is there a reason you didn't go the Hosting route?

If I recall, Hosting also includes Federated capability?

Many thanks.

[Drew]

Paul,

Are you using VMware or Msoft HyperV ?

     We are suing VMware

When you say Managed Database, are you referring to a database backed Geodatabase or to the Data Store that comes with Portal?

The managed database is one that Portal uses when people want to copy data to the server. We prefer not to do this though.. I believe we needed one when federating though

Do you have AGS boxes serving up content (map services, feature services, imagery, etc...)?

We have a few AGS boxes.  All our basemaps and other common services are not hosted on our Portal AGS box, but linked as basmaps. Out Portal AGS instance is strictly for portal resources created by users.

Hope that helps.

Andrew

[PaulDavidson1]

Thanks Andrew:

One more question about your other AGS servers that are serving up your basemaps, etc...

Are those all on one site and your Hosting server setup as a separate site?

Or do you have them all joined together as one site?

I'm curious as to +/- of these two approaches.  Tie all servers together or keep the portal server isolated...

I imagine either way works, until you find something that creates a snag

thanks

[JustinRodriguez]

Hello Paul,

I hope you are doing well. Portal for ArcGIS and Server for ArcGIS are both pretty RAM intensive products. As such I would not suggest that they are on the same virtual guest or virtual host for that matter. Please separate the machines as much as possible to ensure maximum resource availability.

You can install them all on the same machine, and it would be fine, but I would split them if I could.

Simply turning on IIS and putting a web adaptor on the machine shouldn't be an issue, but I wouldn't try to install these products on a full blown web server hosting multiple applications if I could avoid it as well.

I do not believe there is a specific installation order as these products are independent of each other.

I hope these answers help a bit. Thanks-

Thank you,

Justin

Esri Support

[PaulDavidson1]

Hi Justin:

I like the idea, it is where my thinking has been going, at least until we start running out of resources.

I mean, to have separate servers for each functionality.

But at some point, I'm probably going to get reigned in and have to make servers multi-functional.

I guess I'll start with as much separation as possible and scale it back as needed.

[Robertvan_Waasbergen]

Paul,

Portal and Server can live on the same machine, as long as there are sufficient resources.  We haven't had any issues doing that.  The Portal does not appear to be very processor-intensive, as most of the heavy lifting is handled by Server.

You will want a Hosted server in order for Portal users to be able to publish data as services through the Portal interface (doesn't require ArcGIS Desktop), and to enable certain Portal API features.

You will want to use Federated servers if the services that are hosted in those require secure access.  Federating the servers means they will hand off authentication and privilege handling to the Portal.

One thing to keep in mind is user-licenses for Portal: unless your organization has a huge (or unlimited) number of licenses, this can become a problem if everyone who wants to access GIS services needs to be a Portal user.

I hope this is useful,

Robert van Waasbergen

[PaulDavidson1]

Hi Robert

Thanks for the response, very helpful.

Can you run the Hosting and Federation on the same AGS unit?

I seem to recall that Hosting included the ability to federate?

We're on an ELA so we're working on the Portal licensing.

It is of course a concern.

However, I was wondering:

if we publish a map or a web app that is available to everyone, then a user could get to it without needing a Portal license, right?  Similar to what one can do in AGOL.

Since we're inside a firewall, anyone who can see the everyone map has already been authenticated just to get on the network.

Do you know if that's a correct statement?  That a map open to everyone on Portal doesn't require a Named User on Portal?

[JustinRodriguez]

Hello Paul,

You only need licensing for Named users. You can publish Maps with Anonymous access, and if your end customer's access this service without logging in, then there wouldn't be any licenses consumed. Secured services would require a named user, and thus could potentially require at least one named user.

Portal, for all practical purposes, is ArcGIS Online that is hosted internally. If you can do it without a license in ArcGIS Online, you should be able to do it without a license in Portal.

I hope that helps.

Thank you very much,

Justin Rodriguez

Esri Support