Latest Contributions by danbecker

‎08-24-2017

Server was federated to Portal. Server was configured as the hosting server, Data store was also configured. Everything was working great at 10.5, but I wanted to upgrade, latest is greatest, right? This ended up being a 2AM nightmare. Rather then keeping these notes to myself, I thought I'd share. Portal 10.5.1 Upgrade, Registered survey123 app Portal (linux) update failed when attempting to create the initial site administrator account. Looking in the portal database logs, there was a problem when attempting to execute data.sql, specifically the INSERT statement dealing with survey123. This is because I already had survey123 configured as a registered App so that we could use the survey123.arcgis.com website against our own portal. I understand this was in Beta with 10.5. As soon as I commented out that line in the data.sql file the initial site admin account could be created, no more errors. CAUTION: If you have survey123 added as a registered application at 10.5, then attempt to 10.5.1 upgrade, you will likely experience the above error. Portal 10.5.1 Upgrade, Webadaptor Re-install After portal was upgraded to 10.5.1, I uninstalled/re-installed it's web adaptor. Same for Server, after it was upgraded to 10.5.1, I uninstalled/re-installed it's web adaptor. I logged into the Portal and tried to open an existing web map and would only get an IdentityManager popup, asking for credentials for the arcgisServer.local.domain machine? Server is federated with Portal, why would I bet directed to Server for a token? After troubleshooting further, all previously published feature services were working correctly, no auth. popup box. It was the offline basemaps (actually webmaps) that I had configured. Why can't ArcGIS Enterprise users simply use ESRI basemaps offline like you can in ArcGIS Online? We have to complete this extra step, outlined last section of this page: Prepare maps for offline use—Collector for ArcGIS | ArcGIS I looked at my offline basemap(s) in Portal, details page, and the Service URL was arcgisServer.local.domain/portal. That's WAY wrong and would never be reachable outside our LAN. Not to mention it's the Server hostname and portal web adaptor name. Changing the URL to FQDNDNSAlias.com/portal worked right away, I was able to get to the rest endpoint of the basemap. Devil is in the details. Look at this page: Configure ArcGIS Web Adaptor—Installation Guides (10.5) | ArcGIS Enterprise, Step #2. "If a DNS Alias will be used with the portal, the Web Adaptor should be configured over the DNS Alias instead". So, after the portal web adaptor is installed, you have to access the web adaptor config. page on the machine it's installed on, but you have to use the same externally accessible DNS Allias, so https://myexternallyfacingFQDN.com/portal. Then you will reach the portal configure page where you enter the arcgisPortal.local.domain:7443 URL. After this step, the Service URL of any item you add to your portal via a URL will correctly display as https://myexternallyfacingFQDN.com/portal/item..... Portal 10.5 Restore via RestAPI/Importsite I cannot restore (or backup) using the portal webgisdr utility since my deployment is a mix of Linux/Win. So, I individually backup Portal using the exportSite REST API and backup Server using the serverbackup.py utility. Initially I didnt' figure out the above portal web adaptor fiasco so I decided to uninstall portal 10.5.1 and go back to 10.5. Uninstall went fine, deleted the /arcgis/portal directory. Re-installed 10.5 and when I got to the initial admin. account setup, I entered the same initial admin username as before, portal_admin. I then went to arcgisPortal.local.domain:7443/arcgis/portaladmin/importSite. I specified the full path to the .portalsite file and waited, fingers crossed. After 10 minutes, Error. I looked in the portal/database logs and found an error related to INSERT "gw_" does not satisfy the unique key requirement, VALUES 'portal_admin'. To my novice SQL eye, this looks like the restore was attempting to INSERT username portal_admin from the backup, when I had already specified portal_admin during the intial admin. account config. So, I uninstalled 10.5 and re-installed again, this time when I got to the initial admin. account config. I entered tmp_admin, then the /importSite operation succeeded!! FYI, since Server/Portal were federated, I was a little unsure of the restore order, here's what I used and it worked great: Uninstall Portal, Server, and both web adaptors re-install Portal, configure a new/unique initial site admin account re-install Portal web adaptor. Remember my DNS Alias point above, this is what got my into my 2AM nightmare. re-install Server re-install Server web adaptor navigate to arcgisPortal.local.domain:7443/arcgis/portaladmin/importSite, specify the full path to the .portalsite file Cross fingers. Our site is pretty small and it took about 30 minutes. To my surprise, the importSite REST operation also restored all Server Services. I'm assuming this is because Server was federated. I did not need to run the restore.py utility on the Server machine.

‎06-28-2017

I've noticed this in almost all version of Collector including the latest. I add a cached map service to a web map and enable pop-ups on it. The cached map service has the option checked to download 10,000 cache tiles. On the web map the popups work as expected. Viewing the map in Collector while online, the pop-ups continue to work as expected. But, as soon as the map is downloaded and taken offline on Collector, pop-ups no longer are displayed in Collector. Is this expected behavior or am I doing something wrong?

