POST
|
Just as an update on this in case anyone else has the same issue, I resolve this by doing the following: Delete all Geofences Export geofences in correct CRS using {serviceURL}/MapServer/dynamicLayer/query?layer=xxxxxx in JSON format Selective Export GeoEvent Configuration Store (GeoFences) Manually update geofences with exported JSON rings Selective Import GeoEvent Configuration Store (GeoFences) Something was causing GeoEvent to always use 3857 to either import or synchronise from this same service and this solved that problem, short of cleaning out the whole site. GeoFence synchronisation now seems to work and synchronise as needed.
... View more
a month ago
|
0
|
0
|
40
|
POST
|
Hey everyone, I'm having an issue with a GeoTagger not tagging a point event feature WITHIN_ANY geofence polygon on a 10.7.1 instance. I have created the geofence polygon such that if the inbound event point feature is not within one of the Allowed areas, it will be tagged with the inverse larger area geofence called None. A GeoTag value should always be applied to the point event features, though this does not appear to be consistently working near the western and eastern extremities of the largest geofence. The inverse None geofence is also not being tagged, which is the most surprising part. My GeoFence polygon features are synchronised with a feature service that is in a projected CRS, though when it imports, it imports geofence coordinates to Web Mercator, which likely uses a default transformation rather than the transformation required, being a likely culprit for this issue to occur : If I manually update the geofence polygon coordinates with projected CRS coordinates, the GeoTagger tags correctly. The problem here being that I must then switch off the geofence synchronisation and update the geofence coordinates manually for it to work, which is far from ideal. Is there some way to have them imported in the CRS specified either in the Synchronisation Rule or the Map/Feature service, or something that I'm missing? Thanks! Dean
... View more
01-13-2021
10:37 AM
|
0
|
1
|
111
|
POST
|
Thanks for the update Jonathan, that's very useful to know. Have a Merry Christmas! Dean
... View more
12-20-2020
04:16 AM
|
0
|
0
|
314
|
POST
|
Hi @JonathanQuinn, I've seen there is now a "Portal for ArcGIS High Availability and Disaster Recovery Quality Patch" for 10.6 / 10.7 available but doesn't seem to indicate the deadlocking issue is resolved. Can you tell me whether this BUG-000121969 was resolved in 10.7.1 in the patch above (perhaps as part of a different bug fix?), or whether the patch for this is coming out in a later patch? Thanks! Dean
... View more
12-15-2020
09:18 AM
|
0
|
2
|
348
|
POST
|
Brilliant, thanks for that Jonathan, I'll subscribe to this bug to await the patch at 10.7.1. Cheers, Dean
... View more
08-18-2020
11:08 AM
|
0
|
0
|
408
|
POST
|
Hi Guys, I'm having an issue with 2 separate (staging/production) 10.7.1 Portal Environments with High Availability coming back online following server restarts. From some investigation of the log files it seems to occur when the servers are restarted at the same time, with the logging service starting (within 0 - 10 seconds, after 60 seconds the nodes fail over and doesn't seem to present the issue). Following a restart of both servers, the existing master node ( Server 1 ) remains the master node, the standby ( Server 2 ) node is removed from the shared nodes.config file. Server 2 then seems to attempt to recover itself as standby node after around 3.5 hours if left alone. During this time the master node logs report to be running fine and monitoring standby nodes: HA: Node server1 .domain.local is configured to be master. HA: Monitoring the standby nodes. and Server 2 does not recover its standby node status, with the following repeating every 11 minutes: HA: Error in HA plugin. java.lang.Exception: Failed to start the Web Server. The startup timed out. Leaving the nodes.config with just the master node in play: master.node = server1 .domain.local standby.nodes = After 3.5 hours Server 2 decides it does want to be standby node, and updates the nodes.config file: HA: Store the standby node server2 .domain.local from the standby.nodes property in the nodes.properties file. And both end up in play in nodes.config: master.node = server1 .domain.local standby.nodes = server2 .domain.local The most notable issue here is that the master node web server does not display at all during this "not fully recovered" state, so the portal is essentially offline without the manual intervention of restarting portal services. Neither of the following pages will load: https:// server1 .domain.local:7443/arcgis/portaladmin https:// server1 .domain.local:7443/arcgis/home To remedy the issue, simply stopping the Portal for ArcGIS Service on Server 2 allows the master node web server to display correctly! For some reason, the standby server, not correctly acting as standby causes the master node webserver to fail to display at all. I can see (via netstat -ao) that during the failed state the localhost LISTENING 5701 ports do not seem to be running, though the servers appear ESTABLISHED via 5701, so are somewhat communicating. Once both servers are listed in the nodes.config file, both the localhost 5701 LISTENING and remote ESTABLISHED ports are running. I also see the following occurring in the Catalina logs: I have disabled McAfee for testing and internal firewalls are disabled, but the error still presented itself following serveral restarts. Maybe (hopefully) Jonathan Quinn or someone else in the community may have come across something like this before? Thanks, Dean
... View more
08-18-2020
04:34 AM
|
1
|
5
|
490
|
POST
|
Hi Olov, You may need to update the license in the AGS data store using command line if you've not already? Could be a license conflict, though I would have thought it would still function with the test licenses unless they've expired. updatelicense Cheers, Dean
... View more
01-13-2020
09:17 AM
|
0
|
1
|
270
|
POST
|
Hi Jon, I'm on 10.7.1 for both environments, and yes, unfortunately the WebGISDR error was a little general to assist with troubleshooting. The Debug logs helped find whether the error was, which was related to the authentication of one of the Image servers in IIS. Interestingly, when the geoevent server was having a similar issue, it simply skipped past the issue saying "Failed to back up the ArcGIS Server:" Unfortunately once it completed it simply deleted the backups and didn't perform the packaging operation, but did package once all of the servers were reverted to correct parameters. I'm sure that as the tool is improved it will be possible to gather the shared configuration even when one of the servers is not reachable, and to package the export prior to deleting the separate backed up components. Thankfully though, with the debug logs the needle was removed from the haystack and placed in plain sight. Thanks Jonathan Quinn Dean
... View more
01-13-2020
09:06 AM
|
0
|
0
|
76
|
POST
|
Hi Portal Experts, I have a staging environment that is having problems running the WebGISDR utility and so cannot perform backups successfully: Cannot get the web GIS configuration. I have two environments with the following configuration (this is the production env and is working successfully): The production environment is working fine as in the above screenshot. I have been running the backups via a scheduled task and running with a service account with admin privileges on the portals. The config file is like this: I've successfully managed to export a site/backup for each and federation validates successfully. Has anyone come across anything similar? Thanks! Dean
... View more
01-09-2020
01:09 PM
|
0
|
2
|
160
|
POST
|
Hi Michael, Yes that is correct, only supports TLS 1.2 at this stage. There is no such Esri documentation as yet that I'm aware of. My statement regarding TLS 1.3 was in relation to JRE / Java security roadmap / roll outs / bug fixes that I discovered in the Oracle Java Bug Database. Thanks, Dean
... View more
01-09-2020
05:52 AM
|
0
|
0
|
161
|
Online Status |
Offline
|
Date Last Visited |
a month ago
|