Latest Contributions by RyanUthoff

‎07-17-2020

I have discovered what I believe to be a bug in Survey123 that I am able to replicate in multiple forms in two different ArcGIS Enterprise (10.6.1) environments. In my survey, I have a hidden field with a "bind::esri:fieldType" of "esriFieldTypeInteger." Just for reference, we populate that hidden field from a URL in a web map. When we submit a survey with that field being null, it will be written to the data store table as being null (and I can verify that by looking in the hosted feature service and seeing it being null). However, if we edit and re-submit that existing survey through Survey123, it will change the value in the hidden field from null to 0 (again, by verifying that value in the hosted feature service). Luckily, if a value is already populated in the hidden field and then you re-submit a survey, it will not change the field value to 0. It will maintain the value. It only changes the value to 0 if the original value is null. Is this behavior to be expected? I don't see why the field value would get changed from null to 0.

‎07-17-2020

I am referring to ArcGIS Dashboards. I apologize if my terminology was incorrect, I refer to the Dashboard pie charts, gauges, etc. as widgets. It turns out the issue was a spatial index issue. The widgets in question were views and not the base tables, and the indexes we have access to through Esri weren't helping. Luckily our DBA was able to create some additional indexes through SSMS that greatly improved the performance.

‎07-10-2020

I am experiencing some poor dashboard performance and I'm not sure how to determine the root cause of the issue. I am running ArcGIS Enterprise 10.6.1 and all of the data is hosted in MS SQL EGDB using a regular feature service. I am not using any hosted feature services for this dashboard. The web map itself is running fine. I can pan around, scroll in and out and the web map is very responsive. I have no performance issues within the web map itself. When I use that same web map and put it in a dashboard and start adding widgets, the dashboard performance is very poor. The widgets will just sit there and load for a minute or two, then I get a yellow exclamation mark saying "Cannot access data." If I refresh the dashboard web page 3-5 times, eventually all of the widgets load. When viewing the internet traffic, I can see that a lot of the requests eventually time out after one minute. I check the ArcGIS Server logs, and I do not receive any error messages. No time out errors or anything. When I check the number of instances the feature service is using, it is using about 5 of 16 instances, so I am not running out of instances. There are about 20,000 records in the tables, but I set the maximum number of records to be returned by the server well above 20,000. Also, the maximum time a client can use a service is 600 seconds. At this point, I am kind of at a loss of what this issue could be besides it being a limitation of the dashboard widgets. I would have thought that the dashboard would be able to handle widgets pulling from tables with 20,000 records, but maybe that is too much for the dashboard to handle? Any suggestions or troubleshooting steps I could look into?

‎06-24-2020

I am having issues importing a custom widget into Portal in ArcGIS Enterprise 10.6.1 and I am not sure if I am doing something wrong, or if it is just a limitation of Esri. When I add the custom widget URL in Portal, after entering the Manifest URL, I receive the following error message: "Unable to load https://<gis.domain.com>/portal/sharing/proxy?https://<apps.domain.com/manifest.json status: 400." There are two different servers. One that hosts all components ArcGIS Enterprise, and the other which hosts the custom widgets. Both are publicly accessible and the widget URL is fine as I can access it normally through a web browser with no errors. But that URL does not work when I try to import it through Portal. If I use the machine name URL for the custom widget, Portal is able to import the widget fine. But if I use the publicly accessible URL, it does not work and I receive the error message above. Any ideas on what could be causing this error message?

‎05-26-2020

Another way you can troubleshoot is open the map in a web browser, then right click the URL and click "Copy link address" or whatever option it gives you for whatever web browser you use, then paste in a word document. You will be able to see if the GUID is passing through to the URL or not because you will be able to see the field values in the URL itself. This applies to any fields you are transferring over from Collector to Survey123. It will at least tell you if you have your URL configured correctly.

‎05-26-2020

The one thing I noticed right away is that you should be using the curly brackets {} instead of the regular brackets in your Survey123 URL. Edit: I read the documentation you provided and Esri is using regular brackets. With that being said, I've only seen Esri use the curly brackets in all of the other documentation I have read.

‎05-26-2020

I opened a case with Esri support and they concluded that it is a bug, most likely with Runtime. They said that they are aiming to fix this bug in the next release of Explorer, but it would probably be 3-4 months before it is released. Unfortunately, we are still stuck on Collector Classic and Explorer version 18 until this bug is resolved.

‎05-15-2020

I opened a case with Esri support and they were able to replicate the issue and confirmed it is a software defect. For anyone else who encounters this bug, it is: BUG-000130888: Register with Geodatabase - Error 999999: Something unexpected caused the tool to fail.

‎05-12-2020

I have recently updated to the latest release of ArcGIS Pro (2.5.1) and it has partially broken the Register with Geodatabase tool. While non-spatial tables continue to register fine, I am no longer able to register spatial tables with the geodatabase. I originally found this issue when attempting to use my Python script to register the tables, but I was also able to replicate this behavior when using the tool within ArcGIS Pro as well. I received two variations of the same error message, one through ArcGIS Pro, and one when my Python script fails. I've attached those error messages. I reverted back to ArcGIS Pro 2.5 and the Register with Geodatabase tool works again (on the exact same table in the same database I was trying to previously register). I was able to replicate this behavior in two different environments as well. It looks like ArcGIS Pro 2.5.1 is a no go for us until this issue is resolved. The tables we are trying to register are within a Microsoft SQL database.

‎05-01-2020

