We have a 10.8.1 Enterprise on AWS configured across multiple tiers and in HA.
The Hosting Server site is also providing Map/Feature services sourced from FGDB stored in a network share.
The File Share is owned by the ArcGIS Service account and the directory has been confirmed with Full Control for all subdirectories and files. We imported a webgisdr export to this environment from a separate Enterprise that was configured with the same architecture, but with the server directories and the registered file share data store using a different UNC path (original was \\amznfsxoccaafpl.<xxxdomain>\share\gisdata ). We manually copied the data files from the original file share to the new location (\\amznfsxdadnke2z.<xxxdomain>\share\gisdata) and confirmed the ownership and permissions.
When we updated the registered data store via the Portal front end (the data store had been added in the source environment as an item to Portal) to use the new UNC path, I expected this to update the manifest.json for all the services and allow them to restart using the new UNC path to the FGDBs.
However, this did not happen. Even after a restart, the services did not restart correctly. They all started with warning messages similar to the following
FAILED | ||
Message: | Can not open file \\amznfsxdadnke2z.<xxxdomain>\share\arcgisserver\directories\arcgissystem\arcgisinput\XXXX_XXXXMetro_GDA94.MapServer\extracted\p20\XXXX_XXXXMetro_GDA94.msd.
| |
Instance startup state: | STARTED_WITH_ERRORS | |
Message: | Instance of service 'XXX_XXXXMetro_GDA94.MapServer' started with errors. The StandaloneTable:'Tbl_Water_PipeDepth_LUT' in Map:'ESSIL_SydneyMetro_GDA94' is invalid. The base table definition string "Tbl_Water_PipeDepth_LUT" is invalid. | |
Have we made an assumption that is not correct? If so, how should we update the registered data store path and have it propagate to all the existing services?
Solved! Go to Solution.
well - as it turns out - I was incorrect in assuming that the tool provided in Portal to alter the settings of a registered folder data store would go through and update the data source for every layer in every service. (Despite the equivalent tooling for a registered database data store doing exactly that).
As our workflow involved using webgisdr to move the server site to a new environment, I should have taken more note of the direction in the help ArcGIS Enterprise backups—Portal for ArcGIS | Documentation for ArcGIS Enterprise
Item or setting | 10.4.x | 10.5.x, 10.6 | 10.6.1 and later |
Registered data stores other than ArcGIS Data Store | Yes | Yes | Yes |
In the end, we have been forced to republish all the existing services with the overwrite option.
Fortunately, there had been no update of the web layers from the Portal side (pop-ups, layerorder etc), so nothing has been lost.
well - as it turns out - I was incorrect in assuming that the tool provided in Portal to alter the settings of a registered folder data store would go through and update the data source for every layer in every service. (Despite the equivalent tooling for a registered database data store doing exactly that).
As our workflow involved using webgisdr to move the server site to a new environment, I should have taken more note of the direction in the help ArcGIS Enterprise backups—Portal for ArcGIS | Documentation for ArcGIS Enterprise
Item or setting | 10.4.x | 10.5.x, 10.6 | 10.6.1 and later |
Registered data stores other than ArcGIS Data Store | Yes | Yes | Yes |
In the end, we have been forced to republish all the existing services with the overwrite option.
Fortunately, there had been no update of the web layers from the Portal side (pop-ups, layerorder etc), so nothing has been lost.