‎06-06-2017

Since we are just starting to use our Enterprise implamentation of 10.5 this week, I got to the office this morning to a barage of emails from all field staff saying they're getting a sync error!! After some troubleshooting, I realized that all feature services were published to Portal by user: portal_admin, thus owned by portal_admin.Each field staff user has their own named user account in Portal, "publisher" role, and each downloaded the map to take if offline. The users could not sync, but the portal_admin while testing was not having any issues. My workaround was to create a new Role in Portal that included "editing with full control" permission. This solved the problem. Now that I know this is a reported issue, I will install the patch. Thanks for pointing this out!!

‎06-06-2017

I just figured it out... I was accessing the rest endpoint of the server w/out the web adaptor. Doing so apparently hides the replicas. https://servername.activedirectorydomain:6443/arcgis/rest If you access the rest endpoint through the web adaptor, then you can see the replicas: https://webadaptor.domain.com/arcgis/rest

‎06-06-2017

Yes, we've used Collector for years, just recently switched to ArcGIS Enterprise Standard with a federated on-premis Portal and Server implementation. I just can't figure out why we cannot view replicas at the Server rest endpoint?

‎06-06-2017

Yes, map was downloaded in Collector. We even dropped a few test points in Collector and they syncd fine. I've never worked with a federated portal/server and datastore. Perhaps this is a result of that? A known issue with 10.5? Just seems odd. Im waiting for all of our field staff to start calling saying they're getting sync errors!

‎06-05-2017

Server 10.5, federated with Portal 10.5. SDE gdb is stored in PostgreSQL 9.5.7. Server, Portal and PostgreSQL are running on different VMs. We can successfully download a map using Collector, sync's are also working correctly. But, why can't we see the replicas when browsing the feat. service rest endpoint? The replica page of the appropriate feature service is totally blank?? thanks.

‎06-01-2017

I used the Create Database User tool, then added user DBO to the new postgreSQL db. I then connected to the postgreSQL gdb as user DBO and was able to import the .XML workspace file. Now, when I try to register the postgreSQL gdb.sde connection file with ArcGIS Server, I get this error: "Machine: <ArcGIS Server machine> [<reg. db name>: The connection property set was missing a required prooperty or the property value was unrecognized. Bad login user]" Doesn't matter if I edit the .sde connection file to connect as postgres, sde or DBO user, they all give the same error above when attempting to register with ArcGIS Server. edit: got this figured out! Looked at the PostgreSQL log and saw entries: "<ArcGIS IP Address> not granted access in pg_hba.conf" Then remembered, I restricted PostgreSQL client access to a single workstation (mine) for testing... Added in the entire LAN and now everything is working!! thanks again.

‎05-31-2017

Have several sde geodatabases stored in SQL Server Express instance. Just created new Linux Ubuntu instance of PostgreSQL, added st_geometry.so file to /lib. I used the create enterprise geodatabase tool in ArcMap; sucessfully created sde gdb on PostgreSQL server. To migrate the data: 1) export XML workspace file from SQL server sde gdb 2) attempt to import the XML workspace file to the PostgreSQL sde gdb Error: "database user name and current user schema do not match". Can someone explain how to migrate the data to new PostgreSQL instance? thanks.

‎05-23-2017

We are moving forward with the upgrade from workgroup to ArcGIS Enterprise Standard. Also upgrading from SQL Server Express to PostgreSQL. Purchased the following server: Supermicro Mobo 12 core Xeon processor 64GB RAM 1x250GB 7.2K RPM SATA drive 8x600GB 10K RPM SAS drives Supermicro (LSI) SAS RAID controller Total of 6 intel NICs (each VM will have a dedicated NIC port) Created a single RAID10 Volume (OBR10); total size 2.4TB. Installed Hyper-V Core (no GUI) on the SATA drive. Here's how we plan to breakdown the VM's: VM1 -- MS Server 2012 R2 Std; 1 CPU Core; 8GB RAM 1 VHD (dynamic) for everything; 128GB Domain Controller IIS ArcGIS Web Adapter VM2 -- MS Server 2012 R2 Std; 4 CPU Cores; 24GB RAM 1 VHD (dynamic) for everything; 256GB ArcGIS Server VM3 -- Ubuntu Server 16.04 LTS; 4 CPU Cores; 16GB RAM VHD (dynamic) for OS; 64GB VHD (dynamic) for data; 500GB PostgreSQL VM4 -- Ubuntu Server 16.04 LTS; 3 CPU Cores; 16GB RAM VHD (dynamic) for OS; 64GB VHD (dynamic) for data; 500GB Portal for ArcGIS ArcGIS Data Store Questions: The guest OSs are all supported, I checked that. But what about the distribution of system resources? We only have 2 licenses for Win Server 2012. Would it be better to have fewer Linux VMs, or more? More or less VHDs? For Win server, we usually have os.vhdx and data.vhdx. The data drive stores network share data. Should we continue that for ArcGIS Enterprise? thanks in advance