This is a very informative post, thank you! I do have a question regarding the ArcGIS Server Administrative URL. Let's say we initially deployed ArcGIS Enterprise as a single machine deployment and initially configured the Administrative URL using the machine name. But later, we added a second machine to the site but did not re-configure the Administrative URL to point to the web adaptor URL. Obviously we want to change that Administrative URL to point to the web adaptor URL so the server is truly HA (we had the machine referenced in the URL offline for an extended period but luckily our services still continued to work from the second server, but we did lose some functionality such as publishing S123 forms). Are there any concerns with just changing that Administrative URL to the web adaptor URL? I see there is documentation regarding this, but I'm curious to see if there are any concerns or potential issues when changing the URL (such as broken feature/host feature services, etc.). All of our services are published using our web adaptor URL. Configure an existing ArcGIS Enterprise deployment for high availability—Portal for ArcGIS (10.6) | Documentation for …

‎04-20-2020

I had this same issue and it was infuriating. I was trying to join a second machine to our existing site and I received this error message late at night as I was trying to do this during non-production hours (and this was after a couple of months of troubleshooting with Esri support on why I wasn't able to add a second machine to our site, un-related to the license issue though). I was in a similar situation as you. I had a VM where I previously installed server and attempted to join it to our site. Part of the troubleshooting process (again, not for the license issue) was to un-install and re-install server. So that's what I did, but even though I used the same authorization file, it still wouldn't like the authorization file. I had to do a complete un-install and remove all evidence of any Esri files in the Program Files directory. Then finally do a fresh installation and it accepted the authorization file at that point. If possible, I'd recommend installing server on a fresh VM. But I know that's easier said then done.

‎04-15-2020

You mention that the reason why you changed the location for sideloaded content in Explorer is because of upcoming restrictions in Android. I'm assuming these restriction changes will be coming in a future Android update? The reason I ask is because Explorer 20.1.0 currently does not work in our ArcGIS Enterprise environment (it's a long story, but the issue seems to be something with the newest version of Runtime because the new version of Collector also does not work, but Collector "Classic" works fine). I have already submitted a ticket with Esri support about this. With that being said, Explorer 18.1.0 works fine. With the Android restrictions coming, is it possible that if we update our Android devices to the version of Android that includes these restrictions, that it will break the Explorer 18.1.0 app with our sideloaded content? This could be problematic as we already had to roll back several users to 18.1.0 and then a future Android update will break the only functioning version of Explorer that we have.

‎03-04-2020

I am suddenly getting error messages when trying to open maps from ArcGIS Enterprise in Explorer for ArcGIS on Android and Collector for ArcGIS on iOS. When I open a map, then click the layers button, I get an error message under all of my layer names stating "User cancelled authentication challenge." It worked perfectly fine yesterday, but it no longer works today. We did not make any changes to our internal network, so I don't know why it's giving me an error message now. I will add that the web map works perfectly fine when accessing it through Portal (and when using the same account for both Portal and Explorer). We are able to successfully sign in to Explorer, and it never asks for any additional credentials, so why would it say the user cancelled the authentication challenge when it never even asked me?

‎03-02-2020

Is there a reason why GNSS Metadata is not supported on iOS? Having GNSS metadata is pretty important and I would like to understand the reasoning why GNSS metadata is not supported on one platform but is supported on another platform. We would like the flexibility to be able to be able to switch OS platforms with an R2 unit while still receiving the same functionality, including having GNSS metadata.

‎02-20-2020

We're experiencing an "issue" when users re-publish feature services in ArcGIS Pro and ArcGIS Enterprise and it un-shares it with the group it was previously in. Below is an example of the issue. I publish a feature service and share that feature service to a group. A second user (who is also an administrator in Portal) re-publishes the feature service, but it un-shares that feature service with the group if that user is not a member of the group. We never had this issue in ArcMap, so I don't understand why it's an issue in ArcGIS Pro. If you're an administrator, you have access to every single group in Portal, even if you are not a member of it. So I don't understand why it would un-share it with the group. I realize that it is an "easy" fix to just become a member of a group, but some users don't know what group a feature service is a part of and it's an inconvenience to go to the feature service, see what groups it is a part of, and verify that they are a member of the group. Plus, there is the added inconvenience that you (even as an administrator) can't even add yourself as a member to an existing group. You either have to ask someone else to add yourself, or change the owner of the group to yourself which doesn't make sense because you're not allowed to add yourself as a member, yet you can change the owner of the group to yourself. Again, this issue did not exist in ArcMap. This is a pretty annoying inconvenience. I propose that re-publishing feature services in ArcGIS Pro does not un-share it with any group if the user who is re-publishing is not a member of that group.

Online Status	Offline
Date Last Visited	Thursday

My Ideas

Latest Contributions by RyanUthoff

Survey123 Re-Send Survey Bug

Re: Poor Dashboard Performance

Poor Dashboard Performance

Importing a Custom Widget into Portal Error

Re: Feature GlobalID not passed to related table in Survey 123

Re: Feature GlobalID not passed to related table in Survey 123

Re: Explorer for ArcGIS Error - User Cancelled Authentication Challenge

Re: ArcGIS Pro Update (2.5.1) Partially Broke the Register with Geodatabase Tool

ArcGIS Pro Update (2.5.1) Partially Broke the Register with Geodatabase Tool

Re: Planning Load Balancer Configuration for Highly Available ArcGIS Enterprise

Re: ArcGIS Server multi-machine license doesn't match

Re: Migrating Sideloaded MMPKs from Explorer Android 18.1.0 to 20.1.0

Explorer for ArcGIS Error - User Cancelled Authentication Challenge

Re: Direct GNSS external receiver support in Survey123 3.3

Do Not Un-Share Feature Services when Re-Publishing in ArcGIS Pro

Re: How have Orgs worked around related tables and...

Create Multi-factor Authentication Groups in Porta...

Re: Access Postgre from Datastore

Re: Cannot Change User Type?

Re: Cannot Change User Type?