publishing/paths issue with supporting files

[nathanaamot]

I've run into this issue a few times with the v1.2 of the tools (running ArcGIS 10.4.1). I think it is isolated to arcgis server sites where the config-store and directories locations have been reconfigured to us a shared drive location such as a NAS file share. I have one system where the config-store and directories are local (C:) and another system where they are in a shared location. This issue only seems to happen with the shared location configuration.

The issue is a failure to update the published path of the "ndsupportingfiles" folder in the serves. This causes failures with the routing tool and other solvers. Digging through the network traffic I've found an error where the services are trying to find the "defaulttravelmodes.json" file this path:

"original publishing location"\0\v101\ndsupportingfiles

rather than where they should be found in:

\"sharedrivelocation"\arcgisserver\directories\arcgissystem\arcgisinput\Routing\NetworkAnalysis.GPServer\extracted\v101\ndsupportingfiles

If I replicate the exact path the service is looking for (path to original publication location) on the server and copy the ndsupportingfiles into that location, this repairs the issues with the services not functioning properly.

[deelesh]

@nathanaamot In your workflow, If you first setup your ArcGIS Server to use file shares for the config-store and server directories and then publish services using PublishRoutingServices tool, do you run into the same issue?

Another thing to try is to republish the services (from the service definition) after you have changed the server directories and the config-store to use a file share. To do this,

1. From ArcGIS Server manager, delete the Routing folder. (This will delete all the services in that folder).
2. Using the Publish Service button in ArcGIS Server manager, republish all the services one by one using the service definition files (.sd files). You can accept the default values when publishing the service. The sd files should be in the folder that you specified as the Service Definition Folder parameter when running the PublishRoutingServices tool.
3. Test if the services work fine.

[nathanaamot]

Hi @deelesh - Yes, my implementations have been set up as described above from the outset. One where they use file shares, one where config-store/directories are stored locally (C). I can try republishing from SD files but given your reply I'm not sure this would be relevant. Thanks!

[deelesh]

@nathanaamot On my side, I tried a 10.4.1 setup where the config store and server directories were on a file share and then published these services. Everything worked as expected and when executing services, I was able to confirm that the services were reading the files in the ndsupportingfiles folder from the file share.

I also did another test where initially my config store and server directories were on a local drive and I published the services. Everything worked as expected. Next I updated all the server directories to point to a file share. Now if i run the services, they correctly read the ndsupportingfiles from the file share.

So i can say that I am not able to reproduce the issues you are encountering.

[nathanaamot]

Hi @deelesh - We have upgraded to 10.5.1 and I followed the instructions for the tools v2.0 to remove the routing folder etc and republish from the script. I'm still having the same issue as indicated above where the services are not looking for DefaultTravelModes.json in the published service location. I also tried your suggestion of deleting and republishing from the .sd files. Still same issue. I have attached the PublishRoutingServices.log file and some screenshots of our server configuration and the error in the server logs. Hopefully this provides some additional insight for you as to why the service publication process does not appear to update the ndsupportingfiles folder path as intended. Thanks for providing a great package. Our work around for now is to create a copy of the ndsupportingfiles folder and it's contents in the location where the services are trying to find it. PublishRoutingServices.log