GeoEvent Processor

[pkdavidson]

About to install a geo event processor (GEP) into our test system. Test Portal is not setup as an HA, thus the all in one box has the config folders set to be located on the local hard drive of that VM.

Looking at the GEP json file a few questions come to mind:

1. ArcGIS Server gets installed but is done without IIS or a web adaptor. Which means this is a Windows environment (Win Srvr 2012 R2) I'm guessing then that the GEP Server runs out there on its own, no web adaptor needed. Hence one doesn't federated it into the Portal system. In essence, it's sort of an island on its own. Which I also assume means that you don't publish anything to the Server piece of the GEP box. It's strictly for running the GEP extension? In the talks I've attended, the GEP is said to be rather processor intensive so I assume you would never publish map or feature services to the box.
2. How about when I introduce a GEP into my Production Portal environment? Anything different in that situation? For example, Prod Portal is setup to eventually become the primary in an HA environment. So the config folders are out there on a shared file server. Once again I'm guessing that GEP basically runs as an island, unaware of Portal and its Federated Servers? At least unaware in the sense that it is not part of Portal and is not sharing config files?

Thanks for your help.

[pkdavidson]

One question about the installation: I though the cookbooks opened up the local firewall ports. For example, the geoevent.rb file has the powershell command to do so. Although I don't see a similar one in the server.rb.

But after the install occurred, there were no ports in the firewall opened. However, it appears that we don't have the key code for geoevent on my.esri. It is part of our ELA so it's just a matter of having it added.

Would that lack of authorization have prevented the opening of ports in the firewall section of the cookbook from running?

FYI, the log I create from the run doesn't show any errors: [2016-04-16T15:34:44-06:00] INFO: Processing arcgis_geoevent[Validate ArcGIS GeoEvent Extension for Server system requirements] action system (arcgis::geoevent line 20) [2016-04-16T15:34:44-06:00] INFO: Processing powershell_script[Open Ports required by GeoEvent Extension] action run (C:\chef\cookbooks\arcgis\providers\geoevent.rb line 21) [2016-04-16T15:34:44-06:00] INFO: Processing arcgis_geoevent[Authorize ArcGIS GeoEvent Extension for Server] action authorize (arcgis::geoevent line 24) [2016-04-16T15:34:44-06:00] INFO: Processing arcgis_geoevent[Setup ArcGIS GeoEvent Extension for Server] action install (arcgis::geoevent line 30)

But the ports weren't open in the firewall. I did then run the powershell command by hand and then the ports showed up in the firewall.

When I get the proper key, should I put it into the prvc file and run the cookbook again, or just authorize via the software authorization wizard? Or will it even matter?

Thanks

[pbobov]

I have limited experience with GEE. But here is how I see it.

GEE may grab all the resources available on the machine. It's typically advised to run it in a separate clusters of machines.

GEE stream services use web sockets, which is not supported in Web Adaptor.

ArcGIS Server with GEE can be federated with portal just like other servers. To automate federation you may try to add 'federation' recipe after 'geoevent' recipe in the JSON file. You will also need to add domain_name, admin_username, and admin_password attributes for portal to the JSON as well (federation is a relationship between server and portal, so it must know about both).

