Latest Contributions by pfoppe

I realize this thread is related to Oracle databases, but we had a similar error message with a back-end SQL Server environment.   Cross posting for good measure... here was our fix on SQL Server - https://community.esri.com/thread/248923-collector-offline-map-sync-failed-unknown-error-occurred#comment-942437  ... View more

Quick followup.   I engaged in the UC2020 virtual and an Esri  rep confirmed this is not possible.   Instead suggesting placing the data store on a dedicated machine, and scaling the Hosted Server site vertically (adding resources) or horizontally by adding more machines.  It should scale to a multiple machine site like any other federated site.  ... View more

Hi Jonathan Quinn‌,  We have not opened an esri support incident on this yet, we actually discussed doing this today.  Esri support was able to reproduce the issues of the C:\ to D:\ content migration (referenced above) and I suspect this is related to that.   When we start to run out of C:\ space, we manually purge some of these walarchive files to keep the system operational.  Thanks ... View more

Hi Jonathan Quinn‌, We have a situation where we are running weekly full backups (using webgisdr) and daily incrementals, but the C:\<portal_dir>\backup\walarchive folder is not being cleaned up after a webgisdr full backup.  This is chewing up the available C:\ space and we have been manually purging some of these files that are over 60 days.   Per the Common problems and solutions—Portal for ArcGIS (10.8) | Documentation for ArcGIS Enterprise The portal content directory has grown to several gigabytes in size Once you run a backup using the webgisdr tool, this limit is removed, but the transaction logs are cleared each time the tool is run. We have a few ArcGIS Enterprise deployments, and this is the only one causing problems.  It is also the only environment we (unsuccessfully) attempted a portal content C:\ to D:\ migration... so I suspect the situation is that the webgisdr utility is trying to purge the D:\<portal_dir>\backup\walarchive instead of the C:\ location... thus leaving these behind for us to have to clean up manually.  GeoNet reference to that thread - https://community.esri.com/message/904321-re-moving-arcgis-portal-directories#comment-929961    Thoughts on this issue?  I suspect the suggestion will be to open a new support case (referencing the support case and bug logged on the referenced thread).   Thanks! Leeah Risher‌ ... View more

We had opened a case on this and Esri support was able to reproduce the issue; the following bug was logged: BUG-000129131 - "Despite updating the content path for Portal for ArcGIS to a new physical drive, the application still calls the original drive path" Outside of the bug, the only other options presented was to try and migrate to a new machine with the correct content directories as documented here - Migrate to new machines—Portal for ArcGIS (10.7 and 10.7.1) | Documentation for ArcGIS Enterprise  We have not tried that yet. ... View more

We too have started to experience this situation in our ArcGIS Enterprise v10.7.1 environment.   Quick Tech Details:  ArcGIS Enterprise v10.7.1 - MS IIS, Web-adaptor for portal & server, hosting server & federated (non hosting) server. This was upgraded from v10.6.1 Publishing from back-end SQL Server 2017 (running Enterprise Geodatabase v10.6.1) Published with a SQL "editor" account (not the data schema owner) If we publish the service with our data schema owner, then the offline download/sync functions as expected.  If we publish with a built-in SQL Server "editor" account, then the sync fails with the same behavior mentioned in this thread "No path for delta data changes".  All other references we searched for were related to the ORACLE "create table" issues.   We deployed a feature service with this configuration (sync enabled and published with a built-in SQL 'editor' account) when we originally built the ArcGIS Enterprise environment at v10.6.1 and were successful with offline sync then. Seems possibly related to the v10.7.1 upgrade? We may try to upgrade the back-end Enterprise Geodatabase to v10.7.1 to see if it resolves, but expect it to continue to fail.   The back-end SQL Editor account has full "Insert/Create, Update, Delete, Query/Read" permissions on all back-end database tables (including their underlying 'a' and 'd' tables in the traditional versioned configuration). The SQL editor account also has "connect, create table/procedure/view/function" permissions.   Any help is appreciated.  Thanks. ... View more

