Select to view content in your preferred language

Resetting Server registered File Share data store

805
1
Jump to solution
05-18-2022 04:27 AM
DavidHoy
Esri Contributor

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.
The system cannot find the path specified.
Probable cause: The file is inaccessible to Server.

 

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?

 

0 Kudos
1 Solution

Accepted Solutions
DavidHoy
Esri Contributor

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

Must this item or setting be identical across deployments when running the webgisdr utility?

 
Item or setting10.4.x10.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.

 

View solution in original post

1 Reply
DavidHoy
Esri Contributor

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

Must this item or setting be identical across deployments when running the webgisdr utility?

 
Item or setting10.4.x10.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.