Error after Changing Collectors Route and Geocoding Services

[BenGrod]

A published a routing and geocoding service on our ArcGIS Server (10.2), added it to my content on ArcGIS Online, and successfully utilized the routing and geocoding services in a web app. I'm now trying to use those services in Collector. I modified my organizations Utility Services to point at the routing and geocoding service (added my locator above the Esri World Geocoder). Now when I try to geocode with Collector I get "no results found" and when I select a feature and get "Direction to here" it returns the following error: "Unable to determine a route to the destination. AGSCredential Required"

I'm interpreting that as an ArcGIS Server Credential is missing? I even tested this while on my company WiFi and VPN into our network. Is there some additional setting on ArcGIS Server that I need to apply or change so that Collector can consume the service? Thanks in advance for your time and help.

[RussRoberts]

Did you sign out of the app and log back in after you switched the route/geocoding services? The app only grabs the "portal info" upon login so if you changed those utility services and did not log out that could explain the issue.

Also if these services are added as items with credentials embedded make sure they are shared to your org so they are accessible to the users in your org.

Russ

[BenGrod]

Russell, thank you for the suggestions and I certainly thought it would solve my problem because after checking the ArcGIS Server Sharing settings I wasn't logged in to Portal. I logged in to ArcGIS Server, added our corporate ArcGIS Online URL (http://apache.maps.arcgis.com/) to the Portal URL and signed in. I then navigated to the services and updated the sharing properties (shared to Organization). I signed out of Collector/back in and tested geocoding and routing, both still return the same results.

Looking in to it further I wonder if it has anything to do with our ArcGIS Server Security Settings? We are currently set to: Users and roles from an existing enterprise system (LDAP or Windows Domain)

[RussRoberts]

Do you have those services Route and Geocode added as items under the admin for the portal account with the credentials stored with them? Then you share them to your Portal and Also have them set as the Route service and the primary geocoder and that should then work with your custom services. Also make sure you use the URL listed in the item detail page and not the AGS URL.

[BenGrod]

Russell, thanks again for your continued support. I think I will post a ticket with Esri so I can share more information and get to the root of the problem. In the mean time here is my current status. I believe I have everything set up as you mentioned above but I do not have credentials stored with either of the services. My ArcGIS Server Security Settings use Windows Domain for User and Role Store and Web for Authentication Tier and Mode. I do not see the option to store credentials with the services. My URL's are both the ArcGIS Web API REST Connection for each service, as in the below example. 

Geocoding URL

http://ags-mobile/arcgis/rest/services/Mobile/USA_Apache/GeocodeServer/

Routing URL

http://ags-mobile/arcgis/rest/services/Mobile/RouteServiceAoi/NAServer/Route/

[BenGrod]

Russell, I created a ticket with Esri yesterday and I've been corresponding with them today. Not sure where this will go or how long it will take but I will certainly revisit this posting to acknowledge any issues identified and resolutions. Thanks again for all your help

[BenGrod · Accepted solution]

Russell, I saw your status has you moving to support ArcGIS Online and the Scene viewer products. Good luck with that and thank you for all your previous Collector support! On this particular discussion issue (Collector consuming Route and Geocoding Services) it appears the issue is with our server and security configuration. Our ArcGIS Server Service REST endpoints are not publicly facing/accessible. Esri Support was able to help me identify this and suggest solutions which will require me to work with my local IT to make the web address public. Working on that now along with an alternative solution of hosting everything on Portal (not set up yet) and having the mobile users required to be signed in on VPN. Thanks again for all your help!

[RussRoberts]

Thanks Ben!