We had a similar issue with one of our implementations.  In our case, the machine was built out in our central, corporate data center.  We then boxed it up and shipped it to one of our offices and (at some point), trying to access hosted feature services failed with the error:  FATAL: no pg_hba.conf entry for host "<new_ip_address>", user "<redacted>", database "<redacted">, SSL off I used the allowconnection datastore command to forcibly add the (new) IP, User, DB connection - ArcGIS Data Store command utility reference—Portal for ArcGIS (10.8) | Documentation for ArcGIS Enterprise  Wierdly enough, we have a few similar implementations where we built out the system in a different location than where it is running and they are not experiencing the same issues...   And concerning that this is tied to an IP address as we do NOT set static/reserved IP addresses on our machines unless there is a known need (like firewall ACL rule or DNS alias resolution).   This is a pretty straight forward 10.7.1 setup with all ArcGIS Enterprise components running on the same host (IIS, web-adaptor for portal & server, portal, server, datastore).  No image server.  No Geoanalytics.  Jonathan Quinn‌ - thoughts on this?  Thanks!! ... View more

Yes, very good points!! ... View more

This it us again today, and I forgot the fix... so had to re-discover.  GAR The root cause was our C:\ hosting the install location ran out of disk space.  So I think the product tried to write to the file and couldn't and ended up writing a 0 byte file.... ... View more

Thanks for the feedback.  We have fixed all the webgisdr.properties to use a UNC for the shared loc (on the portal server itself), then a DFS path for the backup loc.   From your feedback, I think only the portal server accesses the BACKUP_LOCATION, hence why that could reference a local drive on the portal server (to speed things up)?  And that might make the process faster (since its local and will minimize network traffic)? I think for now, we will leave the BACKUP_LOCATION on a DFS path as the file system on that DFS path is being backed up by our corporate backup solution... that will prevent us from having to do a robocopy (or like) to that DFS location after the webgisdr utility has finished.  Although... I'll keep this in my back pocket in the event the webgisdr backups become un-sustainable (taking to long).  At this point, we plan to only run a weekly FULL and daily INCREMENTAL in the middle of the night... so I suspect they will be finished long before our normal business hours.   Thanks! ... View more

Thanks for the reply Jonathan Quinn‌! I found a few hints that may have caused this... We started running backups in this test environment on 1.8.2020 and both the "SHARED_LOC" and "BACKUP_LOC" were on a distributed file system.  The backups were taking quite a while so one of our SA's was testing out migrating the SHARED_LOC to a local path on the portal server and leaving the BACKUP_LOC on a network location.  Looking through the webgisdr logs (on this date), it looks like during that testing some of the webgisdr.properties were not valid.. Specifically... there was a C:\shared_loc reference in the properties file and so the federated servers (and datastore) that live on different machines were failing to write and logged an error:  Cannot access the file C:\Loc\SHARED_LOC\WebGISSite1578958815609\server\<redacted>\January-13-2020-at-4-40-53-PM-MST.agssite. Exiting the WebGIS DR utility. I remember consulting with the SA that it had to be a UNC path, so I suspect the webgisdr utility pre-maturely failed and left them behind.   Again... thanks for confirming that we can remove these! ... View more

Thanks Jonathan Quinn‌!  I'll work up a support case.  ... View more

Help!  We have the same problem.  We have been able to move the following:  LOGS - portaladmin/logs/settings CONTENT DIR - portaladmin/system/directories/content DB - portaladmin/system/directories/db TEMP - portaladmin/system/directories/temp INDEX - portaladmin/system/directories/index Using Process Monitor, we can see the ArcGISPortal.exe is accessing content in the old:  C:\content\dsdata\... C:\content\<ugly_looking_guid>.dat C:\content\backup Furthermore, there is an arcgis-data-store-config.json file at C:\content\dsdata\etc that has a lot of references to the C:\content folder still Ultimately our objective is to move the entire C:\content folder to a D:\ Thanks for any suggestions! Jonathan Quinn‌ - Thoughts??? ... View more