So far the cookbook does not configure windows firewall, except for GEE on Amazon AWS. (Opening ports in the firewall is a sensitive subject. We don't want to rush here.) If you remove line only_if { node['platform'] == 'windows' && ENV['arcgis_cloud_platform'] == 'aws'} from action :system in /providers/geoevent.rb file, then geoevent recipe will open ports required for GEE.

The authorization file for GEE is specified using ['arcgis']['geoevent']['authorization_file'] attribute, which is by default is set to ['arcgis']['server']['authorization_file_version'] attribute value. That is, if the license file specified in 'sever' section contains the keys for GEE, then you do not need to specify a separate license for GEE in 'geoevent' section.

[pkdavidson]

Thanks very much. This helps explain what I've seen. I've opened the ports by hand (yep, you are correct, in many environments the security police would be all over me...)

I did obtain our license ECP today, put it into the PRVC file and just reran Chef for GEE on that server. Finished with no errors and now I can access the GEE manager (via the proper port of course).

Do you think there is any reason or advantage to federate this server with Portal? Seems like I might as well just leave it out there on its own?

thanks

[pbobov]

The primary reason to federate a server with portal is using the same user store across hosting server, portal, and the federated server (GEE in you case), and managing services security using portal. I'm not sure if you really need that. I'd recommend you not doing that for production deployment before you find the reason to do that. At the same time, I'd recommend to try and federate GEE in the staging deployment, so you understand the process, the problems (if any), and the effect. First I'd do it manually, and then would try to automate this.

[simongis]

Just trying to understand how the script allows for access to GeoEvent in the scenario where you have a ArcGIS Server federated with Portal, Data Store and GeoEvent all on one machine, but using an external domain (which the script applies to the portal URL for the web adaptor).

Does it do something special in IIS to allow logging in via the web adaptor? Rewrite rules?

[pkdavidson]

Hi Simon, I can't answer your question. But I will comment that based on what I've read and from taking the new GEE course at the UC this year, that I think trying to run GEE on the same server as WebGIS is asking for a lot of potential problems. Every source I can think of has told me to place GEE on its own ArcGIS Server.

GEE can be very intensive in its processing and I believe it's designed to be a priority resource hog. That's a pretty standard tenant of data acquisition and real time work.

If you go this route, maybe as a dev box?, I'd be curious to hear how it works out for you. I can envision some scenarios where it might work if the load is very low. I'd suggest reaching out to the GEE guys for more information.

[simongis]

Thanks @pkdavidson I agree with you - this is just a dev environment for a partner to trial out OSISoft and the Pi Integrator.

I have found out that Cloud Builder is doing some magic with URL rewrites in IIS, thought it might relate to a recipe here, but perhaps specific to Azure.

[nshampur]

Yes. The azure configuration through cloud builder uses IIS + ARR which supports web sockets as a reverse proxy.

It does not use Chef to do its configuration but rather automation through Powershell DSC.

Sent from my iPhone

On Jul 24, 2016, at 9:43 PM, Simon Jackson notifications@github.com<mailto:notifications@github.com> wrote:

Thanks @pkdavidsonhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pkdavidson&d=CwMCaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=GKPzMDXz5g9Gb1wx5wVvSf58aIRvq0W8_K0q541KA0U&m=quzjBtI4gDESepk73MTkozizJlxCQ07mrsREPW7DWNk&s=oLxRKBDFUPwo8m-dQdfGcAjnmsTp-B-zHXCYLT0HQaE&e= I agree with you - this is just a dev environment for a partner to trial out OSISoft and the Pi Integrator.

I have found out that Cloud Builder is doing some magic with URL rewrites in IIS, thought it might relate to a recipe here, but perhaps specific to Azure.

[1]https://urldefense.proofpoint.com/v2/url?u=https-3A__cloud.githubusercontent.com_assets_2769383_17090669_14d6bedc-2D5276-2D11e6-2D8c0d-2De7fd3b4972f7.png&d=CwMCaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=GKPzMDXz5g9Gb1wx5wVvSf58aIRvq0W8_K0q541KA0U&m=quzjBtI4gDESepk73MTkozizJlxCQ07mrsREPW7DWNk&s=D4udgD2e45Uh5J2hCvr2ZTzDxbIDwrzBKb6-rg1T2sc&e=

You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3Agithub.com_Esri_arcgis-2Dcookbook_issues_43-23issuecomment-2D234836612&d=CwMCaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=GKPzMDXz5g9Gb1wx5wVvSf58aIRvq0W8_K0q541KA0U&m=quzjBtI4gDESepk73MTkozizJlxCQ07mrsREPW7DWNk&s=ik9bIegTX6EKX4-WQv0aObVzW5fRdR_5ODgOprvXB-8&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3Agithub.com_notifications_unsubscribe-2Dauth_AES4gykUPjLsSBAhfmkY-2D-2D8ZJ3-2DU6zTRks5qZD7-5FgaJpZM4IJBB0&d=CwMCaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=GKPzMDXz5g9Gb1wx5wVvSf58aIRvq0W8_K0q541KA0U&m=quzjBtI4gDESepk73MTkozizJlxCQ07mrsREPW7DWNk&s=23CTWt1mFPgIZUei_0no6S6CQ4wuMWYJ0vp7phY2okI&e=.