‎04-19-2017

I finally got a survey that uses repeats working with a non-federated 10.3.1 feature service. The trick was to create a GUID field (NOT GlobalID) in the parent point layer, then use the field as the primary key in the relationship class. The foreign key (child table) also uses a GUI field.

‎04-05-2017

I did not make any headway in getting a read-only value to populate in survey123. I just told all the field staff to NOT TOUCH the ID field that was pre-populated from Collector. The ideal scenario would be to use survey123 hidden field, then field staff won't even ask a question.

‎04-04-2017

Thanks James. The above documentation does not list the requirement for the relationship to have the same name in each direction. I just ended up publishing a hosted feature service on AGOL rather then trying to use our un-federated server. However, I still cannot export a FGDB from the hosted feature service. I can create a replica FGDB from the parent layer serviceURL, but if I go to the hosted feature service item details page, and hit "Export/FGDB" it always errors out. I would assume the issue is with the relationship class created via the repeat in the survey123 connect markup. I also tried to add the hosted feature service to ArcMap 10.3.1 from the "my hosted services" folder. The parent point layer displays fine, but the related child table errors when trying to open it "could not load data from the data source....". I also tried to "create a local copy for editing", and got another error "a general error when something is wrong with a field [parentglobalid]." Perhaps all these errors are related to my 10.3.1 deployment of desktop and server? Regardless, there seems to be issues with repeats and relationship classes. I need to move the feat. services onto our own server now that I know about the relationship naming requirement. Then I could just use the data locally in our own SDE GDB; lot less hassle.

‎04-04-2017

@Tony; thank you so much for posting this. We also had this exact same thing happen. All feature services for survey123 were hosted on AGOL. After the first round of field work we attempted to download all data from the hosted feature service as a FGDB, but we just get "error downloading the FGDB". We use repeats and the relationship class appears to break FGDB export routine on AGOL. Creating a replica from the ServiceURL as FGDB works w/out issue, but you don't get the related table. Easy enough; it's exportable in CSV format. Like you, we edited the schema in survey123 connect, then republished to AGOL. All field staff deleted the old survey and downloaded the new one. After collecting data for a day, 1 person tried to sync their survey records and continually got the "getting service information" nag. The role of this user was restricted, but after checking the "view all" and "update" permissions as indicated in your screenshot, they were able to sync w/out issue. Again, thanks. I would have wasted a day figuring this out.

‎03-25-2017

Server 10.3.1 not federated. I followed the above documentation to get a survey123 repeat working to no avail. I tried every combination of globalID, GUID, parent--child relationship in the feat. service relationship class to no avail. After publishing the feat. service, I added the REST feat. service endpoint URL as an item to AGOL, saved the credentials with the item, then included that arcgis.utility....URL in the xlsform service_url field. The name of the repeat was exactly the same as the related table name in the feat. service. Using survey123 connect, every time I tried to publish the survey to AGOL, I would get the error, "parent relationship <relationship name from child to parent> not found from <related table name>". If I re-publish the feat. service w/out the relationship class, then re-publish the survey w/out the repeat, everything worked great, and we are able to host the survey123 feat. service on our non-federated server. Which is ideal for us since we are running low on AGOL credits. Another issue: I can publish a survey123 repeat to AGOL, the hosted feat. service is automatically created in AGOL and everything works as expected. HOWEVER, if you try to download the hosted feat. service as a FGDB it fails because it contains a relationship, i.e. related table. If you download as .csv everything works as expected. Looks like a few more relationship bugs exist.

Online Status	Offline
Date Last Visited	Friday

My Ideas

Latest Contributions by danbecker

Upgrade to 10.5.1 and Resotring a 10.5 Site, Cautionary Tales

No Popup Window offline Cached Map Service

Re: I keep getting errors when I try to Sync my Collector map back onto our Server

Re: replicas not listed

Re: replicas not listed

Re: replicas not listed

replicas not listed

Re: How to migrate SQLserver data to PostgreSQL?

How to migrate SQLserver data to PostgreSQL?

Re: PostgreSQL as alternative to SQL Server Express

Re: Survey123 Error: Global id based relationship requires support for applyEdits with GlobalIds

Re: pass data to Survey123 note or hidden field not working

Re: Survey123 Error: Global id based relationship requires support for applyEdits with GlobalIds

Re: BUG: Getting service information

Re: Survey123 Error: Global id based relationship requires support for applyEdits with GlobalIds

ESRI Survey123 Website Sending Report API Requests...

Re: Portal for ArcGIS upgrade from 11.5 to 12.1 no...

Re: Azure Files premium file share - SLOW File Geo...

arcpy layout.export - hosted feature layers not sh...

Re: Survey123 Date Only shows incorrectly on Repor...